OD Users Unable to Login to Client

I don't think your problem is related to Managed Preferences, but you might want to double-check to ensure that you are not restricting access to the computers (Computers or Computer Groups section of Accounts in Workgroup Manager).

This sounds like a general inability to log in to any user account that resides in Open Directory, although at one time you must have been able to. This is what I think happened:

When things were working, Steve and Sally logged into their own Macs and chose to create a Mobile Account. (Sounds like they're also using Portable Homes, too.) When the Mobile Account is created, a copy of the user account is placed in the client's local LDAP (10.5) or NetInfo (10.4, 10.3) domain. The user's password hash is also copied to the local machine - from the Password Server database on the server to the Shadow Hash database on the client. The client's copy of the user account contains a reference to the original in the server's directory domain so that the two can be kept up-to-date.

However, the way it works is a little different from what most people may think: Whenever Steve or Sally logs into his/her own Mac after creating the mobile account, the client-side copy of the account will always be used (even if the server is available), because it is in the local directory node, which always has first priority in the authentication search path (search policy).

At some point, a change was made to your server, causing users in its LDAP (Open Directory) domain to lose the ability to log in. This would explain why Sally cannot log into Steve's Mac, and why Steve can. (Remember that Steve already has the mobile account there, but Sally doesn't.)

Now this change wouldn't necessarily affect the home synchronization feature via Portable Homes. That, along with other managed preferences, could still be working, largely because the clients keep a cache of that information, and because that information can be accessed in the directory by simply reading account attributes (no user authentication).

So at this point, I'd say that the problem resides either in your server's LDAP domain or in its Kerberos configuration.

Let's start with the LDAP domain: Have you changed your server's local (behind-NAT/private) IP address lately? Or did you start up NAT after Open Directory? If so, you may have to update the address and hostname in the server's LDAP domain via *slapconfig -changeip*:

sudo slapconfig -changeip (old IP) (new IP) (old name) (new name)

In short, the IP address should be the local one and the hostname should be +the DNS entry that resolves to that local address+. There are a couple of ways to accomplish this, such as hosting a private (behind-NAT) DNS zone. I've answered a similar question here: http://discussions.apple.com/message.jspa?messageID=5933263

The hostname is important not only for the LDAP process, but for Kerberos as well. The Kerberos realm name will be the server's hostname in uppercase. I've also answered a question relating to manual Kerberization and the things to check: http://discussions.apple.com/thread.jspa?threadID=1251391&tstart=0

Hope this helps!

--Gerrit

I am also having strange issues with Open Directory.

I am running an OD Master, and it's the only directory service on the network. If I use Directory Utility on my client machine and connect to the directory server, all is well. If I try to connect via AFP to the server, I get the following error:

+"Sorry, the operation could not be completed because an unexpected error occurred. (Error code -5019)"+

The server generates the following log entry in kdc.log:

*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: CLIENT NOTFOUND: 1FB8C945ACD9E0CE784F8B491DD16255E143CFDC@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET, Client not found in Kerberos database*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: CLIENT NOTFOUND: 1FB8C945ACD9E0CE784F8B491DD16255E143CFDC@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET, Client not found in Kerberos database*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: NEEDED_PREAUTH: timmcmanus@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET, Additional pre-authentication required*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: NEEDED_PREAUTH: timmcmanus@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET, Additional pre-authentication required*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](debug): handling authdata*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](debug): handling authdata*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](debug): .. .. ok*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](debug): .. .. ok*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: ISSUE: authtime 1196195452, etypes {rep=16 tkt=16 ses=16}, timmcmanus@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: ISSUE: authtime 1196195452, etypes {rep=16 tkt=16 ses=16}, timmcmanus@NS.100GREENWOOD.NET for krbtgt/NS.100GREENWOOD.NET@NS.100GREENWOOD.NET*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: ISSUE: authtime 1196195452, etypes {rep=16 tkt=16 ses=16}, timmcmanus@NS.100GREENWOOD.NET for afpserver/ns.100greenwood.net@NS.100GREENWOOD.NET*
*Nov 27 15:30:52 ns.100greenwood.net krb5kdc[107](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.0.1.7: ISSUE: authtime 1196195452, etypes {rep=16 tkt=16 ses=16}, timmcmanus@NS.100GREENWOOD.NET for afpserver/ns.100greenwood.net@NS.100GREENWOOD.NET*

Now, if I remove the directory from Directory Utility on the client and try to connect to the server, it works fine.

What did I break?

Wanted to add this log too from ApplePasswordServer.Server.log:

*Nov 27 2007 15:30:52 KERBEROS-LOGIN-CHECK: no principal (1FB8C945ACD9E0CE784F8B491DD16255E143CFDC@NS.100GREENWOOD.NET)*
*Nov 27 2007 15:30:52 KERBEROS-LOGIN-CHECK: no principal (timmcmanus@NS.100GREENWOOD.NET)*
*Nov 27 2007 15:30:52 KERBEROS-LOGIN-CHECK: no principal (timmcmanus@NS.100GREENWOOD.NET)*

The LDAP database was imported into Server Admin without any issues. I had archived the database, turned the server into a Standalone server and then back to an OD Master to fix a Kerberos problem. Then I reimported the archive back into LDAP with the Server Admin tool. All of the logs were fine as I rebooted and left the machine running for an hour. Then I added the OD master to the client's Directory Utility and I could not connect as any user.

Now it seems that I cannot connect as any user to AFP. Prior to adding the OD Master to the Directory Utility I could connect to the server.

I have no idea what is happening, but I suspect it's Kerberos.

Seems like this is more of an AFP issue than a Kerberos issue:

http://discussions.apple.com/thread.jspa?threadID=1224346&tstart=0

Okay, I have more details surrounding this issue. It IS an Open Directory problem.

After setting my server up last night and setting up Time Machine to back my laptop up to the server everything looked fine. However, I had the Console window open all night on the server. At 3:42 AM DirectoryServices crashed. I checked my laptop and Time Machine had backed up at that exact time. The Console also noted that Launchd restarted DirectoryServices a few seconds after the crash.

Now, things like iCal Server are working properly and SMB is also. Therefore, when DirectoryServices restarted, AFP and the PasswordServer returned a "no principal" error, which subsequently prevents people from logging into AFP. The only way to fix it is to stop AFP and restart it. This rebinds AFP to DirectoryServices.

Any "no principal" error is due to the service not communicating properly with DirectoryServices. Restarting the service "fixes" the issue. Found that one out the hard way.

Is there a way to increase Directory Services logging? I'm having a strange issue on my 10.4.10 clients bound to a 10.4.11 ODmaster and I'm starting to suspect it's a problem with DS. I'm not seeing anything out of the ordinary on my ODmaster but would like to increase log levels on both client and server to see if I can track it down.

Essentially users with network homes are getting intermittent hangups when launching new apps or opening new windows. Occasionally DS will crash or won't be able to traverse the directory node of our ODMaster on the clients and they won't have access to their own files. killall -HUP DirectoryService will resolve both the crashing/directory node issue, but the hangups tend to last about 10-30 seconds. With the hangups, nothing appears to be breaking, but perhaps it is some sort of timeout issue?