AD Group Permissions Ignored

[taco]

My Setup-
XServe G5 w/4GB RAM
Mac OS X Server 10.4.8
XServe RAID – all shares here, only boot disk in XServe
Bound to AD
Qualified Domain Name
Time Synced from Cisco NTP router
Kerberized principals (AFP, SMB, Web, et.al)
Using POSIX permissions, not ACLs
55 users on 10.3.9 and 10.4.8, all bound to AD using local homes.
Using AD Groups and AD UIDs
Use a PC to configure AD Groups and Users in my OU
On AFP, I’ve got permissions set to inherit from enclosing folder.
No AFP or SMB guest access

My Problem –
First I read the AFP 548 white paper on AD-OD integrattion. It’s nice, but does not really address what’s going on with me. I’m totally dependent on AD and am not using OD at all. Over time since I first bound this Xserve this Sept., I’ve noticed that AD groups are partially starting to get ignored. Owner and everyone rights are recognized. Where I restrict access to specific folders using different groups from the parent folder is where I’m seeing trouble. There is this one user who calls me daily saying he can get/see the contents of a share point from AFP, but under that the contents of nested folders look blank – like nothing is there. I’ve tried several things to remedy this.

In WGM –
-propagated permission over effected folders

-checked with Effective Permissions Inspector

From Terminal –
-done the ‘sudo managed -r’ command to server clear group cache (this worked under a ODM server, but on AD, ?)

-checked using the id command — this showed weird results in that the server does not see the user’s group from which I am assigning the folders. But if I go to a 10.3.9 Mac which is bound to AD and use the id command, I can see that that user is assigned to that group! Also WGM and the AD tool I use on a PC show that that user is assigned to that group.

I read about something that when a user is assigned to 16 or more AD groups, Mac OS X Server goes ga ga.
I’m going to count the groups this users has and report that here.

This is a common problem with Mac OS X Server. I’ve read about it on afp548, but steps to fix are hard to find.

[taco]

[QUOTE][u]Quote by: taco[/u]
I read about something that when a user is assigned to 16 or more AD groups, Mac OS X Server goes ga ga.
I’m going to count the groups this users has and report that here.
[/QUOTE]

The Mac user in question currenlty belongs to 23 AD groups.
I found others with the same number who have yet to make a complaint. This user is ‘cursed.’
😡

[taco]

Today, in a preemptive move, I went to IT and asked them to remove the user from our group that I use to give everyone access to the share — then add him back to the same AD group. They have the power to refresh the AD and I don’t so I thought this would help. I did the id command in the Terminal 2 hours after this request on a Mac OS 10.3.9 Mac, a Mac OS 10.4.8 Mac and the XServe. All did not show that the user had been added to the needed group for my XServe share. But WGM showed the user WAS a member of the group. This afternoon the user emailed me AGAIN saying he could not get into folder X under the parent share. He could see folders under the parent share, but when he wanted to go to the folder X, he saw nothing. The folder had restricted access — Admin – rw, AD Group- rw, and Everyone – no access. I heard that making a local XServe group from AD UIDs was a possible troubleshooting method. So I killed the AD group in my OU that had special access to folder X, then created a local group on the XServe and populated it with the AD users. I was one of the users to add to the new local group. In WGM I then used Effective Permissions Inspector to confirm the user had the proper access. It checked out. I logged in to my eMAc and could see the contents of folder X. I went to his desk, asked him to restart his eMac. He logged in (AFP) and navigated to folder X – NOTHING. This whacked me out! I then decided to move the folder from the parent folder (that was the share point) and move it to the XServe RAID root directory as its own share. I thought this might kill any influence the original share point was having to the user’s rights. I shared folder X AFP, SMB only with no guest access. I again checked the user’s permissions using EPI – he checked out. On his eMac this time (AFP) the same result – NOTHING.

I saw his PC laptop on his desk and asked him to log in to see if he could see the contents of the new share. BOOM! He could browse share X!!

What the 😈 ??

[taco]

Update –

For some reason the group I was using from local was not working with AD UIDs. This group had exclusive access to Share X. So I went back into my OU, under AD on a PC and created a fresh group, and assigned it to Share X.

So far AFP is responding favorably.

The ‘Why’ is another matter.

I suppose persitance and determination are the best medicine when dealing with issues of this type. And the fact that just because one thing is showing weird behaviors does not mean that you should redo the entire server. Working non evasivly towards a solution is the first and best policy.

[Author]

Posts