Home / server / Questions / 808645
In Process
dlakelan
Asked: 2016-10-13 08:12:14 +0800 CST

Using resources in foreign Kerberos Realm from windows without cross-domain trust?

  • 772

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 "[email protected]", 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 [email protected] instead of [email protected] which is the identity they used to login to windows.

the Linux/Unix/MIT Kerberos way would be to "kinit [email protected]" 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.

windows linux kerberos cross-domain

2 Answers

  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.

    • 1

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

    • 0