Re: Double hop
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 20 Nov 2006 23:30:06 -0600
Ok, so is the front end web server calling a back end web server (like a web
service) and trying to delegate that way?
If so, then the first thing to do is to make sure you can hit the back end
web directly from the browser or some other client and get Kerberos auth.
All the same things that applied to front end web server would apply to the
backend as well.
Then, the next thing to do is check to make sure the SPNs are all correct.
You want to have the back end server's service account have an SPN that
matches the host name part of the URL you are using to connect to the
backend. Even though you said you've got the SPNs all put together, I'm
guessing that there is something wrong here which is causing the NTLM
failover. It is also important to make sure there are no duplicates of that
SPN in the forest. I'm guessing again there aren't, but try to make sure.
I usually use an LDAP search tool against the global catalog to check.
There is another tricky thing I've run into which is that if you are using a
DNS name in the URL (instead of a short NetBIOS name) and that DNS name is a
CNAME in DNS, Kerberos may actually resolve that to the A record and build
the SPN using the A record's DNS name. Then, if another account has that
SPN, it won't work. This has screwed me in the past.
The good news is that once you get Kerberos between the front end web server
and the back end, you should delegate just fine. :) Seriously, I wish this
stuff was more straightforward to troubleshoot. The good news is that
you'll know a lot more about it for the next time you do this. If it all
worked on the first try, you wouldn't have any idea why.
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
--
"Johann Granados" <JohannGranados@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:89182EEA-C21E-444D-B2A4-46D7EB4FAAB5@xxxxxxxxxxxxxxxx
Hi Joe,
Thank you very much for your kind reply.
I'm still trying to solve the double hop issue. I turned on the security
audit logs and installed the IEHttpHeaders application. By using both
tools
I realized that Kerberos Authentication is being used between client and
middle server (ServerA) but NTLM is being used between middle server and
the
back end (Server B). Both IIS Worker Process use the same Identity and
the
SPN have been set for that identity (HOST/ServerA, HOST/ServerB, HOST
ServerA.DoubleHop.com, HOST Serverb.DoubleHop.com -same entries for http
server class-). Both server have been set up as trusted for delegation.
Do
you know how can I troubleshoot the authentication process between ServerA
and ServerB in order to realize why both machines are using NTLM
Authentication and not Kerberos Authentication.
Best regards,
Johann Granados
--
"Joe Kaplan" wrote:
The best way is to enable auditing of logon events in the security event
log
on the web server and looking to see what kind of authentication was
actually performed in the details of the logon messages. If you see NTLM
instead of Kerberos mentioned, that is bad. :)
Another technique I like to use is to look at the headers being exchanged
between the browser and the web server. I like a tool called
IEHttpHeaders
for this (www.blunck.info), but there are other ways. This tool is an IE
add-in that adds a menu option to Explorer Bar menu that shows a pane
with
the request and response headers.
When the server is allowing Kerberos auth, it will send back a 401
response
with a www-authenticate header containing "Negotiate". If it just
contains
"NTLM", that is bad. Sometimes it contains both and that is ok, as long
as
Negotiate is first.
If "Negotiate" is not in the www-authenticate header, then the IIS
metabase
is misconfigured (probably by SharePoint) and you'll never get Kerberos
auth. This must be fixed first.
If the server is responding with "negotiate" but the browser is still
doing
NTLM (this is allowed, as negotiate auth picks a protocol that both
client
and server can use), then the problem is typically that of service
principal
names not being set correctly (although it could be a bunch of other
stuff).
I usually check to see if the IIS app pool identity (or the machine
account
is NETWORK SERVICE is used) has a servicePrincipalName attribute in AD
set
that matches the URL being used by the browser.
Let's see how far you get with those steps before digging into SPN
mismatch
issues though. :)
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
--
"Johann Granados" <JohannGranados@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:7349338F-DA9D-4DE1-A121-235494D9772A@xxxxxxxxxxxxxxxx
Hi Joe,
I'm facing the same problem than Ralph (double hop). I have done the 2
first checks you wrote however I don't know how to verify if browser is
using
Kerberos authentication. Could you please give me some advice?
Thank you very much for your kind reply
Could you please copy your reply to the following address:
johann.granados@xxxxxxxxxxxxxxx
--
Johann Granados
MVP Compact Framework
Costa Rica, Central America
"Joe Kaplan (MVP - ADSI)" wrote:
Unfortunately, implementing Kerberos delegatio can be a little tricky
and
it
isn't easy to explain it simply such that you'll definitely get
everything
working the way you need to.
The first question is whether your AD is 2003 native mode and whether
your
web server is 2003. If both are true, then you have a few additional
options to consider (protocol transition and constrained delegation).
If
not, then you must use traditional Kerberos delegation.
The basic steps always are:
- Set proper SPNs on the account running the web server process
- Enable the web server process account for delegation
- Ensure browser is authenticating against IIS using Kerberos
(warning:
SharePoint pre-SP2 actually disables this feature in the metabase; you
must
change it back!). This step is necessary unless you can use protocol
transition
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
--
"ralph_jj22022" <u24448@uwe> wrote in message
news:63b6e900a8653@xxxxxx
HI Gurus,
I am trying to build a web part in asp.net 1.1 using VS.Net 2003. I
am
using
this web part on a sharepoint server hosted on a remote server. I am
trying
to loginto a sql server 2000 machine , again on a third machine. The
issue
I
am facing is that of "Double hop". I ahve gone through the MSDN
articles
and
some articles on web butcouldn't understand much. Can anybody
explain
to
me
in simple novice terms how to solve this double hop issue an connect
to
the
sql server from a remote web part.
Happy coding,
Ralph
.
- References:
- Re: Double hop
- From: Johann Granados
- Re: Double hop
- From: Joe Kaplan
- Re: Double hop
- From: Johann Granados
- Re: Double hop
- Prev by Date: Re: deploy authentication 'forms'
- Next by Date: Re: Why is this method requesting these permissions?
- Previous by thread: Re: Double hop
- Next by thread: sql Connection
- Index(es):
Relevant Pages
|
