| Author | Messages | |
decrosby
Posts:101
 | | 06/03/2010 1:51 PM |
| Question for the wiseones
Does anyone have significant experience of using Kerberos as an account domain for authenticating users whilst resources reside in a trusted Windows AD. AltsecID / namemapping helps obviously but I wanted to understand if anyone else had come across interesting interop issues (GPO etc etc).
Thanks.
Damian.
--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| Parzival
Posts:107
| | 06/03/2010 2:06 PM |
| Hi Damian,
Userprofiles need some additional work (setting a GPO to disable ownership check). For the rest, it works but it can be a pain to manage.. when you use constraint delegation the trust between the two forests must be two-way else those applications break also. The business case for this architecture needs to be rock-solid, since you create a two-way forest trust only to separate users and resources..
Policies:
Allow Cross-Forest User Policy and Roaming User Profiles
Do no check the user ownership of Roaming Profile Folders
_R
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, June 03, 2010 2:49 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Using Kerberos Realm as an Account Domain
Question for the wiseones
Does anyone have significant experience of using Kerberos as an account domain for authenticating users whilst resources reside in a trusted Windows AD. AltsecID / namemapping helps obviously but I wanted to understand if anyone else had come across interesting interop issues (GPO etc etc).
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
| barkills
Posts:201
| | 06/03/2010 5:05 PM |
| Er ... I believe Damian was asking about a Kerberos realm trust not a Forest trust. They are two very different things. Leveraging a forest trust to get an account domain isn't really that much pain--we've got about 50 forests doing that via 1-way trusts with a central account forest.
>From my perspective, Kerberos realm trusts were a great interop technology 10 years ago. They demonstrated that Microsoft was serious about interoperability, and it allowed orgs that had existing investments to leverage those investments and have some peace of mind that they weren't betting the farm on "this version 1.0 Microsoft Kerberos stuff." The problem is that over the years this functionality has been dragged along, but nothing has been done to improve it.
The most significant downside to using a Kerberos realm trust is that you don't get any cost-savings in provisioning. You still have to provision an account (ok, principal) in the Kerberos realm AND in the Windows domain. And to make things worse, to avoid really icky problems for users, you have to provision the same password in both. The problem is that if you don't provision the same password, then if the user needs access to a service where Kerberos isn't accepted (or if Kerberos isn't negotiated for the many reasons that can happen), then the user needs an NTLM token issued, and the local LSA will blindly try to get one using the password the user entered earlier. So if that password doesn't match, the user gets a challenge thrown in their face, and then confusion reigns. In my mind, the whole benefit of using a Kerberos realm trust is so that you only have passwords in one place--and that isn't the reality. That said, I know there are many places that do use it. We even have departments here at the University of Washington that choose to use it (to our MIT Kerberos realm) over a domain/forest trust to our central AD--although I don't understand why they do that. There has been a semi-significant bug in each Windows server release that affected the Kerberos realm trust functionality. I know this because my colleague Ross Wilper (also on this list) discovered each of those bugs.
Many years ago, the Windows-Hied mailing list community (in an effort led by my colleague Brad Judy at UC Boulder at the time) developed a list of all the gotchas associated with Kerberos realm trust functionality. It hasn't been updated in 8 years because most of us have moved on from leveraging this functionality, but I'd expect that some of it is still useful. I've thrown a copy of that doc up at http://www.netid.washington.edu/documentation/kerbInteropTripups.doc.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, June 03, 2010 6:03 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Using Kerberos Realm as an Account Domain
Hi Damian,
Userprofiles need some additional work (setting a GPO to disable ownership check). For the rest, it works but it can be a pain to manage.. when you use constraint delegation the trust between the two forests must be two-way else those applications break also. The business case for this architecture needs to be rock-solid, since you create a two-way forest trust only to separate users and resources..
Policies:
Allow Cross-Forest User Policy and Roaming User Profiles
Do no check the user ownership of Roaming Profile Folders
_R
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Crosby, Damian
Sent: Thursday, June 03, 2010 2:49 PM
To: activedir@mail.activedir.org
Subject: [ActiveDir] Using Kerberos Realm as an Account Domain
Question for the wiseones
Does anyone have significant experience of using Kerberos as an account domain for authenticating users whilst resources reside in a trusted Windows AD. AltsecID / namemapping helps obviously but I wanted to understand if anyone else had come across interesting interop issues (GPO etc etc).
Thanks.
Damian.
________________________________
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.
| | | |
|
|