otpd - resurrecting it

[Michael A Hawkins]

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 at 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 at 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