FreeRADIUS EAP-TLS Lookup Client Cert From LDAP DIT
I've searched for this sort of posting, but found issues unrelated that responded to my search string, so I decided to post it here. OK, currently I have Radius authenticating LDAP users via PAP. Works great. Imagine I want to store x509 certificate data (specifically a client certificate) in an attribute in LDAP (perhaps as a binary attribute, etc). I would like FreeRADIUS, should it be passed a client certificate INSTEAD of a user/pass, to take the DN of the cert and match it to some attribute which contains said DN and cert-data. The ultimate goal of all of this is to allow the continued use of LDAP and store the certificates (to be compared against) in the tree and not on some filesystem basis. Note that I want FreeRADIUS to continue supporting PAP user/pass auth, but only as a secondary fall-back (e.g: customer doesn't have client cert installed on machine, but has a user and password). Is this possible? Does this make sense to you? Let me know if I need to re-explain anything. Thank you, subcon -- View this message in context: http://freeradius.1045715.n5.nabble.com/FreeRADIUS-EAP-TLS-Lookup-Client-Cer... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 10/14/2011 10:43 PM, subcon wrote:
I've searched for this sort of posting, but found issues unrelated that responded to my search string, so I decided to post it here.
OK, currently I have Radius authenticating LDAP users via PAP. Works great.
Imagine I want to store x509 certificate data (specifically a client certificate) in an attribute in LDAP (perhaps as a binary attribute, etc).
I would like FreeRADIUS, should it be passed a client certificate INSTEAD of a user/pass, to take the DN of the cert and match it to some attribute which contains said DN and cert-data.
Ok. It's been a while since I looked at this, but IIRC there is some special search/attribute syntax support in (some) LDAP servers for X.509 certs in the DIT.
The ultimate goal of all of this is to allow the continued use of LDAP and store the certificates (to be compared against) in the tree and not on some filesystem basis.
Note that I want FreeRADIUS to continue supporting PAP user/pass auth, but only as a secondary fall-back (e.g: customer doesn't have client cert installed on machine, but has a user and password).
Is this possible? Does this make sense to you? Let me know if I need to re-explain anything.
I think it should be possible. First, ensure you're running the most recent version of FreeRADIUS. When you've done that, you will have two options: 1. You can examing the "TLS-Client-Cert-Subject" variable in a FreeRADIUS unlang policy, and possibly use this to query your LDAP server via LDAP xlat. For example: authorize { ... eap if (TLS-Client-Cert-Subject) { # we've done enough EAP-TLS to know the client cert update request { Tmp-String-0 := "%{ldap:ldap:///basedn?cn?sub?certsubject=%{TLS-Client-Cert-Subject}}" } if (Tmp-String-0) { # cert was found in LDAP ok } else { reject } } ] However, I'm not certain the TLS-* attributes (see sites-available/default in a recent version of the server) are available in the authorize section - I have a feeling they are only present in post-auth, by which time it's too late to reject them, so... 2. Use the "verify" config of the "tls" module under "eap", and use an external script to perform the check against LDAP. For example: eap { tls { verify { client = "/path/to/script %{TLS-Client-Cert-Filename}" } } } ...then your script can use the (temporary) file given in the 1st argument to query against LDAP. Hope this helps. Cheers, Phil
Thank you,
subcon
-- View this message in context: http://freeradius.1045715.n5.nabble.com/FreeRADIUS-EAP-TLS-Lookup-Client-Cer... Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
This does help greatly, thanks Phil. On Oct 15, 2011, at 4:41 AM, Phil Mayers wrote:
On 10/14/2011 10:43 PM, subcon wrote:
I've searched for this sort of posting, but found issues unrelated that responded to my search string, so I decided to post it here.
OK, currently I have Radius authenticating LDAP users via PAP. Works great.
Imagine I want to store x509 certificate data (specifically a client certificate) in an attribute in LDAP (perhaps as a binary attribute, etc).
I would like FreeRADIUS, should it be passed a client certificate INSTEAD of a user/pass, to take the DN of the cert and match it to some attribute which contains said DN and cert-data.
Ok. It's been a while since I looked at this, but IIRC there is some special search/attribute syntax support in (some) LDAP servers for X.509 certs in the DIT.
The ultimate goal of all of this is to allow the continued use of LDAP and store the certificates (to be compared against) in the tree and not on some filesystem basis.
Note that I want FreeRADIUS to continue supporting PAP user/pass auth, but only as a secondary fall-back (e.g: customer doesn't have client cert installed on machine, but has a user and password).
Is this possible? Does this make sense to you? Let me know if I need to re-explain anything.
I think it should be possible.
First, ensure you're running the most recent version of FreeRADIUS. When you've done that, you will have two options:
1. You can examing the "TLS-Client-Cert-Subject" variable in a FreeRADIUS unlang policy, and possibly use this to query your LDAP server via LDAP xlat. For example:
authorize { ... eap if (TLS-Client-Cert-Subject) { # we've done enough EAP-TLS to know the client cert update request { Tmp-String-0 := "%{ldap:ldap:///basedn?cn?sub?certsubject=%{TLS-Client-Cert-Subject}}" } if (Tmp-String-0) { # cert was found in LDAP ok } else { reject } } ]
However, I'm not certain the TLS-* attributes (see sites-available/default in a recent version of the server) are available in the authorize section - I have a feeling they are only present in post-auth, by which time it's too late to reject them, so...
2. Use the "verify" config of the "tls" module under "eap", and use an external script to perform the check against LDAP. For example:
eap { tls { verify { client = "/path/to/script %{TLS-Client-Cert-Filename}" } } }
...then your script can use the (temporary) file given in the 1st argument to query against LDAP.
Hope this helps.
Cheers, Phil
Thank you,
subcon
-- View this message in context: http://freeradius.1045715.n5.nabble.com/FreeRADIUS-EAP-TLS-Lookup-Client-Cer... Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
subcon wrote:
Imagine I want to store x509 certificate data (specifically a client certificate) in an attribute in LDAP (perhaps as a binary attribute, etc).
That's outside of the scope of FreeRADIUS.
I would like FreeRADIUS, should it be passed a client certificate INSTEAD of a user/pass, to take the DN of the cert and match it to some attribute which contains said DN and cert-data.
That's possible. See raddb/sites-available/default in recent releases. Look for the "TLS-*" comments in the post-auth section.
The ultimate goal of all of this is to allow the continued use of LDAP and store the certificates (to be compared against) in the tree and not on some filesystem basis.
That's thinking about it wrong. You don't "compare" certificates. You verify certificates against a CA. You check certificates against a revocation list.
Note that I want FreeRADIUS to continue supporting PAP user/pass auth, but only as a secondary fall-back (e.g: customer doesn't have client cert installed on machine, but has a user and password).
For what kind of system? Wireless, or wired?
Is this possible? Does this make sense to you? Let me know if I need to re-explain anything.
You need to correct your thinking and your vocabulary. Certificates don't work the way you seem to think. Alan DeKok.
On Oct 15, 2011, at 12:41 PM, Alan DeKok wrote:
subcon wrote:
Imagine I want to store x509 certificate data (specifically a client certificate) in an attribute in LDAP (perhaps as a binary attribute, etc).
That's outside of the scope of FreeRADIUS.
Obviously. I had not actually said the word FreeRADIUS nor RADIUS at that time yet.
I would like FreeRADIUS, should it be passed a client certificate INSTEAD of a user/pass, to take the DN of the cert and match it to some attribute which contains said DN and cert-data.
That's possible. See raddb/sites-available/default in recent releases. Look for the "TLS-*" comments in the post-auth section.
The ultimate goal of all of this is to allow the continued use of LDAP and store the certificates (to be compared against) in the tree and not on some filesystem basis.
That's thinking about it wrong. You don't "compare" certificates. You verify certificates against a CA. You check certificates against a revocation list.
Lets assume I do. I never said this was going to be by the book.
Note that I want FreeRADIUS to continue supporting PAP user/pass auth, but only as a secondary fall-back (e.g: customer doesn't have client cert installed on machine, but has a user and password).
For what kind of system? Wireless, or wired?
This is for authentication for systems that already use Radius for these things (currently works via PAP -> LDAP). These are Linux servers people log into via one or more protocols, and do not involve wireless APs or anything like that.
Is this possible? Does this make sense to you? Let me know if I need to re-explain anything.
You need to correct your thinking and your vocabulary. Certificates don't work the way you seem to think.
Certificates will work the way I tell them to. I have done things similar (without involving Radius) for some unusual systems I work on. I this case, perhaps I should have referred to them as pseudo-certificates, wherein its just a REALLY long password that is presented from the client-end via file instead of being entered like a "normal" password. I really liked Phil Mayers reply, gave me a few good ideas on where to start. Thanks to you both J
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Jeff Doyle -
Phil Mayers -
subcon