Announcement

Collapse
No announcement yet.

setspn.exe and windows integrated authentication

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • setspn.exe and windows integrated authentication

    Problem solved, scroll down for solution.


    The main IIS server is the companys SBS2003, I've made an application that I run on another Windows Server 2003 with IIS. The other server is a member of the domain, all is fine and dandy. I have disabled Anonymous access in the other servers IIS since I need the username for the application to work, instead I've configured the IIS to use Integrated Windows Authentication. The problem is that I cannot access the application I created without entering a the Username and Password. I get a Username/Password prompt, I enter my domain username and password and I'm granted access. I thought that worked automatically?

    In an attempt to make it work automatically I googled for some tips and now I fear I've done something stupid. I followed theese instructions and now I cannot log on to the website even if I supply the domain username and password. Local accounts are working.

    1) Create a Domain account that the Application Pool can run as.

    2) Configure all of your application pools that will use Integrated authentication to run as this domain User.

    3) Add this Domain Account to the IIS Machines local IIS_WPG Group.

    4) On your domain controller open active directory users and computers and select the properties for the domain account you created. On the accounts tab, check the "Account is trusted for delegation" option.

    5) On the domain controller use setspn.exe(Resource Kit Tool, see link below) in order to associate the HTTP service on the IIS 6.0 Machine with this user account

    a. Setspn.exe -A HTTP/Machine domain\user

    b. Setspn.exe -A HTTP/Machine.domain.com(Fully Qualified Domain Name) domain\user

    You can obtain setspn.exe from here:

    <http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.asp>

    After doing this, you will need to reset IIS, and you may need to expire any tickets on your client machine you are using for testing.


    In my case I created a domain user called IIS_APP, I made the Application pool use that account and I added it to the local group IIS_WPG on the web server. After I had done that I allowed the account to delegate and registered it according to 5a and 5b.

    Is there a way that I can restore the original settings, before I changed them with setspn.exe?

    Is there another way to stop the webserver from prompting for Username and Password?


    Please let me know if you need more information.

    Thanks in advance guys!
    Last edited by Anders; 24th October 2006, 11:54.
    A wise man once said: "Assumption is the mother of all fu*k ups".

    Any advice I give is to the best of my knowledge, there is no guarantee what so ever that it will actually work in your particular scenario. I will not accept any responsibility for unexpected consequences, after all - you are taking advice from a complete stranger over the internet. =)

  • #2
    Re: setspn.exe and windows integrated authentication

    (problem solved, scroll down for a solution)

    Working on a solution to my problem, managed to reset the changes I made using setspn.exe -r [HOSTNAME]

    It's still not working and I can see that
    C:\Documents and Settings\Administrator>Setspn.exe -R [HOSNAME] Registering ServicePrincipalNames for CN=[HOSTNAME],OU=SBSServers,OU=Computers,OU=MyBusiness,DC=[DOMAIN],DC=internal
    HOST/[HOSTNAME]$.[DOMAIN]
    HOST/[HOSTNAME]$
    Updated object

    It is still not working, so I looked up why. According to this KB the problem with setspn.exe occurs because a function that the Setspn.exe tool uses returns the name of the computer together with a dollar sign character (also known as a string). The Setspn.exe tool incorrectly adds this string to the computer name.

    When you run the Setspn.exe -R servername command to reset a service principal name (SPN) for a computer account in the Active Directory directory service, the following results appear at the command prompt:

    Registering ServicePrincipalNames for CN=<serverName>,CN=Computers,DC=example,DC=com
    HOST/<serverName>$.EXAMPLE
    HOST/<serverName>$
    Updated object

    In these results, the Setspn.exe tool incorrectly adds the dollar sign ($) to the host name. The results should appear as follows:

    Registering ServicePrincipalNames for CN=<serverName>,CN=Computers,DC=example,DC=com
    HOST/<serverName>.EXAMPLE
    HOST/<serverName>
    Updated object

    Therefore, the SPN is configured incorrectly.


    Work around:
    Modify the servicePrincipalName attribute in Active Directory. To do this, follow these steps:
    1. Start the ADSI Edit tool. To do this, click Start, click Run, type adsiedit.msc, and then click OK.

    Note The ADSI Edit tool is included with the Windows Server 2003 Support Tools.
    2. Connect to a domain controller if ADSI Edit is not already connected to a domain controller.
    3. Expand Domain [domainControllerName.example.com], expand DC=example,DC=com, and then expand CN=Computers.

    Note If the computer for which you want to modify the SPN is located in a different container, modify this path as appropriate.
    4. Right-click CN=serverName, and then click Properties.
    5. On the Attribute Editor tab, click to select both the following check boxes:
    • Show mandatory attributes
    • Show optional attributes
    6. In the Attributes list, click servicePrincipalName, and then click Edit.
    7. In the Multi-valued String Editor dialog box, click HOST/serverName$, and then click Remove. This value appears in the Value to add box.
    8. Modify the entry in the Value to add box to remove the dollar sign ($), and then click Add.

    Note If this entry already appears in the Values list, do not add it.
    9. Click HOST/serverName$.EXAMPLE, and then click Remove. This value appears in the Value to add box.
    10. Modify the entry in the Value to add box to remove the dollar sign ($), and then click Add.

    Note If this entry already appears in the Values list, do not add it.
    11. Click OK two times, and then exit the ADSI Edit tool.


    All according to http://support.microsoft.com/kb/924177

    This, how ever, did not help me.
    It still asked me for username and password when I try to access the webpage - and the domain accounts are not allowed access while the local accounts are.

    Solution
    I used the information from the KB and started looking around with the adsiedit.msc tool, I looked at the domain controller, which had many entries in the servicePrincipalName attribute. I found a common denominator, all the hostnames were preceeded by the service. Example:
    DNS/[HOSTNAME]
    MSSQLSvc/[HOSTNAME]
    ldap/[HOSTNAME]

    So I applied this information when editing the servicePrincipalName attribute that I had reset earlier. I added theese entries as strings in the servicePrincipalName attribute ,at the web server object, with adsiedit.msc:
    HOST/[HOSTNAME]
    HOST/[HOSTNAME].[DOMAIN]
    HTTP/[HOSTNAME]
    HTTP/[HOSTNAME].[DOMAIN]
    And now it works.
    Last edited by Anders; 24th October 2006, 11:56.
    A wise man once said: "Assumption is the mother of all fu*k ups".

    Any advice I give is to the best of my knowledge, there is no guarantee what so ever that it will actually work in your particular scenario. I will not accept any responsibility for unexpected consequences, after all - you are taking advice from a complete stranger over the internet. =)

    Comment


    • #3
      Re: setspn.exe and windows integrated authentication

      Anders, thanks for posting the solution that worked for you and well done on solving it in less than 47 minutes. Good Job!!
      1 1 was a racehorse.
      2 2 was 1 2.
      1 1 1 1 race 1 day,
      2 2 1 1 2

      Comment


      • #4
        Re: setspn.exe and windows integrated authentication

        To be honest the time it took me was between 10:30 and 12:56, but I had an hour lunch break in between so I figure it took me about 1.5 hours Man - I really thought I had screwed something up and I had a hard time finding people with the same problem that I could look upon for help.
        A wise man once said: "Assumption is the mother of all fu*k ups".

        Any advice I give is to the best of my knowledge, there is no guarantee what so ever that it will actually work in your particular scenario. I will not accept any responsibility for unexpected consequences, after all - you are taking advice from a complete stranger over the internet. =)

        Comment

        Working...
        X