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