Tricky problem with ldap and primary groups in AD

[Phil Mayers]

On 08/01/2012 10:52 PM, Franks Andy (RLZ) IT Systems Engineer wrote:

> user on a specific client machine. The Ldap-Group doesn’t see the
> primary group as it’s set to do a“memberof” lookup. Other groups are
> seen fine.

Yes. Sadly this is an AD-specific behaviour, and there's no way to 
change it. It's EXTREMELY unhelpful in cases like this.

>
> There are3 ways I can seethis working :
>
> 1) Get theLDAPbods to assign a different primary groupand use the other
> group to dictate vlan membership. We’ve 5000 odd clients so this isn’t
> my favourite.

FWIW, the way we "solve" this at our site is to ensure that "Domain 
Users" is the primary group for all accounts.

However, we don't store dummy users for MAC auth in AD.

>
> 2) Check the primarygroupid attribute out by mapping it using
> ldap.attrmap and attributes in the dictionary file, but then as far as I
> can tell I can’t use these as checkitems within the users file. It’s

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
   }
   ...
}

> also tedious to have to know the primarygroupIDsfor each group. I’d

It is. I assume you're familiar with SIDs and RIDs, and what these 
values mean?

> quite like the users file to be the main source of passing radius
> attributes back to clients, but there may be another way?
>
> 3) Something else a bit more clever. I’ve seen various examples of java
> / vb.net/php etc ways of taking the primarygroupid, changing it’s data
> type and thus finding the group name, which could then maybe be passed
> back to the users file. I have absolutely no idea here.

Not quite sure what you mean here.

To convert a primaryGroupId to a group name, you need to:

  1. Extract the domain SID for the forest you are querying
  2. Append the group ID (RID)
  3. Convert to binary
  4. Perform an LDAP binary search

This is fairly tedious. I'd avoid it, if possible, and I'm 99% sure you 
couldn't do it inside FreeRADIUS using the existing LDAP code.

A few other solutions you might consder:

4) Don't store the MAC address "users" in AD; put them in an SQL DB 
accessible (better yet, *on*) the RADIUS servers. If you really want to 
master them in AD, maybe use a periodic LDAP query to copy the data from 
AD into SQL.

5) See if the group checking via "wbinfo" / winbind can work for you. 
This should, IIRC, give primary as well as nested groups back. However, 
it'll be slow (since you'll have to exec "wbinfo" on each auth) and 
non-standard - probably tricky to setup.

6) If it's available to you, see if the "virtual LDAP server" stuff in 
newer AD can help; it might be able to present a "clean" LDAP view of 
your data without the Microsoft-isms. I can't remember what this 
functionality is called, but IIRC it needs Win 2008 (R2?) to use.


There are probably more options. But if you really want to store the 
data in AD, the simplest solution is to change the primary group to a 
dummy one that you don't care about.

In some places at our site, we have code that queries all users and 
flattens nested groups, then resolves primaryGroupId. My advice would be 
to avoid that.

Cheers,
Phil