Re: Tricky problem with ldap and primary groups in AD

2 Aug 2012

      On 02/08/12 14:18, Franks Andy (RLZ) IT Systems Engineer wrote:
...
...
Correct. You can however check them in "unlang"
authorize {
  ...
 ldap
  if (Ldap-Group == mygroup) {
    # they're a member via memberof
    ...
  }
  elif (control:Ldap-PrimaryGroupId == 1234) {
    # assuming 1234 is the RID for "mygroup"s SID
    # they're a member via primaryGroupId
    ...
  }
  else {
    reject
  }
  ...
}
That's fantastic - this example is really helpful. I'd been playing
around with putting an entry into the dictionary file for a custom
attribute then using ldap.attrmap to map it up to the primaryGroupId -
didn't realise you could just reference Ldap-PrimaryGroupId "out of the
Sorry, I've confused matters a bit.

The above example assumed you have defined and populated a custom 
attribute. There is no built-in Ldap-PrimaryGroupId.

Since the "ldap.attrmap" restricts you to check (a.k.a. control) and 
reply items, you would need something like this:

raddb/dictionary:

ATTRIBUTE	Ldap-PrimaryGroupId	3010	integer

raddb/ldap.attrmap:

checkItem	Ldap-PrimaryGroupId	primaryGroupId

...but it sounds like you're familiar with that technique.
...
then it's quite new to me. I can see Ldap-Group and
Ldap-UserDn but not Ldap-PrimaryGroupId. Maybe it's inferred that I use
an ldap.attrmap entry?
No, as above it's not built-in. You need to define & map it yourself. 
Sorry for the confusion.

Re: Tricky problem with ldap and primary groups in AD

Phil Mayers