LDAP login + local homes=big problems!

[andyinindy]

We are using the LDAPv3 plug-in to authenticate our lab eMacs/iMacs against a Sun LDAP server, with homes being created locally. Probably 30% of the time we get home folders that are not coming from /System/Library/User Template/English.lproj as they should be.

One of two things happen when login fails:

1) We get a home that is owned by root (and therefore unwritable for our users). This home is being created from some “other” default template, presumably the same one that is used to create the root user’s home. I have no idea where this template lives, else I’d change it. This problem is sometimes accompanied by the “there is a problem logging in at this time” error message. This is the more common problem.

2) We sometimes get a situation where homes are not created at all. This is accompanied by the “home directory was not found in the usual location” error message (Strangely, we sometimes get this error message when logging in as a local user!). This error occurs less often than 1).

Things we have tried:

–The creation of home folders is now scripted, and happens via a loginhook based on Mike Bombich’s script. Previously we were relying on OS X’s built-in mechanism for this.

–We have given all lab machines statically assigned IP’s in DHCP. The thought was that they are not getting the network quickly enough at startup (we see lookupd and other network services failing at startup in our system logs).

–Forward/reverse DNS entries for Sun LDAP server.

–Deleted MCX cache in netinfo.

We are using a static mapping for NFSHomeDirectory. We have it mapped to #/Users/$uid$, per this example:

http://homepage.mac.com/dansinema/

Again, not sure if this is part of the problem or not.

Any and all advice greatly appreciated! Please help!

–Andy

P.S.: We also occasionally get finder hangs at logout, such that the system needs to be manually rebooted. All other apps work fine, but the finder will not let us log out. We have our home folders being archived to /private/tmp at logout instead of at login; not sure if this is a contributing factor or not. Have deleted all finder.plist files to no avail.

[andyinindy]

10.3.4

[andyinindy]

Awesome! I will definitely investigate the DirectoryService logs and attempt to use dscl to get info on where it thinks the homes should be. Thank you for the advice! I will post results on Tuesday.

Oh, and if memory serves me correctly, most of the startup errors with lookupd have disappeared, although I still have tons of warnings about nfs not being able to find… something. Maybe the static mapping is causing problems? Hmm. I’ll post these logs as well.

[andyinindy]

Let me see if I undertsand this. It sounds like you do not rely on a loginhook to create your home directories, but instead use Mac OS X’s built-in mechanism (i.e. customizing the default user template). Is this correct?

I ask because I had a thought. What if having my static mapping as #/Users/$uid$ in conjunction with a loginhook that manually creates /Users/$1 is confusing things? Maybe the script is fighting with the OS? Should I eliminate one or the other?

Just a thought. I have turned on DirectoryService debug mode as you suggested; hopefully this will yield some useful results. I will also investigate dscl.

Thanks again!

[andyinindy]

DirectoryService has started returning some useul debugging info. The error codes that I have seen so far include:

-14002 : eDSOpenNodeFailed
-14130 : eDSInvalidRecordType
-14134 : eDSAttributeNotFound
-13136 : eDSRecordNotFound

The most serious of all of these was the -14002. This corresponded to a complete inability to login via LDAP (login panel shaking off passwords). This was accompanied by errors with the MCXCacher, so I logged in as a local admin and did a “flushCache” in lookupd, and was then able to authenticate against LDAP again.

The other errors seem non-fatal, as they allow login to proceed (albeit slowly). I am still trying to “catch the tiger by the tail” so to speak, by catching one of the aforementioned failed logins (with bogus homes) in the logs.

Incidentally, I am seeing lots of log OUT failures as well! The finder locks up such that it cannot be relaunched or forced to quit, and thus logout stalls. Not sure if this is related or not. All finder.plist files deleted to no avail.

I’ll keep at it. Again, all help appreciated!

–Andy

[andyinindy]

I’m using what I presume to be the FQDN (in that it has forward & reverse entries). I will certainly try pointing the LDAP plugin at the raw IP of the server to see if this helps.

