Greetings, A few more questions :) I've now gone through the book ( I feel like such a snob reading it on the bus ==) and have a better understanding of how Freeradius works. I have gotten it to search for an attribute in LDAP and return it the NAS. What I would like to do is to have it be able to query the memberOf attribute in the acrtive directory server and then verify if the user is in any of those groups and than permit access based on that membership. Heres what im wondering a) When I query the attribute it returns multiple cn=... results. In the debug log I see it setting this as xxx.xxxx which is understood by our nas equipment. It does it four times, But in the reply packet I only see it sending one and not four. Am I correct to assume that it will only send one of the responses to the Nas. b) I think I can use the Users file to determine which group the user is a member of and then have it send an attribute back to the Nas telling it which role to set. Is the the attribute returning multiple groups a problem (not multiple attributes, one attribute several bits of data seperated by a delimiter) ? c) can I strip the leading cn= bit from the response the ldap server sends ( I saw an article somewhere about using an operator in the LDAP.attrmap file) and once thats done can it use the groups returned in the users file? Thanks! Liz
liz wrote:
What I would like to do is to have it be able to query the memberOf attribute in the acrtive directory server and then verify if the user is in any of those groups and than permit access based on that membership.
The "memberOf" attribute (groups on the user entry) is supported by the "groupmembership_attribute" config item, which it seems from reading the code is ONLY consulted AFTER the searches for group objects returns no values. Since AD maintains the group objects and the memberOf in concert, you'll never reach there. The "Ldap-Group" support allows you to check if a user is in a group at the server, and works like so (you probably know this): DEFAULT Ldap-Group = "shortname" Or: DEFAULT Ldap-Group = "cn=shortname,ou=path,dc=domain,dc=com" If you use the first form, the search that's done is: base: standard LDAP baseDN filter: cn=shortname AND (GROUPMEMBERSHIP_FILTER) If you use the 2nd form, the search that's done is: base: cn=shortname,ou=path,dc=domain,dc=com filter: GROUPMEMBERSHIP_FILTER GROUPMEMBERSHIP_FILTER being the config item of the same name in the radiusd.conf - in the case of AD, an appropriate config is: groupmembership_filter = "(&(objectClass=group)(member=%{Ldap-UserDn}))" As I say, only after those searches have been done and returned no entries is memberOf consulted, which will never happen for an AD LDAP server. But the results of looking up the group entry versus looking up memberOf on the user entry should be identical.
Heres what im wondering
a) When I query the attribute it returns multiple cn=... results. In the debug log I see it setting this as xxx.xxxx which is understood by our nas equipment. It does it four times, But in the reply packet I only see it sending one and not four. Am I correct to assume that it will only send one of the responses to the Nas.
I'm not sure I understand this part - could you expand on it? How are you putting the LDAP groups into the reply (that's not the normal use-case - you would normally do group-based checks at the server rather than the NAS, not that there's anything wrong with the latter)
b) I think I can use the Users file to determine which group the user is a member of and then have it send an attribute back to the Nas telling it which role to set. Is the the attribute returning multiple groups a problem (not multiple attributes, one attribute several bits of data seperated by a delimiter) ?
When doing LDAP group checks at the server side, you would normally have something like (examples using the long/DN form for group - you can just put the short name, see above): DEFAULT Ldap-Group == "cn=nasadmin,dc=domain,dc=com" NAS-Role = "Administrator" DEFAULT Ldap-Group == "cn=nasoper,dc=domain,dc=com" NAS-Role = "Operator" DEFAULT Auth-Type := Reject Reply-Message = "You are not able to admin the NAS" The fact the user may be in >1 group is not a problem - the LDAP search looks for the user and the group combination.
c) can I strip the leading cn= bit from the response the ldap server sends ( I saw an article somewhere about using an operator in the LDAP.attrmap file) and once thats done can it use the groups returned in the users file?
I'm not sure I understand this. The rlm_ldap module does not by default put the groups into the reply. Via the "ldap.attrmap" entry you can put anything you like into the reply, but modifying the value that comes out of the LDAP server is non-trivial. If you could describe more precisely what you're trying to do I may be able to give a more specific answer.
Phil Mayers wrote:
If you could describe more precisely what you're trying to do I may be able to give a more specific answer.
Actually I've just had a quick look at your earlier email and it's a bit clearer what you want to do - take NT groups from AD via LDAP, send them to your Aruba after stripping the name from cn=<name>,ou=path and have it process them - correct? You could do this: ldap.attrmap: # append memberOf to radius reply as Whatever-Attribute replyItem Whatever-Attribute memberOf += radiusd.conf: modules { # bulk of modules, then ldap { # ldap config } # chop end off attr_rewrite stripGroupDn1 { attribute = Whatever-Attribute searchin = reply searchfor = ",.*" replacewith = "" ignore_case = yes new_attribute = no max_matches = 1 append = no } # chop start off attr_rewrite stripGroupDn2 { attribute = Whatever-Attribute searchin = reply searchfor = "^cn=" replacewith = "" ignore_case = yes new_attribute = no max_matches = 1 append = no } # rest of modules } authorize { preprocess ldap stripGroupDn1 stripGroupDn2 files } # rest of radiusd.conf ...however, you'll need CVS HEAD for the ldap.attrmap 4th item (operator) and for fixes to the extraction of replyItems from LDAP attributes - or the (scantily tested) backport I've just written to 1.1.0 (attached)
participants (2)
-
liz -
Phil Mayers