Kerberos Authentication for workstations not on domain
Solution 1:
how are systems (laptops) not on the domain able to access the same network resources using only the username and password of an active directory user?
It depends on which "network resources" are involved. On a domain-joined Windows computer you're logged into, there are at least two client Kerberos identities in play:
- you, user@DOMAIN
- the computer, workstation$@DOMAIN
There is also host/workstation@DOMAIN, but that's generally the identification of a service running on the host, being accessed from elsewhere. If a privileged process on the host wants to do something -- say, add its name to DNS using Kerberos-authenticated dynamic DNS -- it will use its identity to do so, workstation$@DOMAIN. If you in your login session access some resource yourself, however -- say a CIFS network share, or an authenticated HTTP URL -- then the client identity is your principal name, user@DOMAIN (credentials for which are acquired automatically for you using the password you entered to log in). From your question, you seem to think that some combination is involved; it's not, they are separate.
This is why there's no problem using Kerberos to access Windows-based resources from other platforms. You can just as well type "kinit user" on a Linux box, enter your password to get a Kerberos credential (TGT) from a domain controller, and then use Firefox to access a Kerberos-authenticated web page on IIS. The protocols for all this are standard, and you don't need anything except your user credential.
A previous answer claimed that NTLM is required in this case; that's false (though certainly it may be used). However, when you access some resource from a non-domain computer and are prompted for your username and password, you don't necessarily know what authentication method is actually being used. It might use Kerberos. It might also just fall back to a password-based mechanism whereby it sends your username and password to the server for verification, and then cache your password so you don't have to re-enter it. Many protocols allow both via abstraction schemes like SASL. You'd have to look on the wire to see what's going on.
Solution 2:
Old question, but the answers are not particularly accurate.
Windows doesn't especially care whether your computer is domain joined or not. The domain join in this stage of authentication is really just a hint to tell the client what domain it maybe should try contacting if enough information isn't present.
The way Kerberos auth works is it takes a look at the creds presented to it during authentication. If the username provided has enough information to resolve a domain controller it will happily attempt Kerberos immediately. It will only fall back to NTLM if there isn't enough information provided by the user for the client to find a DC. It basically works like this:
User types
\\foo\shareUser is prompted for creds, enters [email protected] and password
Windows sees bar.domain.com and does something called DC location, which, amongst other things, tries to resolve
SRV _kerberos._tcp.bar.domain.comfrom DNS, which either points to a domain controller or it doesn't.If a DC is returned, Windows attempts to get a TGT from the DC using the creds entered in (2).
If this fails it may do one of these depending on the errors returned:
a) go back to (3) and do round robin
b) fall back to NTLM
c) fail the attempt outright
Now it has a TGT for the user and it stuffs it into the ticket cache (see
klist.exe).With the TGT and DC it can talk to, it requests a service ticket for the SPN
cifs/foo.If the DC found a service account with that SPN it then returns a service ticket, otherwise it returns an error and Windows falls back to NTLM.
The service ticket is cached.
The client sends the service ticket to
\\foo\shareand SMB does it's thing.
This more or less is how it works on workgroup or domain joined computers. The only difference is step 2 and 3 differ. On a domain joined computer the creds are already known, and the domain is already known, so it uses the native SSO creds. DC location is still attempted, but it doesn't have to reason about the user's domain because it already knows it.
So the trick here is entering creds into step (2) such that Windows has enough information to find a DC. That means using the fully qualified domain name and not any custom friendly UPNs you have have added. It also means the legacy NetBIOS method of bar\user probably won't work. Maybe it will if you have enough legacy infrastructure to support it (remember NetBEUI?).
Solution 3:
NTLM is used in this case...
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx
http://en.wikipedia.org/wiki/NTLM