I have also noticed in the system logs that our lab systems seem to be getting link-local hostnames at startup (i.e. whatever.local). Not sure if this is part of the problem or not. Our Apple engineer suggested that we give them hostname reservations, but our admin (who keeps a short leash on such things) decided that IP reservations in DHCP would suffice. Should I push him to fix DNS as well?

Thanks again for the helpful advice!

–Andy

[andyinindy]

OK, more logs. Here’s what I see with a failed login (finally caught it!):

Sep  7 17:07:28 localhost lookupd[1311]: lookupd (version 324.2.1) starting - Tue Sep  7 17:07:28 2004
Sep  7 17:07:28 localhost DirectoryService[1308]: InitLDAPConnection or ldap_init failure: Logging Failed LDAP connection with incomplete data
Sep  7 17:07:29 localhost set-hostname[1317]: setting hostname to LH149-A200381.local
Sep  7 17:07:29 localhost kernel: AFPSleepWakeHandler:  waking up
Sep  7 17:07:29 localhost mDNSResponder[150]: mDNSResponder Waking at 3853196
Sep  7 17:07:31 localhost configd[88]: posting notification com.apple.system.config.network_change
Sep  7 17:07:31 localhost mach_init[2]: Server 221b in bootstrap d03 uid 0: "/usr/sbin/lookupd": exited as a result of signal 1 [pid 1311]
Sep  7 17:07:31 localhost configd[88]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set-hostname
Sep  7 17:07:31 localhost lookupd[1320]: lookupd (version 324.2.1) starting - Tue Sep  7 17:07:31 2004
Sep  7 17:07:31 localhost set-hostname[1333]: setting hostname to LH149-A200381.local
Sep  7 17:07:34 localhost kernel: nfs server automount -fstab [290]: not responding
Sep  7 17:07:36 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: DSGetSpecialNodeName(): dsFindDirNode(2200) == -14900 
Sep  7 17:07:36 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: DSGetComputerInfo(): DSOpenLocalNode() == -14956 
Sep  7 17:07:36 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: MCXSecurityAgent:canMCXUserLogin: Couldn't get computer data -14956
Sep  7 17:07:40 localhost loginwindow[1209]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/kford: Attempt 1
Sep  7 17:07:41 localhost loginwindow[1209]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/kford: Attempt 2
Sep  7 17:07:42 localhost loginwindow[1209]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/kford: Attempt 3

The failed “stat” of the home directory continues about 20 times, until the user finally logs out. Notice the failed LDAP connection at the beginning (presumably logged someplace; I didn’t see it in the DirectoryService log).

I took your advice and configured the LDAP plug-in to look at the server’s raw IP rather than it’s hostname. No joy. Here’s what happened:

