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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
