Kerberos Authentication for workstations not on domain

Solution 1:

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

Solution 2:

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 3:

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:

1. User types \\foo\share

2. User is prompted for creds, enters [email protected] and password

3. Windows sees bar.domain.com and does something called DC location, which, amongst other things, tries to resolve SRV _kerberos._tcp.bar.domain.com from DNS, which either points to a domain controller or it doesn't.

4. If a DC is returned, Windows attempts to get a TGT from the DC using the creds entered in (2).

5. 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

6. Now it has a TGT for the user and it stuffs it into the ticket cache (see klist.exe).

7. With the TGT and DC it can talk to, it requests a service ticket for the SPN cifs/foo.

8. 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.

9. The service ticket is cached.

10. The client sends the service ticket to \\foo\share and 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 4:

Instructions below are for how to authenticate to a Samba server using Kerberos from a Windows 7/10 (maybe others) client. I have not tested for other version of client and server:

On the Windows client, "Run As Administrator" cmd.exe. Then enter this command to supply Windows with knowledge of the Kerberos domain controller (KDC) for the kerberos REALM.COM.

If the KDC are in DNS:

ksetup /addkdc REALM.COM

Otherwise:

ksetup /addkdc REALM.COM kdc01.realm.com

(Enter more KDCs for the realm REALM.COM if they exist. Also, can add other realms in either style.)

Then use Explorer to access the network share of interest. (E.g. \\samba.realm.com\share in the address bar.) A password prompt will open if the share is protected.

You'll need to specify the realm in the username. This can be done either like [email protected] or REALM.COM\user.

Then enter the password.