Serializing credentials and reauthenticating. How?

8 Oct 2008 10:16 AM

Gatecrasher

Can this be done in some way?

I have a .NET client.
I have an Aqualogic Service Bus (ALSB)
I have an IIS server

I am calling a Web Service on ALSB which goes on to call Web Service on IIS

The ALSB is configured with ANON security to avoid a credential store
IIS is configured ANON because NTLM, Kerberos is bounced by ALSB and there
is no impersonation in ALSB

I want to be sure the original caller is logged into the domain when we get
to IIS. I want to do the following.

Get the Current Users Kerberos ticket (they are logged onto a domain)
Serialize this token and put into SOAP Header as an encoded string (or
something). This passes all the way to IIS untouched
A HTTP extension on IIS de-serializes ticket and checks it is still valid
against DC

Can this or something similar be achieved?

I don't want to change security settings or introduce extra servers, like
ADFS.

Cliff

8 Oct 2008 7:34 PM

Joe Kaplan

If you need to call the IIS server using integrated authentication and have
some control over the proxy client that the ALSB uses to call IIS, then you
could probably make this work. However, it would be much easier to use
Kerberos S4U and constrained delegation to accomplish this. S4U allows you
to generate a Kerb ticket for a user given only their username and
constrained delegation allows you to impersonate that token locally so that
you can use it to access another resource on the network. Using an approach
like this allows the IIS server to just receive normal Kerberos
authentication and is thus much cleaner. You would just need the user's
username as input, so you would likely pass that through a SOAP header. You
would need to decide if you wanted to include any additional
authentication/authorization into the proxy client itself.

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

Show quoteHide quote

"Gatecrasher" <Gatecras***@discussions.microsoft.com> wrote in message
news:563D718F-B194-4585-987F-C4555939B8F6@microsoft.com...
> Can this be done in some way?
>
> I have a .NET client.
> I have an Aqualogic Service Bus (ALSB)
> I have an IIS server
>
> I am calling a Web Service on ALSB which goes on to call Web Service on
> IIS
>
> The ALSB is configured with ANON security to avoid a credential store
> IIS is configured ANON because NTLM, Kerberos is bounced by ALSB and there
> is no impersonation in ALSB
>
> I want to be sure the original caller is logged into the domain when we
> get
> to IIS. I want to do the following.
>
> Get the Current Users Kerberos ticket (they are logged onto a domain)
> Serialize this token and put into SOAP Header as an encoded string (or
> something). This passes all the way to IIS untouched
> A HTTP extension on IIS de-serializes ticket and checks it is still valid
> against DC
>
> Can this or something similar be achieved?
>
> I don't want to change security settings or introduce extra servers, like
> ADFS.
>
> Cliff
>

8 Oct 2008 9:01 PM

Gatecrasher

Hi

Thanks for getting back on this...

My skills in ALSB are such that tweaking its proxy is beyond me!

I am curious about this S4U, where can I find out about it with regards to
..NET etc?

I searched for hours looking for info about creating tickets and found
nothing! So let me understand this...

I configure IIS for Kerberos, which is the NTLM check box. Correct? When I
have done this before it fails because the ALSB refuses the authorisation
request.

I have already passed the user name from client to IIS in a SOAP header.

What the company is trying to do is check that the client is a valid domain
user, just as it would if it was client to IIS with integrated security.
Once inside IIS we impersonate a fixed single account to talk to SQL Server.
The managment have bought this ALSB and dropped it in the middle!!

It insists on a local account store if the client side service has anything
but ANON. It also suffers talking to IIS in that NTLM is bounced. You only
have XPath/XQuery type field replacement for this proxy, no real programming
access that I can see.

If I pass username in a SOAP header it could be spoofed by any valid domain
user account name. How do I know its an authenticated user?

Any advice appreciated :)

Cliff

Show quoteHide quote

"Joe Kaplan" wrote:

> If you need to call the IIS server using integrated authentication and have
> some control over the proxy client that the ALSB uses to call IIS, then you
> could probably make this work. However, it would be much easier to use
> Kerberos S4U and constrained delegation to accomplish this. S4U allows you
> to generate a Kerb ticket for a user given only their username and
> constrained delegation allows you to impersonate that token locally so that
> you can use it to access another resource on the network. Using an approach
> like this allows the IIS server to just receive normal Kerberos
> authentication and is thus much cleaner. You would just need the user's
> username as input, so you would likely pass that through a SOAP header. You
> would need to decide if you wanted to include any additional
> authentication/authorization into the proxy client itself.
>
> 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
> --
> "Gatecrasher" <Gatecras***@discussions.microsoft.com> wrote in message
> news:563D718F-B194-4585-987F-C4555939B8F6@microsoft.com...
> > Can this be done in some way?
> >
> > I have a .NET client.
> > I have an Aqualogic Service Bus (ALSB)
> > I have an IIS server
> >
> > I am calling a Web Service on ALSB which goes on to call Web Service on
> > IIS
> >
> > The ALSB is configured with ANON security to avoid a credential store
> > IIS is configured ANON because NTLM, Kerberos is bounced by ALSB and there
> > is no impersonation in ALSB
> >
> > I want to be sure the original caller is logged into the domain when we
> > get
> > to IIS. I want to do the following.
> >
> > Get the Current Users Kerberos ticket (they are logged onto a domain)
> > Serialize this token and put into SOAP Header as an encoded string (or
> > something). This passes all the way to IIS untouched
> > A HTTP extension on IIS de-serializes ticket and checks it is still valid
> > against DC
> >
> > Can this or something similar be achieved?
> >
> > I don't want to change security settings or introduce extra servers, like
> > ADFS.
> >
> > Cliff
> >
>
>
>

8 Oct 2008 9:21 PM

Gatecrasher

I forgot to say that all this sits in an Intranet.

I could create a web service on an NTLM protected IIS box and issue a GUID
and timeout. When I hit my other IIS box I check back through another web
service to see if that token is valid etc etc.

I just hoped that a AD controller could issue a Kerberos ticket (or
something) that says "I gave this to a valid domain user" and the later from
the IIS server I could pass this ticket to the AD server and say "did you
issue this".

We may go SSL/Basic from client to ALSB. Then pass (I think i can do this)
the username and password in the "proxy" from ALSB to IIS, again using Basic
and SSL.

Cliff

Show quoteHide quote

"Joe Kaplan" wrote:

> If you need to call the IIS server using integrated authentication and have
> some control over the proxy client that the ALSB uses to call IIS, then you
> could probably make this work. However, it would be much easier to use
> Kerberos S4U and constrained delegation to accomplish this. S4U allows you
> to generate a Kerb ticket for a user given only their username and
> constrained delegation allows you to impersonate that token locally so that
> you can use it to access another resource on the network. Using an approach
> like this allows the IIS server to just receive normal Kerberos
> authentication and is thus much cleaner. You would just need the user's
> username as input, so you would likely pass that through a SOAP header. You
> would need to decide if you wanted to include any additional
> authentication/authorization into the proxy client itself.
>
> 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
> --
> "Gatecrasher" <Gatecras***@discussions.microsoft.com> wrote in message
> news:563D718F-B194-4585-987F-C4555939B8F6@microsoft.com...
> > Can this be done in some way?
> >
> > I have a .NET client.
> > I have an Aqualogic Service Bus (ALSB)
> > I have an IIS server
> >
> > I am calling a Web Service on ALSB which goes on to call Web Service on
> > IIS
> >
> > The ALSB is configured with ANON security to avoid a credential store
> > IIS is configured ANON because NTLM, Kerberos is bounced by ALSB and there
> > is no impersonation in ALSB
> >
> > I want to be sure the original caller is logged into the domain when we
> > get
> > to IIS. I want to do the following.
> >
> > Get the Current Users Kerberos ticket (they are logged onto a domain)
> > Serialize this token and put into SOAP Header as an encoded string (or
> > something). This passes all the way to IIS untouched
> > A HTTP extension on IIS de-serializes ticket and checks it is still valid
> > against DC
> >
> > Can this or something similar be achieved?
> >
> > I don't want to change security settings or introduce extra servers, like
> > ADFS.
> >
> > Cliff
> >
>
>
>

9 Oct 2008 1:20 AM

Joe Kaplan

If you can capture the plaintext password of the user, then you can delegate
however you want. In many circumstances you don't get that so it isn't an
option.

Regarding S4U (also called protocol transition logon), this is available in
..NET using the constructor on WindowsIdentity that just takes a username.
You create the identity, impersonate it, set your web service proxy to use
default credentials and you can then use that to connect to remote services
if your calling process is trusted for delegation with any protocol in AD
and you have constrained delegation rights to the target. The target must
also take Kerberos auth.

In IIS, to get Kerberos you need to enable IWA auth and ensure the metabase
is set to challenge for Negotiate instead of just NTLM. Negotiate is the
default, but sometimes this gets changed. You also need a valid SPN in AD
for the host name you are using. That is probably set by default if you use
the machine name as the host name and the IIS server runs as network service
(which is default).

There are lots of documents on Kerberos S4U, constrained delegation and
Kerberos auth in general on the various MS websites, so just search for
them.

If the service bus can't do that, then it probably isn't an option. You
could implement a proxy in front of the IIS service that translates
something proprietary coming out of the service bus into standard Kerberos
using the mechanism I described, but that adds to the complexity.

Good luck figuring this out. My experience with these service bus things is
that people rarely think about these details when they put them in. :)

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"Gatecrasher" <Gatecras***@discussions.microsoft.com> wrote in message
news:08BFFCFF-CBD9-4380-9468-7DF5A1FCBB2A@microsoft.com...
>I forgot to say that all this sits in an Intranet.
>
> I could create a web service on an NTLM protected IIS box and issue a GUID
> and timeout. When I hit my other IIS box I check back through another web
> service to see if that token is valid etc etc.
>
> I just hoped that a AD controller could issue a Kerberos ticket (or
> something) that says "I gave this to a valid domain user" and the later
> from
> the IIS server I could pass this ticket to the AD server and say "did you
> issue this".
>
> We may go SSL/Basic from client to ALSB. Then pass (I think i can do this)
> the username and password in the "proxy" from ALSB to IIS, again using
> Basic
> and SSL.
>
> Cliff
>
> "Joe Kaplan" wrote:
>
>> If you need to call the IIS server using integrated authentication and
>> have
>> some control over the proxy client that the ALSB uses to call IIS, then
>> you
>> could probably make this work. However, it would be much easier to use
>> Kerberos S4U and constrained delegation to accomplish this. S4U allows
>> you
>> to generate a Kerb ticket for a user given only their username and
>> constrained delegation allows you to impersonate that token locally so
>> that
>> you can use it to access another resource on the network. Using an
>> approach
>> like this allows the IIS server to just receive normal Kerberos
>> authentication and is thus much cleaner. You would just need the user's
>> username as input, so you would likely pass that through a SOAP header.
>> You
>> would need to decide if you wanted to include any additional
>> authentication/authorization into the proxy client itself.
>>
>> 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
>> --
>> "Gatecrasher" <Gatecras***@discussions.microsoft.com> wrote in message
>> news:563D718F-B194-4585-987F-C4555939B8F6@microsoft.com...
>> > Can this be done in some way?
>> >
>> > I have a .NET client.
>> > I have an Aqualogic Service Bus (ALSB)
>> > I have an IIS server
>> >
>> > I am calling a Web Service on ALSB which goes on to call Web Service on
>> > IIS
>> >
>> > The ALSB is configured with ANON security to avoid a credential store
>> > IIS is configured ANON because NTLM, Kerberos is bounced by ALSB and
>> > there
>> > is no impersonation in ALSB
>> >
>> > I want to be sure the original caller is logged into the domain when we
>> > get
>> > to IIS. I want to do the following.
>> >
>> > Get the Current Users Kerberos ticket (they are logged onto a domain)
>> > Serialize this token and put into SOAP Header as an encoded string (or
>> > something). This passes all the way to IIS untouched
>> > A HTTP extension on IIS de-serializes ticket and checks it is still
>> > valid
>> > against DC
>> >
>> > Can this or something similar be achieved?
>> >
>> > I don't want to change security settings or introduce extra servers,
>> > like
>> > ADFS.
>> >
>> > Cliff
>> >
>>
>>
>>