darrell hershberger writes: > Is it possible to have only one LDAP entry per account, and have all > five email addresses listed in the entry, and have separate passwords > for each, and be able to authenticate each email address when the > client logs in via RADIUS?
LDAP-wise it's possible if your Radius implementation authenticates clients by reading the password from the LDAP server and checking it. FreeRadius does that, I don't know about others (or if the Radius spec requires this or not). If so it's just a matter of whether or not your Radius implementation supports this. Radius would need to do either: search for (email1=address) requesting attribute password1 ... search for (email5=address) requesting attribute password5 or search for (|(email1=address)...(email5=address)) requesting attributes password1...password5, then check which address matched the searched-for address and check the corresponding password. Note that most clients authenticate in what is normally a more secure and sensible way: With the Bind operation - so the server rather than the client will check the password. Clients which do that can't authenticate against such entries, since you can't tell Bind which password attribute to use. Otherwise you can 5 entries, each with one address and one password, and have an attribute in each with the DN of the owner's entry. Or make them subordinates of the owner's entry, so you find the owner by reading their parent entry. Depends on what you need to know of the owner. If the above is not feasible, you can (at least with OpenLDAP) instead set up the server to provide 5 extra views of the directory tree, each under its own DN: One where email1 and password1 are renamed to email and password, one where email2 and password2 are so renamed, and so on. See the slapd-relay and slapo-rwm manpage (or slapd-ldap or slapd-meta). Make them subordinates to a common root entry (with the 'subordinate' keyword described in 'man slapd.conf'). Possibly you'll wish to hide the other mail/password attributes, either with access controls or by not mirroring those attributes in these other views. Now you can search from that root entry for "(email=address)", requesting attribute password. Or if you authenticate with Bind, search for (email=address) to get the DN, then Bind to that DN with the password. If so the exposed password attribute should be called userPassword. There may be other ways to do it, but that's the one which occurred to me. -- Regards, Hallvard --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
