Re: Cross Forest Authentication

Tech-Archive recommends: Fix windows errors by optimizing your registry

Can I use Kerberos Delegation Of Authentication to impersonate a user that
resides in forest A, to a resource in Forest B.

"Al Mulnick" wrote:

A definitive answer on what? I had asked a few questions and Joe was kind
enough to expand on transitional protocol usage in your stead. But I still
don't see what you're after and what the end goal really is well enough to
take a guess at what the question really is. Can you just go ahead and spell
out what the question is?


"Chris Geier" <chris.geier at gmail.com> wrote in message
news:9F8F6AF5-BE92-41F3-B22A-9B14138C9F3A@xxxxxxxxxxxxxxxx
I am not a fan of the design either, and the research I have done into this
situation has not been as clear as I would like. I am in need of a
definitive answer on this. Any other help would be appreciated.

"Joe Kaplan" wrote:

Protocol transition, also called Kerberos Service for User (S4U), is a
new
feature in Win2K3 AD and Win2K3 server. Basically, it allows
authentication
performed with a non-Kerberos protocol (like basic, digest, NTLM or
something custom) to "transition" to Kerberos when Kerberos
authentication
features are required. IIS6 will actually do this for you automatically,
and it can be called programmatically via a new flag and arguments to
LsaLogonUser, or via the constructor on the
System.Security.Principal.WindowsIdentity class that simply takes the UPN
as
the only parameter. The net result is that a service can obtain a valid
logon token for a user with only their logon name and not their password.

The system imposes regulations on what can be done with this token.
Unless
the calling process identity has "act as part of the operating system"
privilege (which by default only SYSTEM has, not even local
administrators),
the token is identity level only, meaning that you can impersonate with
it,
but if you access a kernel object while impersonating (such as a file or
registry key), it will fail. It is also possible to implement delegation
scenarios with protocol transition-derived tokens, although only in
conjunction with constrained delegation (also a new 2K3 AD feature).
This
is basically what the "with any protocol" radio button option in
delegation
tab in ADUC does. In actually, it sets a different bit in
userAccountControl than the normal "allowed to delegate" bit.

One thing about constrained delegation is that it is limited to use
within a
single domain. You can't even hit another domain, much less a different
forest.

Interestingly, protocol transition is the primary mechanism that ADFS
uses
at the web server level to integrate federated authentication with
Windows
token-based web applications. They also have their own auth package that
they use to support 2000 AD forests (which appears to do something
similar
in a more limited way). Other SSO products like RSA ClearTrust use this
feature to achieve roughly the same thing.

All that said, I'm not sure the OP is correct in his assumption that
cross
forest authentication is done with NTLM by default. I think that is
still
Kerberos by default. I've never tried to do delegation (either
constrained
or non-constrained) in a multi-forest scenario, so I don't know if that's
possible. It is probably documented somewhere in the TechNet docs
though.
:) I've never tried to protocol transition in a multi-domain or
multi-forest scenario either, so I'm not sure what happens there.
However,
I'm not sure that protocol transition is needed here.

I can say for sure that almost all ASP.NET multi-tier delegation
scenarios
are hard to get working with a single domain forest, so if that's what
the
OP is trying to do with multiple forests, a world of suckage awaits.
:( I
consider myself pretty talented at this point at implementing delegation
scenarios, troubleshooting them and even getting them to work on the
first
try occasionally (rare, but it has happened at least once!). I would not
want to have to try it in this environment, though.

WS-Federation (active profile), WS-Trust and the WCF are going to make
these
scenarios totally doable, though, even between whole different companies
with no forest trusts at all (and possibly not even AD on the other
side).
We aren't quite there yet. ADFS might be able to make some of the pain
in
this scenario go away, though. I'd like to understand the problem
better.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Al Mulnick" <amulnick_No_SPAM@xxxxxxxxxxx> wrote in message
news:exwhydg2GHA.1568@xxxxxxxxxxxxxxxxxxxxxxx
I don't think I've heard that term before (protocol transitioning). Can
you
elaborate on your thoughts here? ( are you talking about ASP.NET related
protocol transitioning? Is this application an ASP.NET application?)

"I belive the default authentication in a cross forest scenario is
NTLM,
and
that Kerberos is not supported in this fashion. With that being said if
I
wanted to use Kerberos I would have to ensure the use of Protocol
Transition. "

For 2003 ffl/dfl forests, you can and should use kerberos.

What I'm not getting is why you want to have the complexity of a
resource
forest? I get the extranet being separate.

Al



"Chris Geier" <chris.geier at gmail.com> wrote in message
news:BC569C0F-A65A-4BE3-B5DC-13F1A55D7A67@xxxxxxxxxxxxxxxx
Greetings and thanks for reading,

I need to clarify some finer points of AD design. Here is my
hypothetical
design.

3 Forests.

User-Forest
Resource Forest
Extranet Forest

One way trusts exist betwen the user forest and the resource forest,
and
also between extranet forest and resource forest.

I belive the default authentication in a cross forest scenario is
NTLM,
and
that Kerberos is not supported in this fashion. With that being said
if I
wanted to use Kerberos I would have to ensure the use of Protocol
Transition.
However it is my understanding that a requirement for Protocol
Transition
is
a 2-way trust which is not in place in the above situation. So if I
have
a 3
tier application that resides in the resource forest where a service
in
tier
1 needs to access resources that reside in tier 2 as the user
connecting
to
them. An user account that would reside in the user forest. In order
for
this to work, I would need a 2 way forest trust, runiing windows 2003
in
native mode, or else this just will not work.

Am I wrong in the above scenario, or will a one way trust be
acceptable?








.

Quantcast