4

I'm not a Windows person at all, but I understand the basic idea that an Active Directory is LDAP + Kerberos 5 + microsoft special sauce. So, in a situation where I have a windows machine over which I have no control which is in an existing Active Directory Domain, is it possible to have a person on this machine explicitly acquire a Kerberos ticket for a foreign realm and then get resources on the Linux server that I have control over which is in a Kerberos/LDAP realm that I control?

Specifically, suppose I have in my realm a user "foo@MYREALM.COM", and this user logs into a random windows machine in "BAR.COM" which is a microsoft AD realm using username "baz". Now, they want to grab files off a share on my machine quux.myrealm.com via Samba or NFSv4 or access a web page that requires Kerberos auth, and they need to do it as foo@MYREALM.COM instead of baz@BAR.COM which is the identity they used to login to windows.

the Linux/Unix/MIT Kerberos way would be to "kinit foo@MYREALM.COM" and then go for it. Is there an equivalent on windows? Is there an equivalent that doesn't require installing anything unusual (ie. MIT Kerberos for Windows).

Cross-realm trust is not an option here, because I doubt the existing AD administrators will put the appropriate TGT entries even for one-way authentication, and besides, I don't have any desire to trust this domain.

dlakelan
  • 86
  • 8
  • Also, let's assume the foreign realm that I control has appropriate DNS SRV entries for auto-discovery. – dlakelan Oct 12 '16 at 19:05
  • Also note. I was able to map a network drive on my linux server from a windows 10 laptop by simply entering my credentials as MYREALM\username and using my Kerberos password. However, this is on a laptop that is NOT part of an AD system. Does the AD system and its own Kerberos stuff typically interfere with this in any way? – dlakelan Oct 12 '16 at 20:57
  • I suppose you could just `kinit` if Microsoft shipped the tool, which it seems they don't, or if you obtain it elsewhere. – Michael Hampton Oct 14 '16 at 00:17
  • It looks like if I install java I get a java implementation of kinit, it's concievable I could get java installed on the windows machines in question... https://docs.oracle.com/javase/8/docs/technotes/tools/windows/kinit.html – dlakelan Oct 14 '16 at 13:33
  • 1
    Yes, but then you'd have a bigger problem: Java would be on your machines. – Michael Hampton Oct 14 '16 at 15:41
  • Well, not *my* machines ;-) – dlakelan Oct 17 '16 at 12:56
  • @MichaelHampton Windows's [klist](https://technet.microsoft.com/en-us/library/hh134826(v=ws.11).aspx) provides many of the functions that other Kerberos implementations place in `kinit`. – 84104 Oct 19 '16 at 17:00
  • 1
    @84104 Leave it to Microsoft to do something completely different and incompatible to everyone else. – Michael Hampton Oct 19 '16 at 17:02

2 Answers2

1

Ok so here's some stuff I found out.

First off, many of the people who want to use my resources have windows machines that are not part of the Active Domain, just personal machines. So, with that what's needed is to run a terminal as administrator and

"ksetup /setrealm MYREALM_GOES_HERE"

Without the administrator privilege the ksetup won't work.

After a reboot, the windows client machine will think that it should talk with my KDC when getting tickets (my KDC is DNS discoverable).

ksetup is more or less a command-line interface to changing the information that would on a Linux/Unix machine be stored in /etc/krb5.conf, so you can specify default realm with /setrealm and you can tell the system about other realms using /addkdc and set a mapping between kerberos principals and local windows users using /mapuser and soforth as detailed here:

https://technet.microsoft.com/en-us/library/hh240190%28v=ws.11%29.aspx

what I haven't seen is a way to configure what would be in the [capaths] section of the krb5.conf file, that is, to tell the machine how to get transitive trusts between domains that aren't obviously related in a hierarchy (ie. not ABC.EXAMPLE.COM vs EXAMPLE.COM but instead say ABC.EXAMPLE.COM vs FOOBAR.COM)

I'm not sure what would happen if you try to ksetup on an AD member, I suspect it would be more locked down.

dlakelan
  • 86
  • 8
  • Also note that this question was asked and answered in a slightly different way here: http://serverfault.com/questions/444023/can-a-windows-machine-authenticate-against-samba-with-kerberos-when-users-are-st which is that even on an AD joined host, if you can use ksetup to tell it that your particular machine is in a different realm with a given KDC it should go out and talk to that realm at least for SMB mounts. – dlakelan Oct 21 '16 at 13:05
0

I'm not a Unix person, but I can tell you that Microsoft has several technologies for this (and I suspect Unix does also.)

The first is Active Directory Federation Services, which, according to the Wikipedia article, can

"provide users with single sign-on access to systems and applications located across organizational boundaries"

This, like the other products I will mention, uses the new "Claims-based" approach, in which you can have these various Security Token Services (STS) transform your authentication "claims" into the format your server or service needs for authentication (SAML, JWT, etc.).

Active Directory Federation Services must be installed in the Windows domain, so this may not work out for you. However, Microsoft also has a couple of cloud-based "claims transformation" products you can use instead. One is Azure Active Directory Services, which is both an "Identity Provider" and also a "Security Token Service". The previous link states that Azure Active Directory Services gives you

"single sign-on to thousands of cloud apps and access to web apps that you run on-premises".

I really don't recommend LDAP solutions, but if this is the route you want to take, you will need to use the replacement "Graph API" to access this service's "database". Also note that this service has a "sync" option which can sync accounts from an on-premises Active Directory to this cloud service.

Finally, there is Azure's Access Control Service which offers a "Security Token Service" (no Identity Provider). I personally think this service is better suited for mobile apps which need to authorize themselves on behalf of a user (OAuth2), but there is some overlap with Azure Active Directory Services, and you might want to check it out.

PluralSight has a number of courses on these technologies, and I suggest you check them out if you want to learn more about these technologies.

Greg Thatcher
  • 101
  • 4
  • 1
    I have no control over what the windows client or AD domain has installed. What I want is simply to be able to have the user acquire Kerberos tickets in my domain, and then have Windows use them when it needs to. I have (or will have) an LDAP + Kerberos solution set up for a cluster of Unix machines. Can the windows client, without me doing anything to it (such as installing extra software), acquire and use Kerberos tickets in my domain? – dlakelan Oct 14 '16 at 13:31
  • A windows client is configured to trust a Kerberos ticket from one realm. I've never heard of any mechanism that would allow a windows client to hold Kerberos tickets from two realms and use one for some serviced and a different one for other services on other machines.. I know of no way that this could be done without installing software on the Windows client, or using one of the mechanisms I mention above. – Greg Thatcher Oct 16 '16 at 04:13
  • Greg: when you map a network drive and tell windows to use alternative credentials, and give it "MYREALM/username" as the credentials, and then give password, what does it do? Does it go out and acquire tickets in MYREALM? It certainly seemed that way when I tested it, but I confess that there's a possibility it simply sent the password to my samba server rather than a kerberos ticket. – dlakelan Oct 17 '16 at 12:59
  • When you try to connect to the remote drive in a remote realm, the Windows client first tries to use Kerberos, and this fails. Then, it falls back to NT Lan Manager (NTLM) security protocols (challenge/response), and logs you in if your username and password are correct. If all your machines are on the local network, then yes, this may work for you. You can also setup a Web Server to do something similar - no Kerberos ticket, but user can login with their foreign domain's username and password. – Greg Thatcher Oct 17 '16 at 19:47