Tricky problem with ldap and primary groups in AD

Franks Andy (RLZ) IT Systems Engineer Andy.Franks at sath.nhs.uk
Thu Aug 2 15:18:50 CEST 2012


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.

Good old M$. Delightfully different.

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

Just FYI, wanted to avoid this because it allows logon to systems that
depend on the Domain Users group for authorisation, of which we
unfortunately have quite a few

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

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
box". Is there a list of these built-in control attributes somewhere?
Haven't seen them in the files/manuals I've been looking at so far, but
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?

> 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?

	Yes, it's what I talk about in option 3, - there's a translation
in data type from integer to byte apparently to translate from one to
the other, although I haven't looked into it massively - you've
mentioned more of the detail below.

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

	Perhaps using the perl / python modules might yield something,
although haven't even looked at how those are used. I suppose I could
also statically call a exec program but guess that would be quite
costly.

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

Need to look into drawing data down from a SQL server. It makes sense
that the data is stored there, perhaps as a copy. We'd use the AD to
enable / disable computers which we don't want users to connect to the
wireless with any longer. OTOH, it would sort the security issue of a
usernames existing that have immediately guessable passwords. I'm moving
from NPS towards freeradius, all of this wasn't possible and so it's
good to thing "out of the box" a bit!

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

This is interesting - apparently, according to the smoothwall company
who provide our web proxy solution the new version of samba can look up
groups "properly" from AD and cope with this issue, but again something
to research a bit.

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

No idea this existed, I'll have a look into it too.

	>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

Thanks Phil, that's really helpful - thanks again for taking the time to
respond.

Andy


More information about the Freeradius-Users mailing list