I'm using AD with mobile accounts and Forced local home directories and experienced that if I login to the computer as soon after it boots up to login prompt, it will use cached credentials instead of authentication to the network. This will cause not to get a Kerberos ticket for SSO.
This will be resolved if it wait for a while before I login so the network stack properly initialised.
But users might login as soon as it boots up and will cause some issues with network home folders and SSO.
Has anyone got a solution to this?
This is the same thing someone asked in another forum;
hi all I have some general inquiries regarding kerberos and OS X. What I am trying to figure out is if the behavior I am seeing is by design or typical. Or if something is broken. This is my first time using OS X and studying it's integration into other systems like Active Directory so unfortunately I can't draw on any personal experience We're experimenting with integration of OSx into our almost purely Microsoft environment. We're seeing a few caveats to how authentication works against Active Directory and, more specifically, Kerberos. First, when you boot up OSx and the networking stack is not completely initialized, it won't you log in with network credentials if you're never logged in before. That's to be expected as it can't contact any directory servers. Once things initialize and the redyellow dot in the username field goes away, you can log in and you'll get a TGT from a kerberos KDC. All is well and you can authenticate to other network resources using kerberos. However, say you reboot again and log in before the networking stack is up or you're just disconnected from any network. Let's also assume you have a mobile account created for your managed (network) account. So, you are able to get logged in. Then you connect to the network (wireless, plug in, whatever). In this scenario, we're seeing that you can't get to any kerberized resources because you never got a TGT. Moreover, you will never get a TGT unless you run kinit or logout and back in. Bummer. At that point you're pretty much reliant on your keychain to supply credentials to network resources that you've accessed previously. Couple this caveat with the fact (as far as I know) that on OSx you can't connect to a wireless network before a user logs in. So there's a good chance that a lot of our laptop users will log in when they're not connected to any network. Thus they won't get a TGT and won't get SSO via kerberos for a lot of resources. Sure, if you have credentials on your keychain for certain resources you'll get the appearance of SSO, but that's sort of dumb as one of the purposes of using an auth scheme like kerberos is that you don't need to keep another database full of credentials. This is in contrast to Windows where, if a directory server is can't be reached at log in, you are logged on with cached credentials. As soon as the network becomes available, you are authenticated and receive TGT's and thus can log in to kerberized services. You don't know the difference as a user. It's transparent. For those of you with experience with this, does my description of how this works make sense and is to be expected or or we missing something in our config? Or am I just plain doing it wrong? Smile
On 10.7, it's the "red" dot issue. If you wait for the "red" dot to go away, it will auth to the domain. If you choose to log in before the dot goes away, it uses cached or prevents login if you haven't logged in to the computer before.
Not sure of how to get around this other than wait. Would like a solution to it as well if anyone has one.
Seen this behavior before? Yes, 10.6.x and 10.7.x. And it's unfortunately a wait 30-45 seconds before the red light disappears.
On another note, I have narrowed the problem down to a single subnet - and that subnet is a Virtual LAN. My networking knowledge ceases at this point but if I take these machine and pop them on to another subnet that isn't VLAN they get rid of the red dot in a matter of seconds after boot.
Incidentally, when these machines have crashed they will always rename themselves (eg. abc-def-012345 -> abc-def-012345 (2)) behavior again that doesn't happen anywhere other than on the VLAN.
Not sure it helps you, but maybe it's another thing you can rule out or confirm?