Tricky problem with ldap and primary groups in AD

[Phil Mayers]

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.