Sep  8 08:30:06 localhost loginwindow[191]: Sent launch request message to DirectoryService mach_init port 
Sep  8 08:30:06 localhost DirectoryService[195]: Launched version 1.8.2 (v257.1)
Sep  8 08:30:06 localhost kernel: UniNEnet::monitorLinkStatus - Link is up at 100 Mbps - Full Duplex
Sep  8 08:30:06 localhost configd[96]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set-hostname
Sep  8 08:30:07 localhost set-hostname[201]: setting hostname to LH149-A200381.local
Sep  8 08:30:07 localhost DirectoryService[195]: InitLDAPConnection or ldap_init failure: Logging Failed LDAP connection with incomplete data
Sep  8 08:30:07 localhost loginwindow[191]: DSOpenNode(): dsOpenDirNode("/LDAPv3/172.16.66.233") == -14002 
Sep  8 08:30:07 localhost DirectoryService[195]: InitLDAPConnection or ldap_init failure: Logging Failed LDAP connection with incomplete data
Sep  8 08:30:09 localhost configd[96]: posting notification com.apple.system.config.network_change
Sep  8 08:30:09 localhost configd[96]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/enable-network
Sep  8 08:30:09 localhost mach_init[2]: Server 0 in bootstrap d03 uid 0: "/usr/sbin/lookupd": exited as a result of signal 1 [pid 131]
Sep  8 08:30:09 localhost configd[96]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set-hostname
Sep  8 08:30:09 localhost lookupd[211]: lookupd (version 324.2.1) starting - Wed Sep  8 08:30:09 2004
Sep  8 08:30:09 localhost ConsoleMessage: Loading Shared IP extension
Sep  8 08:30:10 localhost ConsoleMessage: Starting network time synchronization
Sep  8 08:30:10 localhost ntpdate[245]: ntpdate [email protected] Fri Sep 12 18:30:10 PDT 2003 (1)
Sep  8 08:30:10 localhost ntpdate[245]: step time server 159.242.17.2 offset -0.331185 sec
Sep  8 08:30:10 localhost ntpd[258]: ntpd [email protected] Fri Sep 12 18:30:03 PDT 2003 (1)
Sep  8 08:30:10 localhost ntpd[258]: precision = 9 usec
Sep  8 08:30:10 localhost ConsoleMessage: Starting printing services
Sep  8 08:30:10 localhost ConsoleMessage: Starting network file system
Sep  8 08:30:10 localhost automount[294]: automount version 57
Sep  8 08:30:11 localhost automount[297]: automount version 57
Sep  8 08:30:11 localhost set-hostname[308]: setting hostname to LH149-A200381.local
Sep  8 08:30:11 localhost mach_init[2]: Server 0 in bootstrap d03 uid 0: "/usr/libexec/fix_prebinding": exited with non-zero status 1 [pid 319]
Sep  8 08:30:13 localhost ConsoleMessage: Loading IP Firewall extension
Sep  8 08:30:16 localhost kernel: IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled
Sep  8 08:30:16 localhost kernel: IPv6 packet filtering initialized, default to accept, logging disabled
Sep  8 08:30:16 localhost kernel: IP firewall loaded
Sep  8 08:30:16 localhost ConsoleMessage: Starting internet services
Sep  8 08:30:16 localhost xinetd[335]: 335 {init_services} no services. Exiting...
Sep  8 08:30:17 localhost /System/Library/LoginPlugins/MCX.loginPlugin/Contents/MacOS/MCXCacher: DSGetParentsConfigInfo(): DSGetRecordList() == -14130 

Notice that our old friend -14002 is here again. Strangely, I was able to login just after this point in the log, so maybe -14002’s aren’t always as fatal as they seem…

Anyway, I’m (obviously) still wrestling with this issue. Again, all advice appreciated.

–Andy

[andyinindy]

Eureka!

It looks like we have this thing pegged (knock on some serious wood).

We had not set default dns servers in the network config on our lab machines. Once we did this, the issue with failed logins seems to have been resolved (no pun intended)! Hopefully I’m not speaking too soon…

I’ll keep this thread up to date; if the issue comes back to rear its ugly head, you’ll be the first to know. I have thought that we had this solved several times, so I’m cautiously optimistic.

Thanks for listening,

–Andy

[andyinindy]

Yes, we were using DHCP for everything previously. We have now manually entered the IP addresses for our internal dns servers in the Network preference pane on all client machines.

We are not mounting network home folders, just authenticating against LDAP. Nevertheless, it appears that the issue has been resolved (still no failures).

I will keep an eye on the logs to see if we still get lookupd and other network failures. I too am dismayed by the inability to find the ldap server even with raw ip… this would circumvent dns altogether, so I’m stumped as to why this would not have worked. Perhaps some behind the scenes give and take that required name resolution?

Anyway, thanks again!

[andyinindy]

Of course, I spoke too soon. Had a failed login again. Here’s the system log:

