So I have the magic triangle system working at present.There is a slight issue with Nested AD groups in OD Groups. The problem seems to be that becuase the AD group I am nesting is, for the users of that group, their 3rd AD group – they cannot login.
The thing is, as I understand it, all AD users will have DOMAIN\domain users as their primary group, and therefore the group I want to target will always fail to be the Primary GID.
From what I’ve read nested AD groups should not be a problem, but perhaps it is on the Tiger Server side? I’m running Tiger Server 10.4.7.
Anyone else have these problems, as I’m not particularly pleased about adding each user manually to my OD groups.
The problem could be if the user(s) is a member of 16 or more groups. This was fixed in 10.4.8 Server.
I can’t post links here, but 2 bullet points in the 10.4.8 update of interest:
– membership and permissions issues when Windows users are in more than 16 groups
– login and authentication in Open Directory and Active Directory environments
I have a similar setup, all users primary GID is domain users and I restrict logins in certain labs to the members of that lab and it works fine for me with 10.4.8 server. I don’t recall if I was restricting logins when we had 10.4.7.
Thanks for that, now I do recall that 16 group problem, so I shall ask the Windows Admins on Monday. And it’s probably a good time to update the server anyway.
You probably don’t need to ask the Windows admin. Just do an “id [i]shortname[/i]” for a domain user and count the # of AD groups they are a member of.
I’m going to bump this as until now I’ve been able to live with manually adding AD users to OD groups, but it is becoming unwieldy. Still not sure what you mean (Joel) by OS X Machine Accounts. Do you mean the Computer Objects in AD or the account I use to join/bind to the domain? Or none of those.
Does anyone know why I can’t get nested AD groups in my OD groups working. I’m running Server 10.4.11 and client 10.4.11. OD Group is called AD_TEST and AD Group is called DOMAIN\kt students
Hi there. I have the same problem in 10.4.11 Server. I have a support contract, so contacted Apple. Don’t shoot the messenger here…
[quote]The group nesting issue, is something that we have seen before and engineering has deemed fixed in Leopard. This is not something that is/will be addressed in Tiger, and is expected to work in Leopard by at least 10.5.3.
Thanks,
AppleCare Enterprise Customer Support Engineering[/quote]
Right, that’s me setting up a test Leopard Server partition when 10.5.3. hits. The message does take the tone that the fault lies at Apple’s feet, but seems contrary to what others have said here, that nested groups works as of 10.4.3 Tiger.
I can affirm that it is possible that the machine account of the OS X (Tiger and Leopard) system may not have rights to read the group membership of the AD group.
In a not-too-customized AD implementation, this should *not* be an issue. It is rare that AD admins would get into the level of permissions detail that would interfere with computer accounts reading the properties of Users and Groups. As it happens, I live under such an implementation.
To check this you need a)the computer account name in AD of the OS X client; b) the name of the AD Group in question and c) a user login that has rights to read the properties of Group.
On a windows machine, log in and open Active Directory Users and Computers.
Search for the Group name, right click on it and select properties.
Select the Security Tab
Click the Advanced Button
Select the Effective Permissions Tab
Click the Select button
Click the Object Types button
Check the box next to Computers
Enter the name of the computer account
Click Ok
in the (long) list of properties the computer account needs either:
List Contents
Read All Properties
Read Permissions
or (if Read All Properties is unchecked)
List Contents
Read Permissions
Read gidNumber
Read groupType
Read Members
Read memberUID
Anybody ever get any joy with this? I have this same issue raised in another thread.
Neither my X-Serve nor clients can read the short name or UID of members of any AD group other than Domain Users when viewing from Workgroup Manager and therefore I cannot deploy any managed preferences to these groups.
I have checked the permissions mentioned above and all my clients and server have the relevant permissions.
I really dont want to get into havign to manually manage individual users as I work in an education environment where the members of my groups are changing on a daily basis.
Comments are closed