LDAP login + local homes=big problems!

[andyinindy]

Hmm. Couldn’t ever view your article, but wanted to say that I added static mappings for PrimaryGroupID (in both “People” and Groups”). This attribute is now mapped to “#20”, which corresponds to “staff”. Idea gleaned from this article:

http://www.macdevcenter.com/pub/a/mac/2003/08/26/active_directory.html?page=2

Again, this probably won’t solve the issue with automounts, but it certainly couldn’t hurt. Previously we had PrimaryGroupID mapped to… something else (I wiped it out before I could write down what it was!).

Thanks again, I will report back with results.

[andyinindy]

Well, adding a static mapping for PrimaryGroupID certainly seems to have helped. While the issue with failed logins is not completely gone, it does seem to have decreased pretty dramatically. It now looks like about 5% of our logins fail, vs. 30% previously. We have also recently turned off recursion on our internal DNS servers, so this may have helped a bit.

Again, thank you for all of your help with this issue. Rest assured, I will be back if (when?) things screw up again…

[andyinindy]

We had PrimaryGroupID mapped to “gidNumber”. This was probably a remnant of a network home directory setup that our Apple engineer helped us with (and which we decided to delay the use of).

I still can’t get your link to work, even without the “&query”… what am I doing wrong??

[andyinindy]

OK, I finally found the article on automounts:

https://www.afp548.com/article.php?story=20040803154206687

I did an “allMounts” using lookupd in debug mode, and I found this:

==> 1 object
[
Dictionary: "D-0x003042f0"
_lookup_agent: DSAgent
_lookup_validation: 1099366638
dir: /Network/Servers/
name: xserve:/Volumes/Server HD/Users
vfstype: url
+ Category: mount
+ Time to live: 0
+ Age: 0 (expires in 0 seconds)
+ Negative: No
+ Cache hits: 0
+ Retain count: 2

]
<== 1 object

Obviously, this is bad. My predecessor was working on automounts, apparently, and I somehow managed to roll out a directory access config that contained his deprecated setup! Ugh!

How would I go about getting rid of this?! Which attributes in LDAP might hand out this info? Please help!

[andyinindy]

OK, I just wiped out the entire “Mounts” entry in my directory access config. Here’s what was there. The entries on the right are what I had these attributes mapped to.

Mounts = mount
     VFSLinkDir = mountDirectory
     VFSOpts = mountOption
     VFSType = mountType
     VFSDumpFreq = mountDumpFrequency
     VFSPassNo = mountPassNo

Removing this entry entirely does not seem to have adversely effected authentication. “allMounts” in lookupd now returns “nil”. Yippee!

Again, I’ll report on whether this seems to fix things…

[Detrius]

I wanted to throw in a few small details here. Today, I was having the same problem of users not being able to log in (spinning beach ball after clicking login). system.log showed a lot of the “nfs server automount -fstab [PID] not responding” errors. I also got the symlink errors. I did a killall automount and then went through and removed all folders from /automount. I also removed /private/Network and /private/_Network_. I think I may have also removed /private/var/automount. It is very important that automount not be running when you do this, as an rm -fr could wipe your system. You should also double check using df that nothing is mounted in these locations and you should specifically triple check that there are no important files in these folders.

Then, reboot.

As far as you wanting user folders to be stored locally on the client computers: you could get open directory running properly and then enable mobile accounts. This may be the simplest way to get an effect similar to what you want.

[Author]

Posts