freeradius and yubikeys
Hi, I'm evaluating the use of yubikey OTP's in combination with freeradius and I'd like to know if there's people out there who can share the experience. In particular: - In which mode are you using the yubikey? - How are you verifying the OTP's? through PAM or through another module? Thanks for any response, Frederic
On 8 May 2014, at 13:41, Frederic Van Espen <frederic.ve@gmail.com> wrote:
Hi,
I'm evaluating the use of yubikey OTP's in combination with freeradius and I'd like to know if there's people out there who can share the experience. In particular:
- In which mode are you using the yubikey?
Awesome mode, the only mode they have.
- How are you verifying the OTP's? through PAM or through another module?
How about the rlm_yubikey module, which does both local auth and auth against a yubico server? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello Arran, On Thu, May 8, 2014 at 2:58 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
- How are you verifying the OTP's? through PAM or through another module?
How about the rlm_yubikey module, which does both local auth and auth against a yubico server?
As I understood, this one is only available in FreeRADIUS 3.0. I'm currently running 2.1.12 that's included in debian wheezy. If it is not available (yet) for FreeRADIUS 2.1.12, do you think it would be possible/difficult to port it? I'm currently trying out the one by yubico based on rlm_perl. Only, with the current configuration I'm not sure how the normal password can be verfied to our ldap server. Cheers, Frederic
On Thu, May 8, 2014 at 3:28 PM, Frederic Van Espen <frederic.ve@gmail.com> wrote:
Hello Arran,
On Thu, May 8, 2014 at 2:58 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
- How are you verifying the OTP's? through PAM or through another module?
How about the rlm_yubikey module, which does both local auth and auth against a yubico server?
As I understood, this one is only available in FreeRADIUS 3.0. I'm currently running 2.1.12 that's included in debian wheezy. If it is not available (yet) for FreeRADIUS 2.1.12, do you think it would be possible/difficult to port it?
I'm currently trying out the one by yubico based on rlm_perl. Only, with the current configuration I'm not sure how the normal password can be verfied to our ldap server.
I figured out how to verify the normal user password, however, the question about the rlm_yubikey module still stands :-) Cheers, Frederic
On 8 May 2014, at 20:43, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Thu, May 8, 2014 at 3:28 PM, Frederic Van Espen <frederic.ve@gmail.com> wrote:
Hello Arran,
On Thu, May 8, 2014 at 2:58 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
- How are you verifying the OTP's? through PAM or through another module?
How about the rlm_yubikey module, which does both local auth and auth against a yubico server?
As I understood, this one is only available in FreeRADIUS 3.0. I'm currently running 2.1.12 that's included in debian wheezy. If it is not available (yet) for FreeRADIUS 2.1.12, do you think it would be possible/difficult to port it?
I'm currently trying out the one by yubico based on rlm_perl. Only, with the current configuration I'm not sure how the normal password can be verfied to our ldap server.
I figured out how to verify the normal user password, however, the question about the rlm_yubikey module still stands :-)
2.2.x is feature frozen. rlm_yubikey also relies on the connection pool API which is only in 3.0.x which relies on talloc, and other API changes, so the short answer is no to both... But why stick with the OS packages? Just do a make deb and you've rolled your own. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
2.2.x is feature frozen. rlm_yubikey also relies on the connection pool API which is only in 3.0.x which relies on talloc, and other API changes, so the short answer is no to both...
OK, thanks for the clear anwser
But why stick with the OS packages? Just do a make deb and you've rolled your own.
Well, easy security updates are certainly a plus. Is version 3 fully backward compatible with version 2? If so I guess I could give it a shot, certainly in the testing environment. Cheers, Frederic
On 9 May 2014, at 07:21, Frederic Van Espen <frederic.ve@gmail.com> wrote:
2.2.x is feature frozen. rlm_yubikey also relies on the connection pool API which is only in 3.0.x which relies on talloc, and other API changes, so the short answer is no to both...
OK, thanks for the clear anwser
But why stick with the OS packages? Just do a make deb and you've rolled your own.
Well, easy security updates are certainly a plus.
Which you'd get if you rolled your own packages, and hey you'd actually be contributing something, because if you came across any defects, you might actually be able to provide useful debugging info. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, May 9, 2014 at 9:11 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Which you'd get if you rolled your own packages, and hey you'd actually be contributing something, because if you came across any defects, you might actually be able to provide useful debugging info.
I now have version 3.0.2 up and running with rlm_yubikey. For this testing setup, I'm simply trying to validate to the public yubicloud server using the validate mode. When I was using the rlm_perl based module, I was able to enter a user password, followed by the OTP token. The perl module extracted the OTP and passed on the user password for further authentication (in my case LDAP). Now when I use radtest like this: root@obelix-clone:/usr/src# radtest fes testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr 127.0.0.1 0 testing123 Sending Access-Request of id 85 from 0.0.0.0 port 56523 to 127.0.0.1 port 1812 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x00 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=85, length=20 Here's the output of the server: rad_recv: Access-Request packet from host 127.0.0.1 port 56523, id=85, length=121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0xf4c430ea058e22ef07ef239f42b0270f Fri May 9 11:52:20 2014 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default Fri May 9 11:52:20 2014 : Debug: (0) authorize { Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [preprocess] = ok Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) yubikey : User-Password value is not the correct length, expected 44, got 59 Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [yubikey] = noop Fri May 9 11:52:20 2014 : Debug: (0) if (ok) Fri May 9 11:52:20 2014 : Debug: (0) if (ok) -> FALSE Do you know of any way to regain the behaviour of the rlm_perl based module (user password AND OTP token for two factor authentication)? Should I maybe handle that in the configuration? Thanks, Frederic
On 9 May 2014, at 11:14, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Fri, May 9, 2014 at 9:11 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Which you'd get if you rolled your own packages, and hey you'd actually be contributing something, because if you came across any defects, you might actually be able to provide useful debugging info.
I now have version 3.0.2 up and running with rlm_yubikey. For this testing setup, I'm simply trying to validate to the public yubicloud server using the validate mode.
When I was using the rlm_perl based module, I was able to enter a user password, followed by the OTP token. The perl module extracted the OTP and passed on the user password for further authentication (in my case LDAP). Now when I use radtest like this: root@obelix-clone:/usr/src# radtest fes testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr 127.0.0.1 0 testing123 Sending Access-Request of id 85 from 0.0.0.0 port 56523 to 127.0.0.1 port 1812 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x00 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=85, length=20
Here's the output of the server: rad_recv: Access-Request packet from host 127.0.0.1 port 56523, id=85, length=121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0xf4c430ea058e22ef07ef239f42b0270f Fri May 9 11:52:20 2014 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default Fri May 9 11:52:20 2014 : Debug: (0) authorize { Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [preprocess] = ok Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) yubikey : User-Password value is not the correct length, expected 44, got 59
^ Look at me, look at me, i'm the reason why it's not working, look at me look at me.
Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [yubikey] = noop Fri May 9 11:52:20 2014 : Debug: (0) if (ok) Fri May 9 11:52:20 2014 : Debug: (0) if (ok) -> FALSE
Do you know of any way to regain the behaviour of the rlm_perl based module (user password AND OTP token for two factor authentication)? Should I maybe handle that in the configuration?
The scheme of concatenating the password with the token string is user defined. The yubikey module checks you've performed the split correctly, by looking at the length of the User-Password. It cannot split out the password + OTP token for you as it does not know your concatenation scheme. The yubikey module restricts you to straight concatenation with no separator, FreeRADIUS lets you use any scheme. If you're doing 2FA as a single round with password + OTP concatenation, you need something like: authorize { # 44 is OTP len + ID Len if (User-Password =~ /^(.*)([cbdefghijklnrtuv]{44})$/) { update request { User-Password = "%{2}" } yubikey if (ok) { update request { User-Password := "%{1}" } } } <insert modules to get control:Password-With-Header or control:*-Password, ldap, files etc...> pap } If you look, that's almost exactly what the perl module does. The above will work for normal PAP auth as well as Yubikey auth, as normal passwords are never likely to be that long and consist of modhex chars. AFAIK yubico don't authenticate passwords centrally, just the OTP codes. If that's changed and the API allows the user's password to be sent in some form I can take a look at updating the module, but I don't believe it has. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, May 9, 2014 at 1:02 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
The scheme of concatenating the password with the token string is user defined. The yubikey module checks you've performed the split correctly, by looking at the length of the User-Password. It cannot split out the password + OTP token for you as it does not know your concatenation scheme. The yubikey module restricts you to straight concatenation with no separator, FreeRADIUS lets you use any scheme.
Makes sense. Thanks for the clarification!
If you're doing 2FA as a single round with password + OTP concatenation, you need something like:
authorize {
# 44 is OTP len + ID Len if (User-Password =~ /^(.*)([cbdefghijklnrtuv]{44})$/) { update request { User-Password = "%{2}" } yubikey if (ok) { update request { User-Password := "%{1}" } } } <insert modules to get control:Password-With-Header or control:*-Password, ldap, files etc...> pap
}
I'm still missing something here. It looks like the authorize section of rlm_yubikey always returns OK, regardless whether the OTP token was used or not. Only when I call the yubikey module in the authentice section is it really contacting the yubicloud servers and verifying the OTP. But then I always get authenticated without supplying the user password. Hence my next question, can I use 2 Auth-Type's in the authenticate section? Or is that exactly what you mean by <insert modules to get control:Password-With-Header or control:*-Password, ldap, files etc...> in your previous mail? Thanks, Frederic
On 9 May 2014, at 12:02, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 9 May 2014, at 11:14, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Fri, May 9, 2014 at 9:11 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Which you'd get if you rolled your own packages, and hey you'd actually be contributing something, because if you came across any defects, you might actually be able to provide useful debugging info.
I now have version 3.0.2 up and running with rlm_yubikey. For this testing setup, I'm simply trying to validate to the public yubicloud server using the validate mode.
When I was using the rlm_perl based module, I was able to enter a user password, followed by the OTP token. The perl module extracted the OTP and passed on the user password for further authentication (in my case LDAP). Now when I use radtest like this: root@obelix-clone:/usr/src# radtest fes testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr 127.0.0.1 0 testing123 Sending Access-Request of id 85 from 0.0.0.0 port 56523 to 127.0.0.1 port 1812 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x00 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=85, length=20
Here's the output of the server: rad_recv: Access-Request packet from host 127.0.0.1 port 56523, id=85, length=121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjrndreglhlcdnrrkvcneruvcnnffieibr' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0xf4c430ea058e22ef07ef239f42b0270f Fri May 9 11:52:20 2014 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default Fri May 9 11:52:20 2014 : Debug: (0) authorize { Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [preprocess] = ok Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) yubikey : User-Password value is not the correct length, expected 44, got 59
^ Look at me, look at me, i'm the reason why it's not working, look at me look at me.
Fri May 9 11:52:20 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 11:52:20 2014 : Debug: (0) [yubikey] = noop Fri May 9 11:52:20 2014 : Debug: (0) if (ok) Fri May 9 11:52:20 2014 : Debug: (0) if (ok) -> FALSE
Do you know of any way to regain the behaviour of the rlm_perl based module (user password AND OTP token for two factor authentication)? Should I maybe handle that in the configuration?
The scheme of concatenating the password with the token string is user defined. The yubikey module checks you've performed the split correctly, by looking at the length of the User-Password. It cannot split out the password + OTP token for you as it does not know your concatenation scheme. The yubikey module restricts you to straight concatenation with no separator, FreeRADIUS lets you use any scheme.
If you're doing 2FA as a single round with password + OTP concatenation, you need something like:
Oops. It's more like authorize { # 44 is OTP len + ID Len if (User-Password =~ /^(.*)([cbdefghijklnrtuv]{44})$/) { update request { User-Password = "%{2}" } yubikey.authenticate if (ok) { update request { User-Password := "%{1}" } } } <insert modules to get control:Password-With-Header or control:*-Password, ldap, files etc...> pap } Ok i'll see if I can fix the behaviour to be a little more sane. -Arran
On Fri, May 9, 2014 at 2:32 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Oops. It's more like
authorize { # 44 is OTP len + ID Len if (User-Password =~ /^(.*)([cbdefghijklnrtuv]{44})$/) { update request { User-Password = "%{2}" } yubikey.authenticate
Perfect! That was the missing bit! Thank you sir! It is now authenticating the yubikey OTP. Afterwards it fetches the crypt password from ldap which is then verify using PAP in the authenticate section. Cheers, Frederic
On 9 May 2014, at 14:42, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Fri, May 9, 2014 at 2:32 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Oops. It's more like
authorize { # 44 is OTP len + ID Len if (User-Password =~ /^(.*)([cbdefghijklnrtuv]{44})$/) { update request { User-Password = "%{2}" } yubikey.authenticate
Perfect! That was the missing bit! Thank you sir!
nice!
It is now authenticating the yubikey OTP. Afterwards it fetches the crypt password from ldap which is then verify using PAP in the authenticate section.
I've fixed it in v3.0.x HEAD (which will become 3.0.3 very soon) so that it just works. If you could test it'd be very much appreciated :) For your setup with LDAP and crypt, it'd be something like: authorize { yubikey ldap } authenticate { Auth-Type yubikey { yubikey pap } } Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, May 9, 2014 at 3:52 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I've fixed it in v3.0.x HEAD (which will become 3.0.3 very soon) so that it just works. If you could test it'd be very much appreciated :)
For your setup with LDAP and crypt, it'd be something like: authorize { yubikey ldap }
authenticate { Auth-Type yubikey { yubikey pap } }
Alas, does not seem to work with the configuration you suggest :-( Relevant configuration files and debug output: mods-enabled/yubikey: yubikey { split = yes decrypt = no validate = yes validation { servers { } client_id = XXXXX api_key = 'OBSCURED' pool { start = 5 min = 4 max = 10 spare = 3 uses = 0 lifetime = 0 idle_timeout = 60 spread = yes } } } sites-enabled/default: server default { listen { type = auth ipaddr = * port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { ipaddr = * port = 0 type = acct limit { } } authorize { preprocess yubikey -ldap expiration logintime } authenticate { Auth-Type yubikey { yubikey pap } } preacct { preprocess acct_unique suffix files } accounting { detail unix -sql exec attr_filter.accounting_response } session { } post-auth { exec remove_reply_message_if_eap Post-Auth-Type REJECT { -sql attr_filter.access_reject eap remove_reply_message_if_eap } } pre-proxy { } post-proxy { eap } } and the debugging output: Received Access-Request Id 9 from 127.0.0.1:37537 to 127.0.0.1:1812 length 121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x9c976b6fd97fd7fc4d98acd97be8fc27 Fri May 9 16:41:15 2014 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default Fri May 9 16:41:15 2014 : Debug: (0) authorize { Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [preprocess] = ok Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) yubikey : User-Password (aes-block) value contains non modhex chars Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [yubikey] = noop Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Fri May 9 16:41:15 2014 : Debug: rlm_ldap (ldap): Reserved connection (4) Fri May 9 16:41:15 2014 : Debug: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) Fri May 9 16:41:15 2014 : Debug: Parsed xlat tree: Fri May 9 16:41:15 2014 : Debug: literal --> (uid= Fri May 9 16:41:15 2014 : Debug: if { Fri May 9 16:41:15 2014 : Debug: attribute --> Stripped-User-Name Fri May 9 16:41:15 2014 : Debug: { Fri May 9 16:41:15 2014 : Debug: ref 2 Fri May 9 16:41:15 2014 : Debug: list 1 Fri May 9 16:41:15 2014 : Debug: tag -128 Fri May 9 16:41:15 2014 : Debug: } Fri May 9 16:41:15 2014 : Debug: } Fri May 9 16:41:15 2014 : Debug: else { Fri May 9 16:41:15 2014 : Debug: attribute --> User-Name Fri May 9 16:41:15 2014 : Debug: { Fri May 9 16:41:15 2014 : Debug: ref 2 Fri May 9 16:41:15 2014 : Debug: list 1 Fri May 9 16:41:15 2014 : Debug: tag -128 Fri May 9 16:41:15 2014 : Debug: } Fri May 9 16:41:15 2014 : Debug: } Fri May 9 16:41:15 2014 : Debug: literal --> ) Fri May 9 16:41:15 2014 : Debug: (0) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) Fri May 9 16:41:15 2014 : Debug: (0) ldap : --> (uid=fes) Fri May 9 16:41:15 2014 : Debug: ou=People,dc=escaux,dc=com Fri May 9 16:41:15 2014 : Debug: Parsed xlat tree: Fri May 9 16:41:15 2014 : Debug: literal --> ou=People,dc=escaux,dc=com Fri May 9 16:41:15 2014 : Debug: (0) ldap : EXPAND ou=People,dc=escaux,dc=com Fri May 9 16:41:15 2014 : Debug: (0) ldap : --> ou=People,dc=escaux,dc=com Fri May 9 16:41:15 2014 : Debug: (0) ldap : Performing search in 'ou=People,dc=escaux,dc=com' with filter '(uid=fes)', scope 'sub' Fri May 9 16:41:15 2014 : Debug: (0) ldap : Waiting for search result... Fri May 9 16:41:15 2014 : Debug: (0) ldap : User object found at DN "uid=fes,ou=People,dc=escaux,dc=com" Fri May 9 16:41:15 2014 : Debug: (0) ldap : Processing user attributes Fri May 9 16:41:15 2014 : Debug: (0) ldap : control:Password-With-Header += ''{CRYPT}$6$rounds=1000$czjqtQQw5Sx6BURM$67zg9ok5r8IVTQNcQkdx1Mbi5A75gbHgt5I3oI/Z038MPg8htLLswallK.ou/r914j/0Tkwyuf92ZHsVg1DTz.'' Fri May 9 16:41:15 2014 : Debug: (0) ldap : Attribute "ntPassword" not found in LDAP object Fri May 9 16:41:15 2014 : Debug: rlm_ldap (ldap): Released connection (4) Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: returned from ldap (rlm_ldap) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [ldap] = ok Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: calling expiration (rlm_expiration) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: returned from expiration (rlm_expiration) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [expiration] = noop Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: calling logintime (rlm_logintime) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) modsingle[authorize]: returned from logintime (rlm_logintime) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [logintime] = noop Fri May 9 16:41:15 2014 : Debug: (0) } # authorize = ok Fri May 9 16:41:15 2014 : ERROR: (0) No Auth-Type found: rejecting the user via Post-Auth-Type = Reject Fri May 9 16:41:15 2014 : Debug: (0) Failed to authenticate the user. Fri May 9 16:41:15 2014 : Debug: (0) Using Post-Auth-Type Reject Fri May 9 16:41:15 2014 : Debug: (0) # Executing group from file /etc/freeradius/sites-enabled/default Fri May 9 16:41:15 2014 : Debug: (0) Post-Auth-Type REJECT { Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) for request 0 Fri May 9 16:41:15 2014 : Debug: %{User-Name} Fri May 9 16:41:15 2014 : Debug: Parsed xlat tree: Fri May 9 16:41:15 2014 : Debug: attribute --> User-Name Fri May 9 16:41:15 2014 : Debug: { Fri May 9 16:41:15 2014 : Debug: ref 2 Fri May 9 16:41:15 2014 : Debug: list 1 Fri May 9 16:41:15 2014 : Debug: tag -128 Fri May 9 16:41:15 2014 : Debug: } Fri May 9 16:41:15 2014 : Debug: (0) attr_filter.access_reject : EXPAND %{User-Name} Fri May 9 16:41:15 2014 : Debug: (0) attr_filter.access_reject : --> fes Fri May 9 16:41:15 2014 : Debug: (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [attr_filter.access_reject] = updated Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: calling eap (rlm_eap) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: returned from eap (rlm_eap) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [eap] = noop Fri May 9 16:41:15 2014 : Debug: (0) remove_reply_message_if_eap remove_reply_message_if_eap { Fri May 9 16:41:15 2014 : Debug: (0) if (reply:EAP-Message && reply:Reply-Message) Fri May 9 16:41:15 2014 : Debug: (0) if (reply:EAP-Message && reply:Reply-Message) -> FALSE Fri May 9 16:41:15 2014 : Debug: (0) else else { Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: calling noop (rlm_always) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) modsingle[post-auth]: returned from noop (rlm_always) for request 0 Fri May 9 16:41:15 2014 : Debug: (0) [noop] = noop Fri May 9 16:41:15 2014 : Debug: (0) } # else else = noop Fri May 9 16:41:15 2014 : Debug: (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop Fri May 9 16:41:15 2014 : Debug: (0) } # Post-Auth-Type REJECT = updated Fri May 9 16:41:15 2014 : Debug: (0) Delaying response for 1 seconds Fri May 9 16:41:15 2014 : Debug: Waking up in 0.3 seconds. Fri May 9 16:41:16 2014 : Debug: Waking up in 0.6 seconds. Fri May 9 16:41:16 2014 : Debug: (0) Sending delayed response Sending Access-Reject Id 9 from 127.0.0.1:1812 to 127.0.0.1:37537 Fri May 9 16:41:16 2014 : Debug: Waking up in 3.9 seconds. Fri May 9 16:41:20 2014 : Debug: (0) Cleaning up request packet ID 9 with timestamp +11 Fri May 9 16:41:20 2014 : Info: Ready to process requests. Let me know if there is anything more that you need tested. Frederic
On 9 May 2014, at 15:49, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Fri, May 9, 2014 at 3:52 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I've fixed it in v3.0.x HEAD (which will become 3.0.3 very soon) so that it just works. If you could test it'd be very much appreciated :)
For your setup with LDAP and crypt, it'd be something like: authorize { yubikey ldap }
authenticate { Auth-Type yubikey { yubikey pap } }
Alas, does not seem to work with the configuration you suggest :-(
Git pull... I haven't fixed anything, but i've added a format marker, so it'll show where in the string it found the non modhex char. It'll only show up with -Xx because of the policy we introduced about not showing sensitive strings with -X, after a couple of accidental postings of passwords to GitHub and the list. I tested with your string and it came back fine, so i'm a little confused. Here's my output (with -Xx). Received Access-Request Id 50 from 127.0.0.1:54741 to 127.0.0.1:1812 length 91 Code: 1 Id: 50 Length: 91 Vector: d6f8b36def2807b39afba22805bd09f5 Data: 01 05 66 6f 6f 02 42 d9 dc 63 29 40 fb 89 6d 8d 9c 24 bf 8b 63 a4 dd e0 72 05 bb 58 38 ab 56 7c 40 ec d8 51 8e 98 49 cd a9 e4 4e 76 1a 53 0c 14 67 29 a2 98 c4 8d ad 1a ce 51 70 e8 bb 44 70 ed ae 8e ff c6 8d 1a 8a User-Name = 'foo' User-Password = 'testingpasswordccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) # Executing section authorize from file /usr/local/freeradius/etc/raddb/sites-enabled/default Fri May 9 18:40:54 2014 : Debug: (0) authorize { Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:Yubikey-OTP := 'ccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:User-Password := 'testingpassword' Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) [yubikey] = ok and your debug was was: Fri May 9 16:41:15 2014 : Debug: (0) yubikey : User-Password (aes-block) value contains non modhex chars Meaning it found a char outside of "cbdefghijklnrtuv" in the AES block portion, but were using the same string, so I don't see how that works. Relevant configuration files and debug output: mods-enabled/yubikey: yubikey { split = yes decrypt = no validate = yes validation { servers { } client_id = XXXXX api_key = 'OBSCURED' Hmm I'll add the << secret >> stuff to api_key as well. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, May 9, 2014 at 9:45 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Git pull... I haven't fixed anything, but i've added a format marker, so it'll show where in the string it found the non modhex char.
It'll only show up with -Xx because of the policy we introduced about not showing sensitive strings with -X, after a couple of accidental postings of passwords to GitHub and the list.
I tested with your string and it came back fine, so i'm a little confused. Here's my output (with -Xx).
Received Access-Request Id 50 from 127.0.0.1:54741 to 127.0.0.1:1812 length 91 Code: 1 Id: 50 Length: 91 Vector: d6f8b36def2807b39afba22805bd09f5 Data: 01 05 66 6f 6f 02 42 d9 dc 63 29 40 fb 89 6d 8d 9c 24 bf 8b 63 a4 dd e0 72 05 bb 58 38 ab 56 7c 40 ec d8 51 8e 98 49 cd a9 e4 4e 76 1a 53 0c 14 67 29 a2 98 c4 8d ad 1a ce 51 70 e8 bb 44 70 ed ae 8e ff c6 8d 1a 8a User-Name = 'foo' User-Password = 'testingpasswordccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) # Executing section authorize from file /usr/local/freeradius/etc/raddb/sites-enabled/default Fri May 9 18:40:54 2014 : Debug: (0) authorize { Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:Yubikey-OTP := 'ccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:User-Password := 'testingpassword' Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) [yubikey] = ok
and your debug was was:
Fri May 9 16:41:15 2014 : Debug: (0) yubikey : User-Password (aes-block) value contains non modhex chars
Meaning it found a char outside of "cbdefghijklnrtuv" in the AES block portion, but were using the same string, so I don't see how that works.
Are you sure you did not change anything else? Output is different this time and I'm doing the same thing with the same config. I'm starting it by running "freeradius -Xx" as you suggested. Looks like the authorize section worked correctly (it set Auth-Type to yubikey), but then authentication part fails (BAD_SERVER_SIGNATURE): Received Access-Request Id 222 from 127.0.0.1:33290 to 127.0.0.1:1812 length 121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjebenhetldrkgtbitjlhfhbjnvbhhhiee' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x60e2d3f93d66ace0b8842f7e06c873ee Sat May 10 00:46:30 2014 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default Sat May 10 00:46:30 2014 : Debug: (0) authorize { Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [preprocess] = ok Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) yubikey : request:Yubikey-OTP := 'ccccccdbkebjebenhetldrkgtbitjlhfhbjnvbhhhiee' Sat May 10 00:46:30 2014 : Debug: (0) yubikey : request:User-Password := 'testingpassword' Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [yubikey] = ok Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: calling ldap (rlm_ldap) for request 0 Sat May 10 00:46:30 2014 : Debug: rlm_ldap (ldap): Reserved connection (4) Sat May 10 00:46:30 2014 : Debug: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) Sat May 10 00:46:30 2014 : Debug: Parsed xlat tree: Sat May 10 00:46:30 2014 : Debug: literal --> (uid= Sat May 10 00:46:30 2014 : Debug: if { Sat May 10 00:46:30 2014 : Debug: attribute --> Stripped-User-Name Sat May 10 00:46:30 2014 : Debug: { Sat May 10 00:46:30 2014 : Debug: ref 2 Sat May 10 00:46:30 2014 : Debug: list 1 Sat May 10 00:46:30 2014 : Debug: tag -128 Sat May 10 00:46:30 2014 : Debug: } Sat May 10 00:46:30 2014 : Debug: } Sat May 10 00:46:30 2014 : Debug: else { Sat May 10 00:46:30 2014 : Debug: attribute --> User-Name Sat May 10 00:46:30 2014 : Debug: { Sat May 10 00:46:30 2014 : Debug: ref 2 Sat May 10 00:46:30 2014 : Debug: list 1 Sat May 10 00:46:30 2014 : Debug: tag -128 Sat May 10 00:46:30 2014 : Debug: } Sat May 10 00:46:30 2014 : Debug: } Sat May 10 00:46:30 2014 : Debug: literal --> ) Sat May 10 00:46:30 2014 : Debug: (0) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) Sat May 10 00:46:30 2014 : Debug: (0) ldap : --> (uid=fes) Sat May 10 00:46:30 2014 : Debug: ou=People,dc=escaux,dc=com Sat May 10 00:46:30 2014 : Debug: Parsed xlat tree: Sat May 10 00:46:30 2014 : Debug: literal --> ou=People,dc=escaux,dc=com Sat May 10 00:46:30 2014 : Debug: (0) ldap : EXPAND ou=People,dc=escaux,dc=com Sat May 10 00:46:30 2014 : Debug: (0) ldap : --> ou=People,dc=escaux,dc=com Sat May 10 00:46:30 2014 : Debug: (0) ldap : Performing search in 'ou=People,dc=escaux,dc=com' with filter '(uid=fes)', scope 'sub' Sat May 10 00:46:30 2014 : Debug: (0) ldap : Waiting for search result... Sat May 10 00:46:30 2014 : Debug: (0) ldap : User object found at DN "uid=fes,ou=People,dc=escaux,dc=com" Sat May 10 00:46:30 2014 : Debug: (0) ldap : Processing user attributes Sat May 10 00:46:30 2014 : Debug: (0) ldap : control:Password-With-Header += ''{CRYPT}$6$rounds=1000$czjqtQQw5Sx6BURM$67zg9ok5r8IVTQNcQkdx1Mbi5A75gbHgt5I3oI/Z038MPg8htLLswallK.ou/r914j/0Tkwyuf92ZHsVg1DTz.'' Sat May 10 00:46:30 2014 : Debug: (0) ldap : Attribute "ntPassword" not found in LDAP object Sat May 10 00:46:30 2014 : Debug: rlm_ldap (ldap): Released connection (4) Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: returned from ldap (rlm_ldap) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [ldap] = ok Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: calling expiration (rlm_expiration) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: returned from expiration (rlm_expiration) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [expiration] = noop Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: calling logintime (rlm_logintime) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authorize]: returned from logintime (rlm_logintime) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [logintime] = noop Sat May 10 00:46:30 2014 : Debug: (0) } # authorize = ok Sat May 10 00:46:30 2014 : Debug: (0) Found Auth-Type = yubikey Sat May 10 00:46:30 2014 : Debug: (0) # Executing group from file /etc/freeradius/sites-enabled/default Sat May 10 00:46:30 2014 : Debug: (0) Auth-Type yubikey { Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authenticate]: calling yubikey (rlm_yubikey) for request 0 Sat May 10 00:46:30 2014 : Debug: rlm_yubikey (yubikey): Reserved connection (4) Sat May 10 00:46:30 2014 : ERROR: (0) yubikey : Server response signature was invalid (BAD_SERVER_SIGNATURE) Sat May 10 00:46:30 2014 : Debug: rlm_yubikey (yubikey): Released connection (4) Sat May 10 00:46:30 2014 : Debug: (0) modsingle[authenticate]: returned from yubikey (rlm_yubikey) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [yubikey] = fail Sat May 10 00:46:30 2014 : Debug: (0) } # Auth-Type yubikey = fail Sat May 10 00:46:30 2014 : Debug: (0) Failed to authenticate the user. Sat May 10 00:46:30 2014 : Debug: (0) Using Post-Auth-Type Reject Sat May 10 00:46:30 2014 : Debug: (0) # Executing group from file /etc/freeradius/sites-enabled/default Sat May 10 00:46:30 2014 : Debug: (0) Post-Auth-Type REJECT { Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) for request 0 Sat May 10 00:46:30 2014 : Debug: %{User-Name} Sat May 10 00:46:30 2014 : Debug: Parsed xlat tree: Sat May 10 00:46:30 2014 : Debug: attribute --> User-Name Sat May 10 00:46:30 2014 : Debug: { Sat May 10 00:46:30 2014 : Debug: ref 2 Sat May 10 00:46:30 2014 : Debug: list 1 Sat May 10 00:46:30 2014 : Debug: tag -128 Sat May 10 00:46:30 2014 : Debug: } Sat May 10 00:46:30 2014 : Debug: (0) attr_filter.access_reject : EXPAND %{User-Name} Sat May 10 00:46:30 2014 : Debug: (0) attr_filter.access_reject : --> fes Sat May 10 00:46:30 2014 : Debug: (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [attr_filter.access_reject] = updated Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: calling eap (rlm_eap) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: returned from eap (rlm_eap) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [eap] = noop Sat May 10 00:46:30 2014 : Debug: (0) remove_reply_message_if_eap remove_reply_message_if_eap { Sat May 10 00:46:30 2014 : Debug: (0) if (reply:EAP-Message && reply:Reply-Message) Sat May 10 00:46:30 2014 : Debug: (0) if (reply:EAP-Message && reply:Reply-Message) -> FALSE Sat May 10 00:46:30 2014 : Debug: (0) else else { Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: calling noop (rlm_always) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) modsingle[post-auth]: returned from noop (rlm_always) for request 0 Sat May 10 00:46:30 2014 : Debug: (0) [noop] = noop Sat May 10 00:46:30 2014 : Debug: (0) } # else else = noop Sat May 10 00:46:30 2014 : Debug: (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop Sat May 10 00:46:30 2014 : Debug: (0) } # Post-Auth-Type REJECT = updated Sat May 10 00:46:30 2014 : Debug: (0) Delaying response for 1 seconds Sat May 10 00:46:30 2014 : Debug: Waking up in 0.2 seconds. Sat May 10 00:46:30 2014 : Debug: Waking up in 0.7 seconds. Sat May 10 00:46:31 2014 : Debug: (0) Sending delayed response Sending Access-Reject Id 222 from 127.0.0.1:1812 to 127.0.0.1:33290 Sat May 10 00:46:31 2014 : Debug: Waking up in 3.9 seconds. Sat May 10 00:46:35 2014 : Debug: (0) Cleaning up request packet ID 222 with timestamp +14 Sat May 10 00:46:35 2014 : Info: Ready to process requests. Thanks a lot for your time. Frederic
On 10 May 2014, at 00:04, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Fri, May 9, 2014 at 9:45 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Git pull... I haven't fixed anything, but i've added a format marker, so it'll show where in the string it found the non modhex char.
It'll only show up with -Xx because of the policy we introduced about not showing sensitive strings with -X, after a couple of accidental postings of passwords to GitHub and the list.
I tested with your string and it came back fine, so i'm a little confused. Here's my output (with -Xx).
Received Access-Request Id 50 from 127.0.0.1:54741 to 127.0.0.1:1812 length 91 Code: 1 Id: 50 Length: 91 Vector: d6f8b36def2807b39afba22805bd09f5 Data: 01 05 66 6f 6f 02 42 d9 dc 63 29 40 fb 89 6d 8d 9c 24 bf 8b 63 a4 dd e0 72 05 bb 58 38 ab 56 7c 40 ec d8 51 8e 98 49 cd a9 e4 4e 76 1a 53 0c 14 67 29 a2 98 c4 8d ad 1a ce 51 70 e8 bb 44 70 ed ae 8e ff c6 8d 1a 8a User-Name = 'foo' User-Password = 'testingpasswordccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) # Executing section authorize from file /usr/local/freeradius/etc/raddb/sites-enabled/default Fri May 9 18:40:54 2014 : Debug: (0) authorize { Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: calling yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:Yubikey-OTP := 'ccccccdbkebjkgfkgdrvthntvckrnifbicgrdgrldigl' Fri May 9 18:40:54 2014 : Debug: (0) yubikey : request:User-Password := 'testingpassword' Fri May 9 18:40:54 2014 : Debug: (0) modsingle[authorize]: returned from yubikey (rlm_yubikey) for request 0 Fri May 9 18:40:54 2014 : Debug: (0) [yubikey] = ok
and your debug was was:
Fri May 9 16:41:15 2014 : Debug: (0) yubikey : User-Password (aes-block) value contains non modhex chars
Meaning it found a char outside of "cbdefghijklnrtuv" in the AES block portion, but were using the same string, so I don't see how that works.
Are you sure you did not change anything else?
Ah, yes, I accidentally fixed it. https://github.com/FreeRADIUS/freeradius-server/commit/34dd540de3ac66c659e3d... Was reading len bytes, should of only been 44 :)
Output is different this time and I'm doing the same thing with the same config. I'm starting it by running "freeradius -Xx" as you suggested. Looks like the authorize section worked correctly (it set Auth-Type to yubikey), but then authentication part fails (BAD_SERVER_SIGNATURE):
Hm, that apparently means that the API key was incorrect. Double check the config? or valgrind --leak-check=full <path to freeradius> <args> -m I guess it could be memory corruption... I can have a look on Monday if it's still not working. I just don't have my yubikey token at home. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sat, May 10, 2014 at 1:37 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ah, yes, I accidentally fixed it.
https://github.com/FreeRADIUS/freeradius-server/commit/34dd540de3ac66c659e3d...
Was reading len bytes, should of only been 44 :)
Output is different this time and I'm doing the same thing with the same config. I'm starting it by running "freeradius -Xx" as you suggested. Looks like the authorize section worked correctly (it set Auth-Type to yubikey), but then authentication part fails (BAD_SERVER_SIGNATURE):
Hm, that apparently means that the API key was incorrect. Double check the config?
I don't believe the configuration was changed, and it was working on 3.0.2 with the password and token splitting done in the vhost config. I'll test later today with version 3.0.2 again to confirm.
valgrind --leak-check=full <path to freeradius> <args> -m
I guess it could be memory corruption...
Here's the output from valgrind. Admittedly, this is relatively unknown grounds for me so I don't really know what the output means, but at least it is indeed doing some output where rlm_yubikey is concerned: Ready to process requests. Received Access-Request Id 160 from 127.0.0.1:34487 to 127.0.0.1:1812 length 121 User-Name = 'fes' User-Password = 'testingpasswordccccccdbkebjgjjgnhrrgtdlderdhtjtnhknrlhtgbbn' NAS-IP-Address = 172.16.35.65 NAS-Port = 0 Message-Authenticator = 0x4fa072c8817ccaa12dd7a55fd90af6cd (0) # Executing section authorize from file /etc/freeradius/sites-enabled/default (0) authorize { (0) [preprocess] = ok ==6105== Invalid read of size 1 ==6105== at 0x4C2A884: memcpy (mc_replace_strmem.c:838) ==6105== by 0x5074815: pairstrncpy (in /usr/lib/freeradius/libfreeradius-radius.so) ==6105== by 0x9BC9C68: mod_authorize (in /usr/lib/freeradius/rlm_yubikey.so) ==6105== by 0x41FEAD: modcall_recurse (in /usr/sbin/freeradius) ==6105== by 0x41F220: modcall_child (in /usr/sbin/freeradius) ==6105== by 0x41F3DD: modcall_recurse (in /usr/sbin/freeradius) ==6105== by 0x4204FC: modcall (in /usr/sbin/freeradius) ==6105== by 0x41DC02: indexed_modcall (in /usr/sbin/freeradius) ==6105== by 0x40F7D1: rad_authenticate (in /usr/sbin/freeradius) ==6105== by 0x42C742: request_running (in /usr/sbin/freeradius) ==6105== by 0x429DE4: request_queue_or_run (in /usr/sbin/freeradius) ==6105== by 0x42B006: request_receive (in /usr/sbin/freeradius) ==6105== Address 0xcd6471a is 106 bytes inside a block of size 140 free'd ==6105== at 0x4C27D4E: free (vg_replace_malloc.c:427) ==6105== by 0x5AED918: _talloc_free (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.0.7) ==6105== by 0x5072E1B: pairstrsteal (in /usr/lib/freeradius/libfreeradius-radius.so) ==6105== by 0x9BC9D09: mod_authorize (in /usr/lib/freeradius/rlm_yubikey.so) ==6105== by 0x41FEAD: modcall_recurse (in /usr/sbin/freeradius) ==6105== by 0x41F220: modcall_child (in /usr/sbin/freeradius) ==6105== by 0x41F3DD: modcall_recurse (in /usr/sbin/freeradius) ==6105== by 0x4204FC: modcall (in /usr/sbin/freeradius) ==6105== by 0x41DC02: indexed_modcall (in /usr/sbin/freeradius) ==6105== by 0x40F7D1: rad_authenticate (in /usr/sbin/freeradius) ==6105== by 0x42C742: request_running (in /usr/sbin/freeradius) ==6105== by 0x429DE4: request_queue_or_run (in /usr/sbin/freeradius) ==6105== (0) [yubikey] = ok rlm_ldap (ldap): Reserved connection (4) (0) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (0) ldap : --> (uid=fes) (0) ldap : EXPAND ou=People,dc=escaux,dc=com (0) ldap : --> ou=People,dc=escaux,dc=com (0) ldap : Performing search in 'ou=People,dc=escaux,dc=com' with filter '(uid=fes)', scope 'sub' (0) ldap : Waiting for search result... (0) ldap : User object found at DN "uid=fes,ou=People,dc=escaux,dc=com" (0) ldap : Processing user attributes (0) ldap : control:Password-With-Header += ''{CRYPT}$6$rounds=1000$czjqtQQw5Sx6BURM$67zg9ok5r8IVTQNcQkdx1Mbi5A75gbHgt5I3oI/Z038MPg8htLLswallK.ou/r914j/0Tkwyuf92ZHsVg1DTz.'' rlm_ldap (ldap): Released connection (4) (0) [ldap] = ok (0) [expiration] = noop (0) [logintime] = noop (0) } # authorize = ok (0) Found Auth-Type = yubikey (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Auth-Type yubikey { rlm_yubikey (yubikey): Reserved connection (4) (0) ERROR: yubikey : Server response signature was invalid (BAD_SERVER_SIGNATURE) rlm_yubikey (yubikey): Released connection (4) (0) [yubikey] = fail (0) } # Auth-Type yubikey = fail (0) Failed to authenticate the user. (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/freeradius/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject : EXPAND %{User-Name} (0) attr_filter.access_reject : --> fes (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure (0) [eap] = noop (0) remove_reply_message_if_eap remove_reply_message_if_eap { (0) if (reply:EAP-Message && reply:Reply-Message) (0) if (reply:EAP-Message && reply:Reply-Message) -> FALSE (0) else else { (0) [noop] = noop (0) } # else else = noop (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1 seconds Waking up in 0.9 seconds. (0) Sending delayed response Sending Access-Reject Id 160 from 127.0.0.1:1812 to 127.0.0.1:34487 Waking up in 3.9 seconds. (0) Cleaning up request packet ID 160 with timestamp +16 Ready to process requests. ^CReady to process requests. Signalled to terminate Exiting normally. rlm_ldap (ldap): Removing connection pool rlm_ldap (ldap): Closing connection (4) rlm_ldap (ldap): Closing connection (3) rlm_ldap (ldap): Closing connection (2) rlm_ldap (ldap): Closing connection (1) rlm_ldap (ldap): Closing connection (0) rlm_yubikey (yubikey): Removing connection pool rlm_yubikey (yubikey): Closing connection (3) rlm_yubikey (yubikey): Closing connection (2) rlm_yubikey (yubikey): Closing connection (1) rlm_yubikey (yubikey): Closing connection (0) rlm_yubikey (yubikey): Closing connection (4) ==6105== ==6105== HEAP SUMMARY: ==6105== in use at exit: 48,749 bytes in 1,000 blocks ==6105== total heap usage: 57,844 allocs, 56,844 frees, 5,591,028 bytes allocated ==6105== ==6105== 17 bytes in 1 blocks are definitely lost in loss record 5 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8236C61: ??? ==6105== by 0x8009CF1: ??? ==6105== by 0x800A233: ??? ==6105== by 0x7FEFAAA: ??? ==6105== by 0x7FEFE94: ??? ==6105== by 0x7DD353A: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== by 0x7DD057F: ??? ==6105== by 0x41D83B: find_module_instance (in /usr/sbin/freeradius) ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 42 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x8922C62: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 43 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x89295D8: ??? ==6105== by 0x892987C: ??? ==6105== by 0x892C51F: ??? ==6105== by 0x8922C81: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 44 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x89295D8: ??? ==6105== by 0x892987C: ??? ==6105== by 0x893838F: ??? ==6105== by 0x8922C8A: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 45 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x89295D8: ??? ==6105== by 0x892987C: ??? ==6105== by 0x893262F: ??? ==6105== by 0x8922C96: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 46 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x8963969: ??? ==6105== by 0x89639C8: ??? ==6105== by 0x89649D4: ??? ==6105== by 0x86F1BB2: ??? ==6105== by 0x869CF28: ??? ==6105== by 0x868C0E4: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 40 bytes in 1 blocks are definitely lost in loss record 47 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8236594: ??? ==6105== by 0x8015B2C: ??? ==6105== by 0x8963979: ??? ==6105== by 0x89639C8: ??? ==6105== by 0x89649D4: ??? ==6105== by 0x86F1BB2: ??? ==6105== by 0x869CF28: ??? ==6105== by 0x868C0E4: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 120 (48 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 56 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8DABAA0: ??? ==6105== by 0x8DAC35B: ??? ==6105== by 0x8DAC569: ??? ==6105== by 0x8DACCFB: ??? ==6105== by 0x86A271D: ??? ==6105== by 0x868C101: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== ==6105== 120 (48 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 57 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8DABAA0: ??? ==6105== by 0x8DAAA6D: ??? ==6105== by 0x8DAB021: ??? ==6105== by 0x8DAC657: ??? ==6105== by 0x8DACCFB: ??? ==6105== by 0x86A271D: ??? ==6105== by 0x868C101: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== ==6105== 288 (48 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 63 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8922D14: ??? ==6105== by 0x89239A8: ??? ==6105== by 0x8927B3C: ??? ==6105== by 0x892C79B: ??? ==6105== by 0x893263E: ??? ==6105== by 0x8922C96: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 337 (48 direct, 289 indirect) bytes in 1 blocks are definitely lost in loss record 64 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8DABAA0: ??? ==6105== by 0x8DAD6E0: ??? ==6105== by 0x86A26C2: ??? ==6105== by 0x868C101: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== by 0x7DD057F: ??? ==6105== ==6105== 392 bytes in 1 blocks are definitely lost in loss record 65 of 81 ==6105== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) ==6105== by 0x868506D: ??? ==6105== by 0x868C0EF: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== by 0x7DD057F: ??? ==6105== by 0x41D83B: find_module_instance (in /usr/sbin/freeradius) ==6105== by 0x41E655: modules_init (in /usr/sbin/freeradius) ==6105== ==6105== 664 bytes in 1 blocks are definitely lost in loss record 68 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8922D14: ??? ==6105== by 0x89239A8: ??? ==6105== by 0x8923CEE: ??? ==6105== by 0x8923E1E: ??? ==6105== by 0x8963A04: ??? ==6105== by 0x89649D4: ??? ==6105== by 0x86F1BB2: ??? ==6105== by 0x869CF28: ??? ==6105== by 0x868C0E4: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== ==6105== 664 bytes in 1 blocks are definitely lost in loss record 69 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8922D14: ??? ==6105== by 0x89239A8: ??? ==6105== by 0x8923CEE: ??? ==6105== by 0x8923E1E: ??? ==6105== by 0x8963A94: ??? ==6105== by 0x89649D4: ??? ==6105== by 0x86F1BB2: ??? ==6105== by 0x869CF28: ??? ==6105== by 0x868C0E4: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== ==6105== 720 (48 direct, 672 indirect) bytes in 1 blocks are definitely lost in loss record 71 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8922D14: ??? ==6105== by 0x89239A8: ??? ==6105== by 0x8927B3C: ??? ==6105== by 0x8936DE3: ??? ==6105== by 0x893839E: ??? ==6105== by 0x8922C8A: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 864 (48 direct, 816 indirect) bytes in 1 blocks are definitely lost in loss record 73 of 81 ==6105== at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==6105== by 0x8922D14: ??? ==6105== by 0x89239A8: ??? ==6105== by 0x8927B3C: ??? ==6105== by 0x8929B24: ??? ==6105== by 0x892C52E: ??? ==6105== by 0x8922C81: ??? ==6105== by 0x8922F24: ??? ==6105== by 0x892095B: ??? ==6105== by 0x8013CA5: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== ==6105== 4,452 (72 direct, 4,380 indirect) bytes in 1 blocks are definitely lost in loss record 79 of 81 ==6105== at 0x4C272B8: calloc (vg_replace_malloc.c:566) ==6105== by 0x8B9FD7E: ??? ==6105== by 0x8BA120D: ??? ==6105== by 0x868C03E: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== by 0x7DD057F: ??? ==6105== by 0x41D83B: find_module_instance (in /usr/sbin/freeradius) ==6105== ==6105== 34,345 (72 direct, 34,273 indirect) bytes in 1 blocks are definitely lost in loss record 81 of 81 ==6105== at 0x4C272B8: calloc (vg_replace_malloc.c:566) ==6105== by 0x8B9FD7E: ??? ==6105== by 0x8BA120D: ??? ==6105== by 0x868C025: ??? ==6105== by 0x8016DC7: ??? ==6105== by 0x8013D7A: ??? ==6105== by 0x800AF22: ??? ==6105== by 0x7DD378C: ??? ==6105== by 0x424B07: fr_connection_spawn (in /usr/sbin/freeradius) ==6105== by 0x425598: fr_connection_pool_init (in /usr/sbin/freeradius) ==6105== by 0x7DD057F: ??? ==6105== by 0x41D83B: find_module_instance (in /usr/sbin/freeradius) ==6105== ==6105== LEAK SUMMARY: ==6105== definitely lost: 2,409 bytes in 18 blocks ==6105== indirectly lost: 40,814 bytes in 936 blocks ==6105== possibly lost: 0 bytes in 0 blocks ==6105== still reachable: 5,526 bytes in 46 blocks ==6105== suppressed: 0 bytes in 0 blocks ==6105== Reachable blocks (those to which a pointer was found) are not shown. ==6105== To see them, rerun with: --leak-check=full --show-reachable=yes ==6105== ==6105== For counts of detected and suppressed errors, rerun with: -v ==6105== ERROR SUMMARY: 30 errors from 19 contexts (suppressed: 149 from 8) ==6105== could not unlink /tmp/vgdb-pipe-from-vgdb-to-6105-by-root-on-??? ==6105== could not unlink /tmp/vgdb-pipe-to-vgdb-from-6105-by-root-on-??? ==6105== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-6105-by-root-on-??? Cheers, Frederic
On 10 May 2014, at 08:06, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Sat, May 10, 2014 at 1:37 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ah, yes, I accidentally fixed it.
https://github.com/FreeRADIUS/freeradius-server/commit/34dd540de3ac66c659e3d...
Was reading len bytes, should of only been 44 :)
Output is different this time and I'm doing the same thing with the same config. I'm starting it by running "freeradius -Xx" as you suggested. Looks like the authorize section worked correctly (it set Auth-Type to yubikey), but then authentication part fails (BAD_SERVER_SIGNATURE):
Hm, that apparently means that the API key was incorrect. Double check the config?
I don't believe the configuration was changed, and it was working on 3.0.2 with the password and token splitting done in the vhost config. I'll test later today with version 3.0.2 again to confirm.
OK.
valgrind --leak-check=full <path to freeradius> <args> -m
I guess it could be memory corruption...
Here's the output from valgrind. Admittedly, this is relatively unknown grounds for me so I don't really know what the output means, but at least it is indeed doing some output where rlm_yubikey is concerned:
Thanks. Hm, fixed that one issue, doubt it would of cause a validation error though. The rest of the output was false positives. The server just exits without attempting to cleanup unless you specify -m. I've made it a bit more strict about starting up with invalid API keys, so if it's getting the config from where other than where you think it is, it'll refuse to start. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sat, May 10, 2014 at 2:44 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I don't believe the configuration was changed, and it was working on 3.0.2 with the password and token splitting done in the vhost config. I'll test later today with version 3.0.2 again to confirm.
OK.
Confirmed, without even touching the rlm_yubikey config file and simply downgrading the packages, authentication works fine. The API key was not changed in the config files.
Thanks.
Hm, fixed that one issue, doubt it would of cause a validation error though.
The rest of the output was false positives. The server just exits without attempting to cleanup unless you specify -m.
That's weird. I did start it like this: valgrind --leak-check=full /usr/sbin/freeradius -Xx -m
I've made it a bit more strict about starting up with invalid API keys, so if it's getting the config from where other than where you think it is, it'll refuse to start.
I took a few HTTP traces to compare the difference between 3.0.2 and 3.0.3. Here's the request for 3.0.2: 48.948991 172.16.35.65 -> 103.6.213.69 HTTP 293 GET /wsapi/2.0/verify?id=<XXXXX>&nonce=rvepnyfmrllivnnlbuorqnpetedqwldn&otp=ccccccdbkebjdktflifkufelthvkbjucgfefkijlvrdc&h=V1HcnOhTiaW2mxs5Zgeg1VqFU5k%3D HTTP/1.1 And here's one for 3.0.3: 0.033011 172.16.35.65 -> 109.74.193.72 HTTP 264 GET /wsapi/2.0/verify?id=<XXXXX>&nonce=tughzbxuolnhvjqhyryljthvdkwwyjnu&otp=testingpassword&h=uJfyrooihrq7onQhW8coLiyWARE%3D HTTP/1.1 Looks like we're sending the user's password instead of the OTP :-) I guess that should be easy to fix? Cheers, Frederic
On 10 May 2014, at 17:01, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Sat, May 10, 2014 at 2:44 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I don't believe the configuration was changed, and it was working on 3.0.2 with the password and token splitting done in the vhost config. I'll test later today with version 3.0.2 again to confirm.
OK.
Confirmed, without even touching the rlm_yubikey config file and simply downgrading the packages, authentication works fine. The API key was not changed in the config files.
Thanks.
Hm, fixed that one issue, doubt it would of cause a validation error though.
The rest of the output was false positives. The server just exits without attempting to cleanup unless you specify -m.
That's weird. I did start it like this: valgrind --leak-check=full /usr/sbin/freeradius -Xx -m
I've noticed it doesn't always go down cleanly for some reason. I ran it on my Ubuntu VM and confirmed it wasn't leaking handles.
I've made it a bit more strict about starting up with invalid API keys, so if it's getting the config from where other than where you think it is, it'll refuse to start.
I took a few HTTP traces to compare the difference between 3.0.2 and 3.0.3. Here's the request for 3.0.2:
48.948991 172.16.35.65 -> 103.6.213.69 HTTP 293 GET /wsapi/2.0/verify?id=<XXXXX>&nonce=rvepnyfmrllivnnlbuorqnpetedqwldn&otp=ccccccdbkebjdktflifkufelthvkbjucgfefkijlvrdc&h=V1HcnOhTiaW2mxs5Zgeg1VqFU5k%3D HTTP/1.1
And here's one for 3.0.3: 0.033011 172.16.35.65 -> 109.74.193.72 HTTP 264 GET /wsapi/2.0/verify?id=<XXXXX>&nonce=tughzbxuolnhvjqhyryljthvdkwwyjnu&otp=testingpassword&h=uJfyrooihrq7onQhW8coLiyWARE%3D HTTP/1.1
Looks like we're sending the user's password instead of the OTP :-)
That'd be a problem :P shame about the crap error message, it'd of been easier to figure out if their servers had sent back something meaningful, 'o' isn't even a modhex char.
I guess that should be easy to fix?
Good catch. Half the original auth code got the passcode from char *passcode, and the other used VALUE_PAIR *request->password *sigh*. Ok, all uses passcode now, should work. You know you can do the decryption locally right? You don't need to use their servers. The module didn't even have support for ykclient until they grumbled about it. You can put the shared keys in LDAP as well, you just need to figure out a place to stick the replay counters. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sat, May 10, 2014 at 8:01 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Good catch. Half the original auth code got the passcode from char *passcode, and the other used VALUE_PAIR *request->password *sigh*. Ok, all uses passcode now, should work.
Confirmed working fine now :)
You know you can do the decryption locally right? You don't need to use their servers. The module didn't even have support for ykclient until they grumbled about it.
You can put the shared keys in LDAP as well, you just need to figure out a place to stick the replay counters.
I do know :) I'm currently just trying to set up a small prototype, but admittedly, I haven't done all that much research yet on how to make things run locally. But I'm really going to use all this in production, that's certainly the way we'll go. Thanks a bunch for all your efforts! Frederic
On 11 May 2014, at 09:01, Frederic Van Espen <frederic.ve@gmail.com> wrote:
On Sat, May 10, 2014 at 8:01 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Good catch. Half the original auth code got the passcode from char *passcode, and the other used VALUE_PAIR *request->password *sigh*. Ok, all uses passcode now, should work.
Confirmed working fine now :)
Good :)
You know you can do the decryption locally right? You don't need to use their servers. The module didn't even have support for ykclient until they grumbled about it.
You can put the shared keys in LDAP as well, you just need to figure out a place to stick the replay counters.
I do know :) I'm currently just trying to set up a small prototype, but admittedly, I haven't done all that much research yet on how to make things run locally.
You need to store 3 bits of info, where they come from is completely up to you. It works in a similar way to using the validation server: 1. yubikey.authorize splits out the Yubikey-Public-ID, Yubikey-OTP and User-Password fields from the password string. It also sets Auth-Type yubikey. 2. You implement additional logic to get the control:Yubikey-Key value, associated with the Yubikey-Public-ID and/or User, and the control:Yubikey-Counter value associated with the Yubikey-Public-ID. If there isn't one, you set it to 0. 3. Authenticate runs with yubikey.authenticate, it converts Yubikey-OTP to binary (from modhex), and attempts to decode it using control:Yubikey-Key. It it succeeds it outputs request:Yubikey-Private-ID (which you can use for further validation), request:Yubikey-Timestamp, request:Yubikey-Random and request:Yubikey-Counter (a combination of a couple of 16 bit values from the token used to prevent replay attacks). It then checks that request:Yubikey-Counter > control:Yubikey-Counter, and rejects the request if it's not. Yubikey-Random is for debugging, but could be stored and compared to ensure a new random number is used for each auth. Yubikey-Timestamp is also mostly for debugging, but could be stored and compared to make sure it increased between auths. 4. In post-auth if the previous stage was successful you update your stored Yubikey-Counter to match request:Yubikey-Counter. You can do even neater things if you can be bothered to write the logic. For example if you keep a table with yubikey state (assigned/unassigned), pre-provision all the keys with known shared-secrets and stick them all in the table, the first time a user auths with an unassigned key, you can do auto provisioning and create the association between user and key. Other physical token code based systems can't do this as they don't send the token ID along with the token code. It's the reason why I wrote the module, it's the first OTP system that i've seen that doesn't completely suck. RSA tokens, and all the other little 6-8 digit pin code systems are complete shit compared to yubikey. SMS based OTP is so insecure I can't believe anyone actually uses it, the same with those stupid Java software tokens you run on smartphones.
But I'm really going to use all this in production, that's certainly the way we'll go.
Thanks a bunch for all your efforts!
Thanks for the testing and feedback! -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
FWIW, I've had very little trouble getting YubiKeys to work (in OATH-HOTP mode) with the Google Authenticator PAM through FreeRADIUS. The benefit to that was that it allowed me to support YubiKeys and the Google Authenticator app with the same configuration so that users could have one or the other (YubiKeys are definitely more secure and more universal than smartphone apps, but there is a cost attached to purchasing and (re-)programming them). In my case the FreeRADIUS side of this was pretty easy to configure since my NAS allowed for a secondary authentication server, so all I really had to do in FR was deal with the OTP, although later on I also set up a two-step process using FreeRADIUS for both stages with an Access-Challenge to drive the OTP authentication. On Thu, May 8, 2014 at 6:41 AM, Frederic Van Espen <frederic.ve@gmail.com>wrote:
Hi,
I'm evaluating the use of yubikey OTP's in combination with freeradius and I'd like to know if there's people out there who can share the experience. In particular:
- In which mode are you using the yubikey? - How are you verifying the OTP's? through PAM or through another module?
Thanks for any response,
Frederic - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 12 May 2014, at 19:52, Scott Ireland <sireland+freeradius@ualberta.net> wrote:
FWIW, I've had very little trouble getting YubiKeys to work (in OATH-HOTP mode) with the Google Authenticator PAM through FreeRADIUS. The benefit to that was that it allowed me to support YubiKeys and the Google Authenticator app with the same configuration so that users could have one or the other
That's neat.
(YubiKeys are definitely more secure and more universal than smartphone apps, but there is a cost attached to purchasing and (re-)programming them).
What cost do you see in (re-)programming them out of interest? There is a yubikey-personalization CLI utility. Integrate that with some large USB hubs, D-BUS and some undergraduates and I imagine the programming process would be pretty painless? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 12 May 2014, at 22:19, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 12 May 2014, at 19:52, Scott Ireland <sireland+freeradius@ualberta.net> wrote:
FWIW, I've had very little trouble getting YubiKeys to work (in OATH-HOTP mode) with the Google Authenticator PAM through FreeRADIUS. The benefit to that was that it allowed me to support YubiKeys and the Google Authenticator app with the same configuration so that users could have one or the other
That's neat.
(YubiKeys are definitely more secure and more universal than smartphone apps, but there is a cost attached to purchasing and (re-)programming them).
What cost do you see in (re-)programming them out of interest?
There is a yubikey-personalization CLI utility. Integrate that with some large USB hubs, D-BUS and some undergraduates and I imagine the programming process would be pretty painless?
http://www.cambrionix.com/components/large-capacity-49-port-charge-and-sync-... Mmmm usb. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Mon, May 12, 2014 at 3:19 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
(YubiKeys are definitely more secure and more universal than smartphone apps, but there is a cost attached to purchasing and (re-)programming them).
What cost do you see in (re-)programming them out of interest?
There is a yubikey-personalization CLI utility. Integrate that with some large USB hubs, D-BUS and some undergraduates and I imagine the programming process would be pretty painless?
Corporate environment rather than educational, so at best we have co-op placements instead of undergraduates. :P That said, it's not so much the initial programming of them that scares me as the inevitable replacement of lost keys (which, in fairness, is just the initial programming of a spare) and occasionally having to reprogram one that gets out of sync in weird ways (I actually had a YubiKey's HOTP counter somehow get behind the server's, which should be impossible, but it happened and prevented all future authentications until I reset the server's counter and resynced them). Put users at enough different sites and things involving physically touching the keys to fix issues get more challenging.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Frederic Van Espen -
Scott Ireland