ActiveDirectory plugin not correctly creating users home directories

[pvmike]

Is there a trick to getting the Active Directory plugin in 10.4.7 to correctly create home directories for AD users? It is creating them with the root owning everything in it, and this is unacceptable.

Our setup: We have a Active Directory network (Windows Server 2003 SP1 as DCs), and are trying to integrate some of our Mac clients to user AD single-sign logins. We are not using OS X Server at all.
We do not user any sort of network home directories, as our users always use the same computers.
We just want a user to have a local home directory created when they log on for the first time. Unfortunately, the directories are being created with the wrong permissions.
One thing that may be the problem: the UID that are assigned to the AD users on the Mac clients are very high (> 60000000000). There is an error in the log that a UID that high cannot be added to the lastlog db, so that may be another symptom of the problem.

Is there a way to fix this wihout changing anything on the domain?

[giskard22]

Do you have a lower-ID user that you can test with? For example, the account being used to bind to the DC?

Assuming the the computers are successfully reading info from the DC, this issue could probably be fixed with a loginhook script that runs a chmod command.

[pvmike]

Forgive me if I understand this wrong, but I thought the UID that OSX uses was generated from the AD account's GUID and the computer's MAC address. We don't use any UID mappings.

I could fix it with a login script, but I'd rather not complicate the setup any more... although from what I've been reading it may be the only way.

[pvmike]

After doing a test with some mappings, changing the UID to a lower number (10000) did not change anything.
The home directories are still being created read-only.

[giskard22]

Oh, yeah, I think you're right. I was thinking of a different ID. :)

I don't think that error's actually important. It refers to some old-style UNIX tools not being able to work with the high UIDs, but it's not a problem for the OS. I've bound systems to AD where that error appears and there are no login problems.

Check the email list at macenterprise.org (they have archives). I bet someone's come across this problem before.

[Raven]

The document on this (http://www.afp548.com/filemgmt/index.php?id=12) page may be of some help. Its one of the cleanest and most complete Mac AD integration papers out there.

[pvmike]

Thanks, but that paper deal with using Open Directory OSX Server and using DirHost for networked home folders.
We do not want to use OSX Server; we want the OSX clients to talk directly with the AD domain controllers. We also do not want networked home folders.

[kenkass]

I suspect your problem is similar to one I have been having. I narrowed it down to this:

if the pre2k name (aka SAM) has a space in it (it will by default if you have spaces in your UPN). This maps to the "shortname" on the mac. Problem is that the shortname doesnt allow spaces like the SAM does, so you end up with a error. The directory is created but you dont have permissions (since osx sets permissions based on shortname).

Try logging in with an account that does not have spaces. It should be noted changing the SAM doesnt always fix it since the account gets cached.

hope this helps
-ken

[kopusx]

I had the same taks that you mention not long ago, and I have not gotten any errors, on mac's authenticating to AD, are you making the users administrators of the local machines? or are you creating mobile accounts for use with AD?, in anycase you might wan to check your settings on the Directory Access, and also on the logon prompt.