Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis <BradleyLandis@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 9 Apr 2007 07:52:05 -0700
I managed to get something useful out of the trace. What I found is that it
is looking for the SPN as HTTP/<DNS NAME> instead of HTTP/<NETBIOS NAME>.
What I mean by that is we have a friendly name set up in DNS so that users
can type something like http://intranet into their web browser. So it is
looking for the SPN HTTP/intranet and getting a "server not found in kerberos
database" error.
"Joe Kaplan" wrote:
I'm glad protocol transition provided a usable solution for you. At least.
you had that option. :)
FWIW, when the negotiate protocol "negotiates" down to NTLM instead of using
Kerberos, in my experience I don't usually see any Kerb packets in the
network trace. Something Negotiate does before that causes the selection to
be made, possibly with DNS or some sort of RPC call. As such, it can be
difficult to figure out why Kerb wasn't used when looking at the trace. If
you expand what you are filtering on, you might get a better clue.
I also suggest asking for some additional help on this type of thing from
one of the other security groups like microsoft.public.platformsdk.security
or something. One of those guys may have some additional suggestions on
what to look for and how to fix it.
Best of luck!
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
--
"Bradley Landis" <BradleyLandis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:AFB862CC-0241-4073-AE52-92D9C6CBA252@xxxxxxxxxxxxxxxx
We really didn't want to but we had to enable protocol transition for now
to
eleviate the pain of the users. We figure that we can keep working on it
because we can look at the logs and see if NTLM is still occuring.
I have tried to run a network trace, but when I filter the results on
Kerberos I get no results. Even when I purge the tickets, start the trace
and watch a ticket appear in kerbtray.
So we will keep trying. Thanks for your help Joe.
"Joe Kaplan" wrote:
It is ok to have both HTTP/ and HOST/ SPNs for the same service name, as
long as they are all on the same account. They are redundant, but won't
cause a problem.
The problem I see frequently is that people have duplicate SPNs on more
than
one different account. That usually produces Kerberos errors.
One of the subtle problems that can happen is that since HOST/ is an
alias
for a bunch of different service types including HTTP, you can end up
with
multiple matches on different accounts, even if the SPNs aren't
identical.
It still isn't clear to me why Kerberos isn't working if the
HTTP/webserver
SPN exists on the account that is running the service. As far as I know,
that should work. A network trace might reveal more details though.
Interesting problem you have here. :)
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
--
"Bradley Landis" <BradleyLandis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:1B12E0CC-4C91-46A7-80E8-B2137A868D33@xxxxxxxxxxxxxxxx
Okay, the problem with the second search was that I was putting:
(servicePrincipalName=WEBSERVER)
instead of:
(servicePrincipalName=HTTP/WEBSERVER)
so that search is working as well now.
I will try to remove the HOST/WEBSERVER SPNs and see if that does the
trick.
I believe the browser is requesting kerberos, but it is requesting it
with
the Netbios name instead of the FQDN. Since the SPN for the Netbios
name
is
not configured properly, it negotiates down to NTLM.
"Joe Kaplan" wrote:
I'm not a GPO guy at all, so I'd suggest asking the domain policy
question
on one of the AD or GPO groups. If I had to guess, I'd say that
perhaps
the
policy didn't get applied locally for some reason, but I really don't
know
and you don't want someone with my level of familiarity on GPO to be
providing you with answers to important questions like that anyway.
:)
For the second search, if the user account has an SPN of
HTTP/webserver,
then you should be able to find it with a search filter like:
servicePrincipalName=HTTP/webserver
also, it is probably a good idea to check to see if any accounts have
HOST/webserver registered, as HOST is an alias for HTTP among other
things
and could cause an ambiguity.
That said, I still don't know why the browser doesn't request Kerb
auth
after 30 minutes. Perhaps it is trying to use a different name than
the
webserver name or something? Perhaps there is an alias/CNAME in DNS
that
might be causing something to work differently than you think? I
really
don't know. It could be hard to solve.
Protocol transition could potentially be a workaround here, as it
would
allow the web server to do NTLM and still allow kerberos delegation to
a
different tier. Still, it would be better to just solve the root
cause
issue first.
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
--
"Bradley Landis" <BradleyLandis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:A7F87C06-44AA-45D5-91FE-418B1AD7E885@xxxxxxxxxxxxxxxx
Thanks Joe,
I had no problem running the query. I think we did have some extra
SPNs
in
there so we removed them.
Now when I do the first search, I only see HTTP/<WEBSERVER> and
HTTP/<WEBSERVER>.<DOMAIN>.COM
When I do the second search you gave me, I get 0 results. Which I
think
is
correct.
We are still having the problem.
Another problem we encountered was when we set the "Impersonate
client
after
authentication" on our domain policy, many users experienced issues
where
programs that required administration privelages to run no longer
functioned.
These included virus scan, windows desktop search, word as e-mail
editor,
etc. So we took that out of the domain policy and are in the
process
of
adding it to the local policy now. We cannot figure out why that
would
have
affected users so badly. Any ideas there?
"Joe Kaplan" wrote:
I use an ldap query tool like ldp.exe to do this. If you do a
search
for
the object in question (the user account) with a filter like:
(sAMAccountName=xxxxx)
where xxxxx is the username of the user account that runs the
service.
Have
the LDAP search return these attributes:
servicePrincipalName;userAccountControl;msds-allowedToDelegateTo
You should then be able to see the SPNs that are on that account.
The
servicePrincipalName is the key value, but userAccountControl
allows
you
to
see what delegation permissions the account has and
msds-allowedToDelegateTo
shows what (if any) constrained delegation values are applied.
There is a chance that you have a duplicate SPN here with the
machine
account and that could be a problem. Searching with a filter like:
(servicePrincipalName=xxxxx)
where xxxxx is the NetBIOS SPN in question should reveal that. You
should
do the search at the global catalog level though if you have
multiple
domains in your forest.
I might be assuming too much if you've never done much LDAP
searching
though, so let me know and I'll try to provide more details if that
info
wasn't sufficient.
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
--
"Bradley Landis" <BradleyLandis@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:39E66674-BCDB-4788-A315-EFFC6691AC2F@xxxxxxxxxxxxxxxx
Yes thank you very much for the info about the 30 minute behavior
in
IE.
I
think that is definitely related. But I do believe that we have
both
the
FQDN and the NetBios set up with SPNs. One thing we cannot
figure
out
is
how
to list them since they are associated to a domain account.
setspn -L <COMPUTER NAME>
will list them for the default account of the computer but
doesn't
seem
to
show those for the domain account.
Anyone know how to list them for the domain account?
"Joe Kaplan" wrote:
That's interesting info. Thanks Henning!
I think the behavior IE is showing is a bit bizarre, but it is
good
to
know
it exists. It sounds like the key thing is to make sure the SPN
is
registered for the NetBIOS name as well so it can do Kerb.
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
--
"Henning Krause [MVP - Exchange]"
<newsgroups_remove@xxxxxxxxxxxxxxxxx>
wrote in message news:eLklU2sdHHA.4696@xxxxxxxxxxxxxxxxxxxxxxx
Hello,
the Internet Explorer reverts from the domain name to the
netbios
name
for
some reason after 30 minutes. It's explained here:
http://support.microsoft.com/kb/871179
This might help.
Best regards,
Henning Krause
"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote
in
message
news:ew67WVkdHHA.3632@xxxxxxxxxxxxxxxxxxxxxxx
That's pretty weird. Are you auditing logon success events
- Follow-Ups:
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- References:
- Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- From: Henning Krause [MVP - Exchange]
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- From: Bradley Landis
- Re: Integrated Windows Authentication Timeout?
- From: Joe Kaplan
- Re: Integrated Windows Authentication Timeout?
- Prev by Date: Re: Integrated Windows Authentication Timeout?
- Next by Date: Re: Integrated Windows Authentication Timeout?
- Previous by thread: Re: Integrated Windows Authentication Timeout?
- Next by thread: Re: Integrated Windows Authentication Timeout?
- Index(es):
Relevant Pages
|