Sep  9 12:46:03 localhost kernel: System Wake
Sep  9 12:46:03 localhost kernel: Wake event 0020
Sep  9 12:46:03 localhost kernel: AppleNMI unmask NMI
Sep  9 12:46:03 localhost kernel: UniNEnet::monitorLinkStatus - Link is up at 10 Mbps - Full Duplex
Sep  9 12:46:03 localhost mDNSResponder[150]: mDNSResponder Waking at 11282857
Sep  9 12:46:03 localhost configd[89]: posting notification com.apple.system.config.network_change
Sep  9 12:46:03 localhost mach_init[2]: Server 0 in bootstrap d03 uid 0: "/usr/sbin/lookupd": exited as a result of signal 1 [pid 1243]
Sep  9 12:46:03 localhost configd[89]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set-hostname
Sep  9 12:46:03 localhost lookupd[1263]: lookupd (version 324.2.1) starting - Thu Sep  9 12:46:03 2004
Sep  9 12:46:03 localhost set-hostname[1268]: setting hostname to LH149-A200368.local
Sep  9 12:46:05 localhost configd[89]: posting notification com.apple.system.config.network_change
Sep  9 12:46:05 localhost mach_init[2]: Server 224f in bootstrap d03 uid 0: "/usr/sbin/lookupd": exited as a result of signal 1 [pid 1263]
Sep  9 12:46:05 localhost configd[89]: executing /System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set-hostname
Sep  9 12:46:06 localhost lookupd[1271]: lookupd (version 324.2.1) starting - Thu Sep  9 12:46:06 2004
Sep  9 12:46:06 localhost set-hostname[1284]: setting hostname to LH149-A200368.local
Sep  9 12:46:27 localhost kernel: nfs server automount -fstab [301]: not responding
Sep  9 12:46:31 localhost /System/Library/CoreServices/ARD Agent.app/Contents/MacOS/ARD Agent: 'infores' (159.242.154.37) started ARD administration
Sep  9 12:46:58 localhost kernel: nfs server automount -fstab [301]: not responding
Sep  9 12:47:29 localhost kernel: nfs server automount -fstab [301]: not responding
Sep  9 12:49:33 localhost last message repeated 4 times
Sep  9 12:50:35 localhost last message repeated 2 times
Sep  9 12:50:41 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: DSGetSpecialNodeName(): dsFindDirNode(2200) == -14900 
Sep  9 12:50:41 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: DSGetComputerInfo(): DSOpenLocalNode() == -14956 
Sep  9 12:50:41 localhost /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent: MCXSecurityAgent:canMCXUserLogin: Couldn't get computer data -14956
Sep  9 12:50:44 localhost diskarbitrationd[90]: disk1s2    hfs      0066E9D8-3257-3460-BA9D-475FD5863810 Classic                 [not mounted]
Sep  9 12:50:44 localhost diskarbitrationd[90]: disk1s2    hfs      0066E9D8-3257-3460-BA9D-475FD5863810 Classic                 /Volumes/Classic
Sep  9 12:50:44 localhost loginwindow[1213]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/gwoods: Attempt 1
Sep  9 12:50:45 localhost loginwindow[1213]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/gwoods: Attempt 2
Sep  9 12:50:46 localhost loginwindow[1213]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/gwoods: Attempt 3
Sep  9 12:50:47 localhost loginwindow[1213]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/gwoods: Attempt 4
Sep  9 12:50:48 localhost loginwindow[1213]: Failed to stat homedir: sleeping 1 second: chdir returns -1 for /Users/gwoods: Attempt 5

Again we see the -14900 and -14956. Also, notice the lookupd failure. I have also seen LDAP failing to bind, along with some odd automount failures (Error symlinking /Network/Servers/ to /automount/static/Network/Servers/: File exists).

I did a dscl to see where it thought the home lived, and everything looked fine. We do have both “HomeDirectory” and “homeDirectory” (notice the capitalization difference) attributes set on the server.

“homeDirectory” is there for unix purposes and points to “/homes/uid”.

“HomeDirectory” is a remnant of an old NFS resharing setup that my predecessor implemented, and is no longer used. It is pointing to “afp://xserve/Homesuid“.

There is also an “NFSHomeDirectory” attribute that worked in conjunction with “HomeDirectory”; it points to “/Network/Servers/xserve/private/automount/nfs_reshares/Homes/uid”.

