Re: Kerberos Problem with App Pool running as Domain Account
- From: "Ken Schaefer" <kenREMOVE@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 24 Jun 2008 22:58:02 +1000
You can not have the same SPN registered under more than one object (e.g. under two user accounts, or two computer accounts or a user account and a computer account).
If you read Part 1 in the FAQ I linked to, you will see the process that the DC uses to create the service ticket. It needs to know which password to encrypt the service ticket with. If you have SPNs under more than one account then the DC doesn't know which password to use, and Kerberos AuthN will fail.
Cheers
Ken
"VC" <VC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:9CB3FEF8-5D9E-4FE5-B6FB-B25C6952A8F0@xxxxxxxxxxxxxxxx
Yes. I talked to someone else yesterday and they suggested that since I have
SPNs registered for the DNS alias and the server name, that I should remove
the ones registered to the server name. Perhaps this is the "duplicates" that
Ken Schaefer was referring to. I'm going to try this today and reply to the
post.
"Consultant" wrote:
is the domain account it is running under "trusted for delegation"?
"VC" <VC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3630E23B-1C39-48A9-BE3F-AB25507AE8A1@xxxxxxxxxxxxxxxx
> Thank you for the response.
>
> There are some authentication types of "Negotiate" however, there are > no
> duplicate SPNs, and as far as I can tell everything is setup as it > should
> be.
> My only thought might be that the application pool is running under a
> domain
> account, perhaps IIS itself has to as well (instead of the > IUSR_IISSERVER
> account). But is this even supported, or likely to be the cause of the
> problem?
>
> Here is an error from the security log:
>
> Event Type: Failure Audit
> Event Source: Security
> Event Category: Logon/Logoff
> Event ID: 537
> Date: 6/23/2008
> Time: 10:36:56 AM
> User: NT AUTHORITY\SYSTEM
> Computer: IISSERVER
> Description:
> Logon Failure:
> Reason: An error occurred during logon
> User Name:
> Domain:
> Logon Type: 3
> Logon Process: Authz
> Authentication Package: Kerberos
> Workstation Name: IISSERVER
> Status code: 0xC000040A
> Substatus code: 0x0
> Caller User Name: IISSERVER$
> Caller Domain: TIB
> Caller Logon ID: (0x0,0x3E7)
> Caller Process ID: 1048
> Transited Services: -
> Source Network Address: -
> Source Port: -
>
> And here's the negotiate authentication which occurs after:
>
> Event Type: Success Audit
> Event Source: Security
> Event Category: Logon/Logoff
> Event ID: 528
> Date: 6/23/2008
> Time: 10:36:56 AM
> User: DOMAIN\USER
> Computer: IISSERVER
> Description:
> Successful Logon:
> User Name: user
> Domain: DOMAIN
> Logon ID: (0x0,0xA2489CC)
> Logon Type: 4
> Logon Process: Advapi
> Authentication Package: Negotiate
> Workstation Name: IISSERVER
> Logon GUID: {e241c991-82ad-2241-b533-510eff0f2c75}
> Caller User Name: IISSERVER$
> Caller Domain: DOMAIN
> Caller Logon ID: (0x0,0x3E7)
> Caller Process ID: 840
> Transited Services: -
> Source Network Address: -
> Source Port: -
>
> Any further help would be appreciated.
>
> "Ken Schaefer" wrote:
>
>> a) you need to make sure that the browser is authenticating using
>> Kerberos
>> (and not NTLM). Check the Windows Event logs for this
>>
>> b) you need to remove any duplicate SPNs you might have registered >> under
>> the
>> original computer account
>>
>> http://adopenstatic.com/faq has a list of IIS and Kerberos articles >> that
>> explain everything you ened to do/check.
>>
>> Cheers
>> Ken
>>
>> "VC" <VC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:394285B1-438C-42D7-8EA8-D35CFAF63CD5@xxxxxxxxxxxxxxxx
>> > Good Morning,
>> >
>> > I have multiple applications running with integrated security to
>> > connect
>> > to
>> > a SQL back-end database. Everything works fine on our production
>> > servers
>> > which use the default system accounts for the Application Pool.
>> > However,
>> > I
>> > had to change this to use a domain account because our DR server >> > needed
>> > to
>> > work with the same DNS Alias which conflicted with the already
>> > registered
>> > SPNs.
>> >
>> > As recommended, on our DR server, I began testing by changing the
>> > Application Pool to run under a domain account. I then registered >> > the
>> > following SPNs:
>> >
>> > setspn -A HTTP/iisserver domain\user
>> > setspn -A HTTP/iisserver.domain.com domain\user
>> > setspn -A MSSQLSvc/sqlserver:1433 domain\user
>> >
>> > Additionally, I set the domain\user account to "Account is trusted >> > for
>> > delegation" and the iiserver computer account to "Trust computer for
>> > delegation". Still, I receive the following error when connecting >> > to
>> > the
>> > database:
>> >
>> > Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
>> >
>> > This works fine on the live server, so I'm assuming this is related >> > to
>> > changing the Application Pool to run under a domain account. Any
>> > suggestions
>> > would be greatly appreciated.
>> >
>> > Thank you
>>
>>
.
- References:
- Kerberos Problem with App Pool running as Domain Account
- From: VC
- Re: Kerberos Problem with App Pool running as Domain Account
- From: Ken Schaefer
- Re: Kerberos Problem with App Pool running as Domain Account
- From: VC
- Re: Kerberos Problem with App Pool running as Domain Account
- From: Consultant
- Re: Kerberos Problem with App Pool running as Domain Account
- From: VC
- Kerberos Problem with App Pool running as Domain Account
- Prev by Date: Re: Kerberos Problem with App Pool running as Domain Account
- Next by Date: Re: FTP access issues
- Previous by thread: Re: Kerberos Problem with App Pool running as Domain Account
- Next by thread: Re: SelfSSL IIS 6.0
- Index(es):
Relevant Pages
|
