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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