These attributes are not mapped in the LDAP plugin on the clients, (with the exception of NFSHomeDirectory, which is statically mapped to “#/Users/$uid$”) so I don’t see how this could be causing any problems.

Should we remove these old ‘HomeDirectory” and “NFSHomeDirectory” attributes from LDAP? Could they be causing problems?

[andyinindy]

And another thing…

On the failed logins when I do an “id”, it shows the currently logged in user as having a gid of 100, which corresponds to the “students” group on the LDAP server.

On successful logins, the gid comes back as 10, which corresponds to a local group on the client machine.

Weird! Not sure if this is relevant or not…

[andyinindy]

OK, we removed both the NFSHomeDirectory and the HomeDirectory attributes from LDAP. I’ll report results here next week.

If I haven’t said this already, let me state the obvious; Joel, you (and this site) are an incredible asset. Thank you again for all of your help with this issue!

[andyinindy]

OK, still not solved. Here’s some more info.

On failed logins, we are also unable to logout successfully. However, I can force a logout simply by manually killing the automount process (which appears to be hung). When I look at the system log, I see errors related to automount:

Sep 10 15:54:00 localhost automount[293]: Error symlinking /Network/Servers/ to /automount/static/Network/Servers/: File exists
Sep 10 15:54:00 localhost automount[293]: Attempting to unlink /Network/Servers/…

I am also seeing lots of automount related activity in the DirectoryService logs:

2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16777218 
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16777218 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16777218 : Node Count = 6 : Change Token = 1007
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsOpenDirService(), Server Used : DAR : Dir Ref 16780363 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16780363 
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16780363 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16780363 : Node Count = 6 : Change Token = 1007
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAC : Dir Ref 16780363 : Data buffer size = 512
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16780363 : Requested nodename = DefaultNetworkNodes
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16780363 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeList(), Server Used : DAC : Dir Ref 16780363 : Data buffer size = 512
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeList(), Server Used : DAR : Dir Ref = 16780363 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16780363 
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16780363 : Result code = 0
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16780363 : Node Count = 6 : Change Token = 1007
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsCloseDirService(), Server Used : DAC : Dir Ref 16780363 
2004-09-10 15:50:33 EST - Client: automount, PID: 274, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16780363 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16777218 
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16777218 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16777218 : Node Count = 6 : Change Token = 1007
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsOpenDirService(), Server Used : DAR : Dir Ref 16780364 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAC : Dir Ref 16777218
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsVerifyDirRefNum(), Server Used : DAR : Dir Ref 16777218 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16780364 
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16780364 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16780364 : Node Count = 6 : Change Token = 1007
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAC : Dir Ref 16780364 : Data buffer size = 512
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAR : 1 : Dir Ref = 16780364 : Requested nodename = DefaultNetworkNodes
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsFindDirNodes(), Server Used : DAR : 2 : Dir Ref = 16780364 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeList(), Server Used : DAC : Dir Ref 16780364 : Data buffer size = 512
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeList(), Server Used : DAR : Dir Ref = 16780364 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAC : Dir Ref 16780364 
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 1 : Dir Ref = 16780364 : Result code = 0
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsGetDirNodeChangeToken(), Server Used : DAR : 2 : Dir Ref = 16780364 : Node Count = 6 : Change Token = 1007
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsCloseDirService(), Server Used : DAC : Dir Ref 16780364 
2004-09-10 15:51:13 EST - Client: automount, PID: 274, API: dsCloseDirService(), Server Used : DAR : Dir Ref 16780364 : Result code = 0

I also see that on failed logins, the GID of the currently logged in user is that of a group that resides on the server (100 or “Students”). However, on successful logins the gid is a local group (10 or “infores”). Any idea why the client machine might try to grab groups from the server? Should we try to force local group membership somehow (maybe a loginhook), or perhaps sync our groups between the ldap server and the client systems?

I’m just totally stumped now…

[andyinindy]

And where might I find this article? I did a search on AFP548 but didn’t find it… a url would rock!

[andyinindy]

When I paste this address into my browser, it refuses to load, saying that I must be a member. Well, I am a member, and I’m logged in… what gives?

*edit*

Is this the article you are referring to?

[Author]

Posts