redundant LDAP-Group
Hi, I know this has been covered in the archives, and the news is generally not good, but my users file currently looks like: ---- DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login1-LDAP-Group == it-switch-admin Service-Type = Administrative-User DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login2-LDAP-Group == it-switch-admin Service-Type = Administrative-User DEFAULT NAS-Identifier == switch, Huntgroup-Name == cisco, NAS-Port-Type == Virtual, ldap_login1-LDAP-Group == it-switch-admin Service-Type = NAS-Prompt-User, Cisco-AVPair = "shell:priv-lvl=15" DEFAULT NAS-Identifier == switch, Huntgroup-Name == cisco, NAS-Port-Type == Virtual, ldap_login2-LDAP-Group == it-switch-admin Service-Type = NAS-Prompt-User, Cisco-AVPair = "shell:priv-lvl=15" DEFAULT NAS-Identifier == switch, Auth-Type := Reject ---- In my global configuration I have: ---- instantiate { ldap_login1 ldap_login2 redundant-load-balance ldap-login { ldap_login1 ldap_login2 } ldap_lanwarden1 ldap_lanwarden2 redundant-load-balance ldap-lanwarden { ldap_lanwarden1 ldap_lanwarden2 } } ---- It would be really nice to fold those duplicate LDAP-Group lines into 'ldap_login-LDAP-Group', however alas FreeRADIUS does not love me: ---- /etc/freeradius/LOCAL/users-login[1]: Parse error (check) for entry DEFAULT: Invalid octet string "it-switch-admin" for attribute name "ldap_login-LDAP-Group" Errors reading /etc/freeradius/LOCAL/users-login /etc/freeradius/LOCAL/modules.conf[1]: Instantiation failed for module "files-login" /etc/freeradius/sites-enabled/login[72]: Failed to load module "files-login". /etc/freeradius/sites-enabled/login[35]: Errors parsing authorize section. ---- This 'redundant' LDAP-Group problem often crops up, unfortunately it is way above my head to resolve. Another "moon-on-a-stick" feature is that I have two sets of LDAP servers configured[1], in my authorise section I have: ---- authorize { ... ldap-login if (!ok) { reject } files ... } ---- If I instead simply use 'LDAP-Group' in the users file, 'ldap-lanwarden' is invoked (rather than me expecting a contination of the last used LDAP server)... Is this a bug or a 'feature'? Cheers [1] ldap_login[12] -> ldap_login, ldap_lanwarden[12] -> ldap_lanwarden -- Alexander Clouter .sigmonster says: An idea is not responsible for the people who believe in it.
On Thu, Dec 02, 2010 at 11:54:28AM +0000, Alexander Clouter wrote:
DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login1-LDAP-Group == it-switch-admin DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login2-LDAP-Group == it-switch-admin
instantiate { ldap_login1 ldap_login2
This sounds like you're comparing attributes called "ldap_login1-LDAP-Group" and "ldap_login2-LDAP-Group". Presumably these are generated with those distinct names, by your two LDAP module instances. How do the definitions of those two look like? IOW have you tried using a common LDAP attribute map in both? -- 2. That which causes joy or happiness.
Josip Rodin <joy@entuzijast.net> wrote:
DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login1-LDAP-Group == it-switch-admin DEFAULT NAS-Identifier == switch, Huntgroup-Name == allied-telesis, ldap_login2-LDAP-Group == it-switch-admin
instantiate { ldap_login1 ldap_login2
This sounds like you're comparing attributes called "ldap_login1-LDAP-Group" and "ldap_login2-LDAP-Group". Presumably these are generated with those distinct names, by your two LDAP module instances.
How do the definitions of those two look like? IOW have you tried using a common LDAP attribute map in both?
http://wiki.freeradius.org/Rlm_ldap#Group_Support Cheers -- Alexander Clouter .sigmonster says: Screw up your courage! You've screwed up everything else.
On 02/12/10 11:54, Alexander Clouter wrote:
It would be really nice to fold those duplicate LDAP-Group lines into 'ldap_login-LDAP-Group', however alas FreeRADIUS does not love me: ---- /etc/freeradius/LOCAL/users-login[1]: Parse error (check) for entry DEFAULT: Invalid octet string "it-switch-admin" for attribute name "ldap_login-LDAP-Group" Errors reading /etc/freeradius/LOCAL/users-login
AFAICT this doesn't really work because of the way the attributes comparisons are actually handled. You probably know this, but: Basically when a copy of the "ldap" module is instantiated, it registers a "paircompare" handler for the global "LDAP-Group", then if the module is named: 1. Registers a new attribute "modname-LDAP-Group" 2. Registers a "paircompare" handler for that attribute The "redundant" construct has no way to know about this; the "ldap" module(s) are instantiated (and the attribute/comparisons registered) completely separately from the redundant{} processing. Similar problems hold for the %{modname:} xlat stuff; modules can potentially register any xlat they like, and the modgroup code doesn't know about that. In addition, the "paircompare" handlers currently don't return an error status; they just return an integer, 0 meaning "equality", so a redundant paircompare would have no way of distinguishing a "LDAP OK, user not in group" from "LDAP down, try next module", and would end up querying both LDAP modules much of the time.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
It would be really nice to fold those duplicate LDAP-Group lines into 'ldap_login-LDAP-Group', however alas FreeRADIUS does not love me: ---- /etc/freeradius/LOCAL/users-login[1]: Parse error (check) for entry DEFAULT: Invalid octet string "it-switch-admin" for attribute name "ldap_login-LDAP-Group" Errors reading /etc/freeradius/LOCAL/users-login
AFAICT this doesn't really work because of the way the attributes comparisons are actually handled.
Was wondering if someone out there knew of a neater way to do this? Twas all. Cheers -- Alexander Clouter .sigmonster says: He who has a shady past knows that nice guys finish last.
On 02/12/10 13:14, Alexander Clouter wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
It would be really nice to fold those duplicate LDAP-Group lines into 'ldap_login-LDAP-Group', however alas FreeRADIUS does not love me: ---- /etc/freeradius/LOCAL/users-login[1]: Parse error (check) for entry DEFAULT: Invalid octet string "it-switch-admin" for attribute name "ldap_login-LDAP-Group" Errors reading /etc/freeradius/LOCAL/users-login
AFAICT this doesn't really work because of the way the attributes comparisons are actually handled.
Was wondering if someone out there knew of a neater way to do this?
Ah I see. I was thinking you might be able to do something with the ldap xlat: update control { My-Group-Staff = "%{ldap1:...}" } if (!control:My-Group-Staff) { update control { My-Group-Staff = "%{ldap2:...}" } } or: update control { My-Group-Staff = "%{%{ldap1:..}:-%{ldap2:...}}" } ...but sadly again, the ldap xlat doesn't return an error code, just 0 so it's impossible to distinguish between no match and error, and you'll end up hitting the "ldap2" module a lot when you don't need to. Hmm. Tricky. How about a pair of ldap modules and creative use of the ldap.attrmap, so something like: checkItem My-Group memberOf += ...then: policy { myldap { ldap1 if (fail) { ldap2 } } } ...then: authorize { myldap if (control:My-Group == Staff) { # something } } Alternatively, how about: policy { myldap { update request { Module-Failure-Message !* 0x00 My-Group = "%{ldap1:...}" } if (Module-Failure-Message) { update request { My-Group = "%{ldap2:...}" } } } }
On 02/12/10 14:49, Phil Mayers wrote:
Alternatively, how about:
policy { myldap { update request { Module-Failure-Message !* 0x00 My-Group = "%{ldap1:...}" } if (Module-Failure-Message) {
Nah, this won't work sorry - I was misreading the rlm_ldap.c code, Module-Failure-Message is only set by ldap_authorize on NOTFOUND, not FAIL and not in perform_search()
participants (3)
-
Alexander Clouter -
Josip Rodin -
Phil Mayers