Re: [RADIATOR] Encrypted Password
On 06/15/2011 12:18 PM, Roy Abu Bakar wrote: Hello Roy, Can you please tell me the name of the registered company that has purchased this copy of Radiator? Please reply to me directly, thanks! > I have set up radiator using for authentication. So far, it's > working properly. > I browse radmin database, and I see the user password (column PASS_WORD) is > saving in clear text. If you go to RAdmin settings, you can select Password storage format. The setting will affect passwords that are changed after you change the setting. > As our policy in our organization, all passwords physically in database > should > be encrypted. > Is there a way we can do to encrypt the password physically in the database? If you change the setting, you need to consider the implications for your authentication protocols too. Best regards, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] radiator exists on ClientSQL timeout
On 06/15/2011 06:07 PM, Alexander Hartmaier wrote: > can you please give me an update on that issue?! > We still have to restart radiator approximatly once a day because it > either hangs or crashes. I took a look at some possibilities: what do you think about an option that instructs Radiator to close the database connection after the clientlist update? Then there would not be problems with firewall mangling the connection. I have not discussed the option here yet, but this is something I have thought about. Another option for you would be to make the updates more frequent so that the firewall does not think the TCP connection is idle. As I wrote Radiator tries to detect and recover from unexpected connection problems so the crash problem seems to come from lower levels, which means debugging is much harder. Thanks! > Best regards, Alex > > Am 2011-05-31 11:38, schrieb Hartmaier Alexander: >> Since running with the foreground option radiator doesn't die any more >> and the log only contains lines like those: >> Mon May 30 17:38:14 2011: ERR: Execute failed for 'SELECT device.ipaddr, >> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN >> core.tblhost@PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE >> device.fk_collector = 5': SQL Timeout >> Mon May 30 19:40:14 2011: ERR: Execute failed for 'SELECT device.ipaddr, >> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN >> core.tblhost@PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE >> device.fk_collector = 5': SQL Timeout >> Mon May 30 21:42:16 2011: ERR: Execute failed for 'SELECT device.ipaddr, >> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN >> core.tblhost@PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE >> device.fk_collector = 5': SQL Timeout >> Mon May 30 23:44:18 2011: ERR: Execute failed for 'SELECT device.ipaddr, >> 'statickey', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> NULL, NULL, device.hostid, NULL, NULL, NULL, NULL, NULL, NULL, NULL, >> 'OSC-Group-Identifier=' || tblhost.hsup FROM device JOIN >> core.tblhost@PCMSAT01 ON (device.hostid = tblhost.hostid) WHERE >> device.fk_collector = 5': SQL Timeout >> >> Note that although the refresh interval is configured for 3600 which is >> one hour, it only seems to try every two hours. >> >> Am 2011-05-30 14:02, schrieb Heikki Vatiainen: >>> On 05/25/2011 07:09 PM, Alexander Hartmaier wrote: >>> no, this is only acting as tacacs+ server without any db logging. >>> Thanks for confirming this. >>> # refresh the client list every hour RefreshPeriod 3600 The intermediate firewalls will close the connection because the tcp connection is inactive for about an hour. Can we enable tcp keepalives or add a check to radiator which detects broken connections? >>> It already does check for broken connections. Just before it prints >>> "Adding Clients from SQL database" it does reconnect when needed. >>> >>> So it does a reconnect that succeeds, tries to execute the select for >>> getting the client list and then hits "Execute failed". Now I would be >>> interested in seeing what else it logs before it dies or hangs completely. >>> >>> Can you pass me the logs? I would especially be interested in seeing if >>> it is able to log "Automatic ClientListSQL refresh failed, keeping old list" >>> DBIx::Connector was created from DBIx::Class code and would be the ideal solution for this problem. You could include the newest version with every Radiator release if the license (same as Perl) allows it. >>> I can ask about this, but currently disconnects and reconnects should be >>> handled already. >>> >>> But if you could provide the logs that show how far Radiator gets after >>> "Adding Clients from SQL database" that would be very useful. >>> >>> Thanks! >>> >> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien >> Handelsgericht Wien, FN 79340b >> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >> Notice: This e-mail contains information that is confidential and may be >> privileged. >> If you are not the intended recipient, please notify the sender and then >> delete this e-mail immediately. >> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* >> ___ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator >
Re: [RADIATOR] Encrypted Password
Hi Heikki, Thanks for reply. I really happy when I saw that option on the RAdmin configuration :) I have change the format to Unix Crypt and then change my user password. After that, I tried to logged in, but did not succeed. I check the log and it said "Bad Password". Is there any configuration that I have to configure after change the password format? Here is the log: Thu Jun 16 12:53:21 2011: DEBUG: Handling with Radius::AuthRADMIN: Thu Jun 16 12:53:21 2011: DEBUG: Handling with Radius::AuthRADMIN: Thu Jun 16 12:53:21 2011: DEBUG: Query is: 'select PASS_WORD, STATICADDRESS, TIMELEFT, MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM, VALIDTO from RADUSERS where USERNAME='admin'': Thu Jun 16 12:53:21 2011: DEBUG: Query is: 'select ATTR_ID, VENDOR_ID, IVALUE, SVALUE, ITEM_TYPE from RADSTCONFIG where NAME='Switches' order by ITEM_TYPE': Thu Jun 16 12:53:21 2011: DEBUG: Query is: 'select ATTR_ID, VENDOR_ID, IVALUE, SVALUE, ITEM_TYPE from RADCONFIG where NAME='admin' order by ITEM_TYPE': Thu Jun 16 12:53:21 2011: DEBUG: Radius::AuthRADMIN looks for match with admin [admin] Thu Jun 16 12:53:21 2011: DEBUG: do query is: 'update RADUSERS set BADLOGINS=BADLOGINS+1 where USERNAME='admin'': Thu Jun 16 12:53:21 2011: DEBUG: Query is: 'select PASS_WORD, STATICADDRESS, TIMELEFT, MAXLOGINS, SERVICENAME, BADLOGINS, VALIDFROM, VALIDTO from RADUSERS where USERNAME='DEFAULT'': Thu Jun 16 12:53:21 2011: DEBUG: AuthBy result: REJECT, Bad Password Thu Jun 16 12:53:21 2011: INFO: Access rejected for admin: Bad Password Thu Jun 16 12:53:21 2011: DEBUG: Packet dump: *** Sending to 10.0.0.200 port 1645 Code: Access-Reject Identifier: 14 Authentic: X<128>t<249><148>bc<16><27><172><153><160><133><128><2><162> Attributes: Reply-Message = "Request Denied" Thanks. From: Heikki Vatiainen To: Roy Abu Bakar Cc: radiator@open.com.au Sent: Thu, June 16, 2011 10:55:19 AM Subject: Re: [RADIATOR] Encrypted Password On 06/15/2011 12:18 PM, Roy Abu Bakar wrote: Hello Roy, Can you please tell me the name of the registered company that has purchased this copy of Radiator? Please reply to me directly, thanks! > I have set up radiator using for authentication. So far, it's > working properly. > I browse radmin database, and I see the user password (column PASS_WORD) is > saving in clear text. If you go to RAdmin settings, you can select Password storage format. The setting will affect passwords that are changed after you change the setting. > As our policy in our organization, all passwords physically in database > should > be encrypted. > Is there a way we can do to encrypt the password physically in the database? If you change the setting, you need to consider the implications for your authentication protocols too. Best regards, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Stopping Radiator: problem with killproc
Thanks, I didn't think of that one.
Output after changing:
# /etc/init.d/radiator stop
Shutting down Radiator: -p /var/log/radius/radiusd.pid
/var/log/radius/radius.pid exists, its content is the right pid, so that
shouldn't bhe the problem.
What seems to be missing is the /full/path/to/executable. A killproc with only
-p pid_file isn't working, either.
I changed the KILLPROC etc. lines to "killproc /usr/bin/radiusd -p
${RADIUSD_PIDFILE}" and its restarting an d stopping fine.
Note: there seems to be a space missing in /etc/init.d/radiator:
# SuSE etc
...
TRACEUPPROC="killproc-p ..."
...
- Aeneas
-Ursprüngliche Nachricht-
Von: Michael [mailto:ri...@vianet.ca]
Gesendet: Sonntag, 12. Juni 2011 06:58
An: Aeneas Jaißle
Cc: radiator@open.com.au
Betreff: Re: [RADIATOR] Stopping Radiator: problem with killproc
maybe change your killproc line:
KILLPROC="killproc -p ${RADIUSD_PIDFILE}"
to something like this for debug:
KILLPROC="echo -p ${RADIUSD_PIDFILE}"
then try to kill it, and see what it says for the output for this variable.
one thing i can think of is that your pid file location may have spaces in it.
or, the pidfile location is wrong.
reply with the output.
Michael
On Fri, 10 Jun 2011, Aeneas Jaißle wrote:
> Hi,
>
> I just tried the patched script, no change at all.
>
> # /etc/init.d/radiator stop
> Shutting down Radiator: killproc: Usage:
> killproc [-v] [-q] [-L] [-g|-G] [-N] [-p pid_file] [I ignore_file] \
> [-c root] [-t] [-SIG] /full/path/to/executable
> killproc -l
>
> #
>
>
> OS is openSUSE 11.4, Radiator was installed through RPM.
>
> - Aeneas
>
>
>
> -Ursprüngliche Nachricht-
> Von: Heikki Vatiainen [mailto:h...@open.com.au]
> Gesendet: Freitag, 10. Juni 2011 22:34
> An: Aeneas Jaißle
> Cc: radiator@open.com.au
> Betreff: Re: [RADIATOR] Stopping Radiator: problem with killproc
>
> On 06/10/2011 04:30 PM, Aeneas Jaißle wrote:
>
> Hello Aeneas,
>
>>> there were some issues while installing and running the radius
>>> server for the first time on an openSUSE server (system was looking
>>> for the scripts in /usr/lib/perl5/site_perl/5.12.3/ instead of
>>> /usr/lib/perl5/site_perl/5.10.0/) and there are still issues with
>>> restarting and stopping the service (handing over arguments to
>>> killproc doesn't work; instead of killing the process it displays
>>> the usage of killproc).
>
> There have been a couple of patches for the init.d script
> goodies/linux-radiator.init. You could try downloading the patches and trying
> the patched init.d script too see if it solves your problem.
>
> Thanks!
>
> --
> Heikki Vatiainen
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS,
> PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full
> source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> .
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
