prevent ldap from searching for groups
I am using rlm_ldap (2.0.0-pre2) to check an account for being valid in AD. This works. As I am only interested in one attribute from AD, it would be sufficient, if rlm_ldap would only use "filter" to dive into AD once. How could I prevent rlm_ldap from "Entering ldap_groupcmp()" ? Setting groupname_attribute = NULL groupmembership_filter = NULL only results in an error message "Bad search filter" ..... rlm_ldap: looking for check items in directory...^M rlm_ldap: LDAP attribute primaryGroupID as RADIUS attribute Group-Name == "515"^M rlm_ldap: looking for reply items in directory...^Mrlm_ldap: user host/28tef004.ww006.mycomany.net authorized to use remote access^M rlm_ldap: ldap_release_conn: Release Id: 0^M ++[ldap] returns ok^M How to prevent entering this function?? rlm_ldap: Entering ldap_groupcmp()^M expand: DC=MYCOMPANY,dc=NET -> DC=MYCOMPANY,dc=NET^M expand: NULL -> NULL^M ..... Norbert Wegener
Norbert Wegener wrote:
As I am only interested in one attribute from AD, it would be sufficient, if rlm_ldap would only use "filter" to dive into AD once. How could I prevent rlm_ldap from "Entering ldap_groupcmp()" ?
Don't reference the LDAP-Group attribute? The only time that the ldap_groupcmp() function is called is when the LDAP-Group attribute is used. Alan DeKok.
I get an attribute/value from ad via freeradius and want this as a checkitem in another module. Therefore I added checkItem User-Password primaryGroupID := to ldap.attrmap and have the following users: DEFAULT User-Password == "wrong” Service-Type = Framed-User, Tunnel-Type:1 = VLAN, Tunnel-Medium-Type:1 = IEEE-802, Tunnel-Private-Group-ID = VL-SBS-AD02-0001, DEFAULT User-Password == "515” Service-Type = Framed-User, Tunnel-Type:1 = VLAN, Tunnel-Medium-Type:1 = IEEE-802, Tunnel-Private-Group-ID = VL-SBS-AD02-0002, radiusd -AX says: ... rlm_ldap: looking for check items in directory...^M rlm_ldap: Adding primaryGroupID as User-Password == "515"^M The 515 is form AD and for me its seems to be what I expect. rlm_ldap: looking for reply items in directory...^M rlm_ldap: user host/28tef004.ww006.mycompany.net authorized to use remote access^M rlm_ldap: ldap_release_conn: Release Id: 0^M modcall[authorize]: module "ldap" returns ok for request 11^M users: Matched entry DEFAULT at line 2^M Now I would assume, User-Password == "515" is added to the list of checkitems. Nevertheless the first DEFAULT Entry of the users file is taken. What am I missing? The complete typescript is at http://www.wegener-net.de/freeradius/typescript Thanks Norbert Wegener
Alan DeKok wrote:
...
Repeat after me: Cleartext-Password :=
If it helps :-) Before posting I tried nearly everything, including the use of Cleartext-Password := in ldap.attrmap and the users file. Unfortunately the result was always the same ... add checkItem Cleartext-Password primaryGroupID := to ldap.attrmap users: DEFAULT Cleartext-Password := "wrong” Service-Type = Framed-User, Tunnel-Type:1 = VLAN, Tunnel-Medium-Type:1 = IEEE-802, Tunnel-Private-Group-ID = VL-SBS-AD02-0001, DEFAULT Cleartext-Password := "515” Service-Type = Framed-User, Tunnel-Type:1 = VLAN, Tunnel-Medium-Type:1 = IEEE-802, Tunnel-Private-Group-ID = VL-SBS-AD02-0002, radiusd -AX (1.1.7) ... rlm_ldap: looking for check items in directory...^M rlm_ldap: Adding primaryGroupID as Cleartext-Password == "515"^M rlm_ldap: looking for reply items in directory...^M rlm_ldap: user host/28tef004.ww006.mycompany.net authorized to use remote access^M rlm_ldap: ldap_release_conn: Release Id: 0^M modcall[authorize]: module "ldap" returns ok for request 11^M users: Matched entry DEFAULT at line 2^M ..... Again, the complete output at http://www.wegener-net.de/freeradius/typescript
Fix this everywhere. Then try it again.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Norbert Wegener wrote:
rlm_ldap: looking for check items in directory... rlm_ldap: Adding primaryGroupID as Cleartext-Password == "515"
OK...
modcall[authorize]: module "ldap" returns ok for request 11 users: Matched entry DEFAULT at line 2
Yes... because you are telling the server what the clear-text password is supposed to be. If you tell the server TWICE, it will say OK twice. What sort of behavior do you expect? "If cleartext password is already set, don't set it again" ? Nothing in the ldap or users file documentation says that they do anything like that. If you want that functionality, see 2.0. Alan DeKok.
Alan DeKok wrote:
Norbert Wegener wrote:
rlm_ldap: looking for check items in directory... rlm_ldap: Adding primaryGroupID as Cleartext-Password == "515"
OK...
modcall[authorize]: module "ldap" returns ok for request 11 users: Matched entry DEFAULT at line 2
Yes... because you are telling the server what the clear-text password is supposed to be. If you tell the server TWICE, it will say OK twice.
Telling it twice in a check item? Please correct me, but my understanding of check items has been, that they have to be in the the access request to match an entry. The clear-text password is not in the original request. It is added during the processing of that request via ldap. Depending on that value an entry of the users file should match. I do not yet see, where myunderstanding is wrong. Norbert Wegener
What sort of behavior do you expect? "If cleartext password is already set, don't set it again" ? Nothing in the ldap or users file documentation says that they do anything like that.
If you want that functionality, see 2.0.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Norbert Wegener wrote:
Yes... because you are telling the server what the clear-text password is supposed to be. If you tell the server TWICE, it will say OK twice.
Telling it twice in a check item?
Yes. You told the server what the "known good" password was.
Please correct me, but my understanding of check items has been, that they have to be in the the access request to match an entry.
No. Read "man users", or the comments at the top of the "users" file. The check items hold BOTH the comparison against the original password, AND the instructions for how the server should behave. This is BROKEN, because it confuses people. 2.0 has a more complex configuration. But it's a LOT easier to understand why it works.
The clear-text password is not in the original request. It is added during the processing of that request via ldap.
Yes. So?
Depending on that value an entry of the users file should match.
No. Read "man users". Cleartext-Password is a configuration attribute. It is NOT an attribute that goes into a packet. In 2.0.0-pre2, see "man unlang". Alan DeKok.
Alan DeKok wrote:
Norbert Wegener wrote:
Yes... because you are telling the server what the clear-text password is supposed to be. If you tell the server TWICE, it will say OK twice.
Telling it twice in a check item?
Yes. You told the server what the "known good" password was.
Please correct me, but my understanding of check items has been, that they have to be in the the access request to match an entry.
No. Read "man users", or the comments at the top of the "users" file.
The check items hold BOTH the comparison against the original password, AND the instructions for how the server should behave. This is BROKEN, because it confuses people.
2.0 has a more complex configuration. But it's a LOT easier to understand why it works.
Maybe I should have taken a look at unlang before. Using it solved my problem nearly immediately. Norbert Wegener
The clear-text password is not in the original request. It is added during the processing of that request via ldap.
Yes. So?
Depending on that value an entry of the users file should match.
No. Read "man users".
Cleartext-Password is a configuration attribute. It is NOT an attribute that goes into a packet.
In 2.0.0-pre2, see "man unlang".
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Norbert Wegener