I've tried to figure it out myself, but to no avail. Google offers many tutorials but I couldn't find any for the below case.

We have an external cooperating employee with VPN access to our LAN and he needs to access some of our web applications. His workstation operates under Windows 7 Professional. The web applications can only accept Kerberos-based SSO authentication - password auth is disabled due to security policy and it cannot be changed. Kerberos AS/KDC are provided by Windows Server 2008 R2-level domain, of which his workstation is not a member.

How can we configure Kerberos authentication from his workstation without adding it to the domain? Until now I only used to configure UNIX-based systems with Kerberos. Under Windows I can think of two different solutions:

  1. Install external Kerberos libraries (ie. MIT Kerberos for Windows) - I assume configuration process is similar to UNIX-based (ie. editing krb5.conf, set default realm and enable DNS-based KDC locating).

  2. Configure Windows built-in Kerberos client without adding the workstation to the domain - I'm not sure it is even possible.

We need to make SSO working in Mozilla Firefox. Provided that we use the first solution I assume we should set network.negotiate-auth.gsslib to external Kerberos DLL path. Can this setup work as expected? From the above options the latter is strongly preferred, as we'd like to avoid external dependencies and possible incompatibilities.

  • 1
    That sounds way over-complicated and fragile. Why not setup a remote desktop server or a Windows 7 VM for remote user(s)?
    – Greg Askew
    Jan 8, 2016 at 12:46
  • @GregAskew We've considered a similar solution (with Linux-based workstation though), but due to our policy it requires creating another VLAN and firewall zone to separate access and thus we consider it the last resort option. And I don't consider it "fragile" because Kerberos is a standardized and popular protocol. Jan 8, 2016 at 13:20
  • 1
    AD is, at its core, an MIT kerberos implementation. So 3rd party kerberos client should work with AD, though you will still need to have identity in AD for the user. On the same token, I think you can use ksetup.exe( a windows builtin kerberos tool) to make this machine a member of AD - it's an unusual setup where you treat AD as a realm rather than a native domain. I never test this myself but it should work. For question #2, no, you can't use built in kerberos client without joining into domain.
    – strongline
    Jan 14, 2016 at 3:28
  • @strongline Thank you. If I make Windows client a member of AD Kerberos realm using ksetup.exe, what this means besides authentication? Will GPOs be processed? I assume a keytab will be created (in a file or registry), but what about periodic changing machine account password - is it gonna work? Jan 14, 2016 at 6:11
  • 1
    @sam_pan_mariusz, I don't think GPO will get applied. Machine password change is initiated by client. So for keytab file clients, I don't think it will do that, or it needs that.
    – strongline
    Jan 14, 2016 at 15:00

1 Answer 1


I recently got KERBEROS working from a VPN-connected workstation that's not joined to the domain (an AWS-managed Server 2008R2 Active Directory). The key was adding the SRV and corresponding A records to public DNS so that the worksation could resolve _kerberos._tcp.dc._msdcs.mydomain.mydomain.com to the DC's local VPC address on port 88 (note mydomain twice is not a mistake).

Kerberos clients get tickets using the domain credentials stored in the Windows Credentials Manager. Adding the realm via ksetup wasn't necessary.

  • Could you please show us a screenshot of your SRV and A records-entries added?
    – aHero
    Jul 24, 2023 at 14:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .