Re: Single Sign On using NTLM


You should be able to Kerb auth from your client to your server by specifying an SPN on the service account that runs the service and then specifying that SPN in your target parameter for your NegotiateStream. However, you may not need to.

It may be much easier to implement protocol transition logon at the server service and then using constrained delegation to the IIS web service. This type of solution is frequently used in cases where it is difficult or impossible to guarantee Kerberos login at the front end of your application but you still need to delegate.

Getting this working can be a bit of a pain and will likely require that you read up on the TechNet docs on implementing constrained delegation and protocol transition. Here are some high level requirements:

- You must have a 2003 Forest Function Level AD or higher to use protocol transition. No 2000 AD forests or 2003 mixed mode.
- Protocol transition logon also requires constrained delegation as it cannot be used in unconstrained mode
- Servers participating must be 2003 or higher
- You must have working Kerberos authentication to the backend (IIS web service in your case)

The way I usually approach this is to ensure I've got Kerb auth to the backend verifying that the SPN for the DNS name of the service is properly set on the service account running the service. I use the wfetch tool from the IIS6 res kit for testing Kerb auth as it bypasses some of the weirdness you'll sometimes see with IE as a Kerb client.

Then, I configure the delegation settings on the front end service account (trusted for delegation "with any protocol" and configured to delegate to the SPN of the backend service). Then I try to see if I can get it to work. Usually the security event log on the backend server is the most useful tool to verify the type of authentication being performed. If you see the NTLM SSP being used to log in the anonymous account, delegation is not working. :)

Best of luck getting this sorted. These types of architectures are totally possible to build in Windows, but they can be a real pain to get working.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Stefan L" <slueck@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:uaZdH5zeJHA.1272@xxxxxxxxxxxxxxxxxxxxxxx
Hi again,

thanks for the hint, I got the NegotiateStream basically working but ran directly in the next problem:

We also run a WebService that is configured for SSO (NTLM per HTTP) and hosts functionality that needs to be accessed from our proprietary server in the name of the calling client (ask for private folders, etc.).

Looks like this:
Client --> Server (impersonate) --> IIS-WebServer (AccessDenied)

I found that I need impersonation with permission to delegate, and here's the problem. NegotiateStream always selects NTLM and eventually TokenAccessLevel is only Impersonation, not Delegation. That results in the fact, that the "delegation"-scenario is only working, if the WebServer and other Server are run on the same machine.

I'm not sure what I have to do to come over this. I guess my problem is, that I do not have an SPN defined when calling AuthenticateAsClient, which is needed for Kerberos and delegation.
Documentation seems to be sparse here, I didn't even really find out what an SPN is. I tried all kinds of things for SPN here, like specifying the account name "<domain>\<serviceaccountname>" or something like "HOST/<ServerName>". Nothing.

- Is there any good documentation available on using (creating?) SPNs (for users of .NET 2.0)?
- Is it really the missing/wrong SPN causing the trouble here?
- How likely is it that I did all right and the PDC is not configured correctly (Our netwerk clerk was not that much of a help here...)?

I know my questions are hard to answer, but I would really appreciate if anyone could help me here...

TIA,
Stefan



Joe Kaplan schrieb:
You can wrap your NetworkStream in a NegotiateStream to get this functionality. This will give you NTLM or Kerberos, depending on how your server is configured.

It is possible to write your own lower level wrappers around the Windows authentication APIs (InitializeSecurityContext, etc.) to implement Negotiate authentication, but it is a lot more work. It is much easier to use NegotiateStream.


.

Relevant Pages

  • Re: SPN for SSL over common name
    ... you can't register those SPNs under the SQL Server's ... service account is the MSSQL SPN. ... That SPN should be registered under ... Lastly, since the SQL Server is not being used for delegation anywhere, ...
    (microsoft.public.inetserver.iis.security)
  • Re: SPN for SSL over common name
    ... you can't register those SPNs under the SQL Server's ... That SPN should be registered under the SQL ... Server's service account and *removed* from the SQL ... Lastly, since the SQL Server is not being used for delegation anywhere, ...
    (microsoft.public.inetserver.iis.security)
  • Re: Delegation: IIS Server setup in typical 3-tier scenario.
    ... doesn't already have an SPN and/or you need to change the existing SPN. ... Kerberos is being used - it just means that an API is used to determine what ... so I'm trying to set up delegation. ... Authenticated using NTLM not Kerberos on the Web Server. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Constrained delegation question!
    ... You are right there is a service called HOST on the target server which I ... You should not need to create a new SPN though. ... Active Directory under the delegation tab, ... For allowing Service Control Manager, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Constrained delegation question!
    ... You are right there is a service called HOST on the target server which I ... You should not need to create a new SPN though. ... Active Directory under the delegation tab, ... For allowing Service Control Manager, ...
    (microsoft.public.dotnet.framework.aspnet.security)