I am trying to resurrect otpd, a GPL fork is here "https://code.google.com/p/otpd/. I like this thing because it allows me to run my own OTP service with OATH compliant event based tokens of almost any kind. I never got any time based tokens working and I don't really care. Years ago, I got otpd working by running it as radiusd so that FreeRadius could interact with it. This required setting all rights on all otpd related files and /var/run/otpd/socket to be owned and perm'd for radiusd. I don't know enough about LINUX to know why radiusd had to run otpd but I do remember that no matter what I did, if radiusd did not have rights to /var/run/otpd/socket then FreeRadius was always denied permission when attempting to interact with otpd. Compiling the otpd code was also a challenge because I mostly run Fedora and C files, ./configure and make files all had to be messed with. But I managed. The problem I face now though is that if I do everything I originally did as above I get all the way to authenticating and freeradius always fails the authentication and otpd seg faults. otptest executable works just fine (while running as user otpd, I haven't worked out how to use radiusd while running otptest. I always get... [root@HP-LAB-1 otpd]# su -l radiusd otptest This account is currently not available. I can use tokens and confirm that otpd is working with otptest if and only if I use root while otpd itself is running as root. The major changes that I used to make to FreeRadius configuration was: 4. Now edit the /etc/raddb/sites-available/default file and add a single line with text “otp” inside of both the authorize and authenticate sections. 5. Now add the same “otp” entries into the same sections found in the file /etc/raddb/sites_enabled/inner-tunnel. 6. Restart radiusd with “service radiusd restart”. I added otp to default and inner-tunnel like below (right underneath the heading: authorize { otp ... } authenticate { otp ... } Executing radtest... [mhawkins@HP-LAB-1 bNAC]$ radtest test1 885115 localhost 10 testing123 Sending Access-Request of id 84 to 127.0.0.1 port 1812 User-Name = "test1" User-Password = "885115" NAS-IP-Address = 127.0.0.1 NAS-Port = 10 Message-Authenticator = 0x00000000000000000000000000000000 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=84, length=20 Debug from freeradius looks like... rad_recv: Access-Request packet from host 127.0.0.1 port 37633, id=84, length=75 User-Name = "test1" User-Password = "885115" NAS-IP-Address = 127.0.0.1 NAS-Port = 10 Message-Authenticator = 0x54ce669945c80bffd886fce32b90a76a # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} rlm_otp: otp_pwe_present: password attributes 2, 2 ++[otp] returns ok ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "test1", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = otp # Executing group from file /etc/raddb/sites-enabled/default +- entering group authenticate {...} rlm_otp: otp_pwe_present: password attributes 2, 2 ++[otp] returns fail Failed to authenticate the user. Using Post-Auth-Type REJECT # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test1 attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 6 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 6 Sending Access-Reject of id 84 to 127.0.0.1 port 37633 Waking up in 4.9 seconds. Cleaning up request 6 ID 84 with timestamp +858 Ready to process requests. All of the above results in otpd still running. But if I run radtest once more... otpd segfaults and leaves the /var/run/otpd/socket inaccessible by radiusd. I can see that otpd passes the authentication but freeradius doesn't see it. Sep 22 22:16:59 HP-LAB-1 otpd[9352]: accept_thread: plugin accept fd=8 Sep 22 22:16:59 HP-LAB-1 otpd[9352]: work_thread(140561874147072,8): handling plugin request for [test1] Sep 22 22:16:59 HP-LAB-1 otpd[9352]: verify: user [test1] authentication succeeded So I don't know why FreeRadius is failing the authentication and I don't know why otpd is segfaulting (this is the first time I've ever had to work on an executable that does that). Any help or hints on how to solve or troubleshoot this would be *VERY* much appreciated. /Mike Hawkins