Cross-realm with AD trusting Kerberos

[Robert Wehn]

Am 11.11.2015 um 23:36 schrieb Leonard J. Peirce:
> In an attempt to stop syncing passwords between Kerberos and AD and get to
> a single password store we are currently testing cross-realm with Active
> Directory trusting Kerberos.  We have the trust configured and our Windows
> admin here says that he can successfully authenticate against our KDC
> from an AD-enabled Windows host but is required to specify the @realm
> in order to authenticate since our AD domain is different from our
> Kerberos realm.
> 
> Our Windows admin feels this is unworkable.  I'm not really a Windows/AD
> expert but looking at the Windows ksetup command the /addhosttorealmmap
> and /addrealmflags options look promising.
> 
> Has anyone had success with cross-realm and AD trusting Kerberos this
> way?

We've been testing something similar to that in 2010 (have AD "shadow
users" which point to an MIT Realm with the Password by setting
altSecurityIdentity=Kerberos:username at REALM) and fond it to work with
Windows XP and Windows 7 machines to log on, if you set the trusts,
host-to-realm settings, default Realms ... by GPOs.

The Problems occurred when testing with Applications, that ignored these
settings.

Example: Exchange and Outlook
Exchange Online Web Access worked some way, but the Outlook client (not
sure if it was 2007 or 2010) was not able to cope with that correctly.
The Problem seems to be that in principle it is possible to have "shadow
users" in Exchange, too, but the client in some way can only cope with
that if the users at REALM you point to have a Realm which is also AD,
because they expect they can look up things like SIDs in the
corresponding LDAP.

In a way out test was more complicated, because the Exchange had its own
AD, so we hat to test the 2 Possibilities:
- Exchange(su) <trust> MIT (ru) <trust> AD <su>
- MIT (ru) <trust> AD (su) <trust> Exchange (su)
(su=shadow user, ru=real user with password AD=AD with computer objects
Exchange=AD with exchange server/users)
But I think that even with schadow users/computers only in the Exchange
AD it wasn't really better.

Our conclusion was:
The more complex services you might later want to introduce in AD the
more problems you get when redirecting authentication. Kerberos is not
the problem here but the complex interplay with LDAP some applications
expect to work.

Cheers, Robert.

-- 

Dr. Robert Wehn ........................ http://www.rz.uni-augsburg.de
Universität Augsburg, Rechenzentrum ............. Tel. (0821) 598-2047
86135 Augsburg .................................. Fax. (0821) 598-2028