Re: Cross Forest Authentication

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

I think I have read through everything on Kerberos and Cross forest
authentication and I am still not 100% about the specifics of this situation.
Let me try to explain a bit better

I have a multi-tier applicaiton that resides in the resouce forest where the
Webpage in tier 1 needs to use Kerberos Delegation of authentication to
connect to an applicaiton server in tier 2 in that same resource forrest.
The web identity and the applicaiton identity are both operating as named
account that also reside in the resource forest. Now when a normal every day
user account needs to interact with this 3 tier app, it does so with a user
account that resides in the Account Forest that is trusted by the resource
forest.

Can this delegation of authentication happen in the application given that
the user account to be delegated is not only in a seperate forest but only
has a 1 way forest trust.
I know for 100% that this is not possible in a basic W2K forest. I thought
this was not the case even in W2K3 without a 2 way trust but the more I
research and read the more I am not sure about that. But I would love to
find someone that has done this or knows for sure.

I am begning to postulate that with a W2K3 native mode, and a forest trust
the rules may have changed and that it is possible, but again I am not sure.

Did that make it more clear?

"Joe Kaplan" wrote:

I think you need to dig around deeply in the big Kerberos delegation
whitepapers posted on TechNet. This level of detail regarding how things
work in multi-forest situations is probably only going to be found there, if
at all. Unfortunately, these documents tend to be a little scary long
(20-40 pp), but hopefully you can find the answer. If I knew exactly where
to send you, I would.

I'm sure there is someone from MS who knows too, but I'm not sure if they'll
see this, especially in this group. On thing to keep in mind is that MS
does not automatically answer your question for you unless you post with one
of those registered email addresses (available via the MSDN homepage
somewhere).

I also agree with Al in that I think I might be able to give you more useful
advice if you provided more details about exactly what you are trying to
accomplish.

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
--
"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