Kerberos

I have implemented Single Sign On (SSO) between windows and SAP Enterprise
Portal (EP) - so if a user is logged into windows, they can go to our EP
site, and EP knows who they are, and applies permissions appropriately.

I have pretty much got this working, however I have run into a couple of
things which I can't really explain, and would be interested in hearing why
it might be occurring:

1. If you open a browser, and then type in the address of the portal, the
single sign on works fine
2. If you have a browser window open (on any page) and then click a link (eg
in an email) that takes you to the portal, the SSO works fine
3. If you close all of your browser windows, and then click a link (eg in an
email) that takes you to the portal, then the user is prompted to enter their
username and password (this is a windows style login box). After they have
entered their username and password, they are taken straight into the portal
(ie no portal login box)
4. If you add the portal site address to either "trusted sites" or "local
intranet" (in IE, this is in Tools->Internet Options->, then do point 3
above, you are not prompted to login. (if you go to the portal address, it
comes up as being in the local intranet anyway, so am not sure what this
actually achieves)

Point 3 is the issue that I don't understand - why are you prompted to
login? And what is the difference if you have a browser open or add the site
to "local intranet"?

If anyone could help me out on this it would be greatly appreciated!

Re: Kerberos

I think this KB article will answer your question:
http://support.microsoft.com/?id=258063

Basically, IE uses those security zones to work out whether to send
credentials to a server without prompting the user. Additionally, sites that
are netbios style names (i.e. http://servername) are by default, in the
Intranet zone. Check the KB article for more details.

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"arduk" wrote in message
news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
>I have implemented Single Sign On (SSO) between windows and SAP Enterprise
> Portal (EP) - so if a user is logged into windows, they can go to our EP
> site, and EP knows who they are, and applies permissions appropriately.
>
> I have pretty much got this working, however I have run into a couple of
> things which I can't really explain, and would be interested in hearing
> why
> it might be occurring:
>
> 1. If you open a browser, and then type in the address of the portal, the
> single sign on works fine
> 2. If you have a browser window open (on any page) and then click a link
> (eg
> in an email) that takes you to the portal, the SSO works fine
> 3. If you close all of your browser windows, and then click a link (eg in
> an
> email) that takes you to the portal, then the user is prompted to enter
> their
> username and password (this is a windows style login box). After they have
> entered their username and password, they are taken straight into the
> portal
> (ie no portal login box)
> 4. If you add the portal site address to either "trusted sites" or "local
> intranet" (in IE, this is in Tools->Internet Options->, then do point 3
> above, you are not prompted to login. (if you go to the portal address, it
> comes up as being in the local intranet anyway, so am not sure what this
> actually achieves)
>
> Point 3 is the issue that I don't understand - why are you prompted to
> login? And what is the difference if you have a browser open or add the
> site
> to "local intranet"?
>
> If anyone could help me out on this it would be greatly appreciated!
>

Re: Kerberos

Hi Ken, thanks very much for your response!

That sounds like it explains the problem, the only question that is left
unanwered is why you are not prompted if you already have a browser open
(point 2 in my original post). If you have any ideas on that, I would love to
hear them.

Thanks again for your prompt and helpful reply!



"Ken Schaefer" wrote:

> I think this KB article will answer your question:
> http://support.microsoft.com/?id=258063
>
> Basically, IE uses those security zones to work out whether to send
> credentials to a server without prompting the user. Additionally, sites that
> are netbios style names (i.e. http://servername) are by default, in the
> Intranet zone. Check the KB article for more details.
>
> Cheers
> Ken
>
> --
> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>
> "arduk" wrote in message
> news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
> >I have implemented Single Sign On (SSO) between windows and SAP Enterprise
> > Portal (EP) - so if a user is logged into windows, they can go to our EP
> > site, and EP knows who they are, and applies permissions appropriately.
> >
> > I have pretty much got this working, however I have run into a couple of
> > things which I can't really explain, and would be interested in hearing
> > why
> > it might be occurring:
> >
> > 1. If you open a browser, and then type in the address of the portal, the
> > single sign on works fine
> > 2. If you have a browser window open (on any page) and then click a link
> > (eg
> > in an email) that takes you to the portal, the SSO works fine
> > 3. If you close all of your browser windows, and then click a link (eg in
> > an
> > email) that takes you to the portal, then the user is prompted to enter
> > their
> > username and password (this is a windows style login box). After they have
> > entered their username and password, they are taken straight into the
> > portal
> > (ie no portal login box)
> > 4. If you add the portal site address to either "trusted sites" or "local
> > intranet" (in IE, this is in Tools->Internet Options->, then do point 3
> > above, you are not prompted to login. (if you go to the portal address, it
> > comes up as being in the local intranet anyway, so am not sure what this
> > actually achieves)
> >
> > Point 3 is the issue that I don't understand - why are you prompted to
> > login? And what is the difference if you have a browser open or add the
> > site
> > to "local intranet"?
> >
> > If anyone could help me out on this it would be greatly appreciated!
> >
>
>

Re: Kerberos

Has the user ever visited the SSO page or portal prior to clicking the link
etc? IE will continue sending the user's credentials until either:
a) the browser window is closed
or
b) the server sends back 401 (Not Authorized)

So, if the user has ever authenticated to this resource earlier in the
session, they would not nee to authenticate again if re-using the same IE
process (iexplore.exe)

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"arduk" wrote in message
news:63DCB301-6415-4A6A-8858-9077EDB7688F@microsoft.com...
> Hi Ken, thanks very much for your response!
>
> That sounds like it explains the problem, the only question that is left
> unanwered is why you are not prompted if you already have a browser open
> (point 2 in my original post). If you have any ideas on that, I would love
> to
> hear them.
>
> Thanks again for your prompt and helpful reply!
>
>
>
> "Ken Schaefer" wrote:
>
>> I think this KB article will answer your question:
>> http://support.microsoft.com/?id=258063
>>
>> Basically, IE uses those security zones to work out whether to send
>> credentials to a server without prompting the user. Additionally, sites
>> that
>> are netbios style names (i.e. http://servername) are by default, in the
>> Intranet zone. Check the KB article for more details.
>>
>> Cheers
>> Ken
>>
>> --
>> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>>
>> "arduk" wrote in message
>> news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
>> >I have implemented Single Sign On (SSO) between windows and SAP
>> >Enterprise
>> > Portal (EP) - so if a user is logged into windows, they can go to our
>> > EP
>> > site, and EP knows who they are, and applies permissions appropriately.
>> >
>> > I have pretty much got this working, however I have run into a couple
>> > of
>> > things which I can't really explain, and would be interested in hearing
>> > why
>> > it might be occurring:
>> >
>> > 1. If you open a browser, and then type in the address of the portal,
>> > the
>> > single sign on works fine
>> > 2. If you have a browser window open (on any page) and then click a
>> > link
>> > (eg
>> > in an email) that takes you to the portal, the SSO works fine
>> > 3. If you close all of your browser windows, and then click a link (eg
>> > in
>> > an
>> > email) that takes you to the portal, then the user is prompted to enter
>> > their
>> > username and password (this is a windows style login box). After they
>> > have
>> > entered their username and password, they are taken straight into the
>> > portal
>> > (ie no portal login box)
>> > 4. If you add the portal site address to either "trusted sites" or
>> > "local
>> > intranet" (in IE, this is in Tools->Internet Options->, then do point 3
>> > above, you are not prompted to login. (if you go to the portal address,
>> > it
>> > comes up as being in the local intranet anyway, so am not sure what
>> > this
>> > actually achieves)
>> >
>> > Point 3 is the issue that I don't understand - why are you prompted to
>> > login? And what is the difference if you have a browser open or add the
>> > site
>> > to "local intranet"?
>> >
>> > If anyone could help me out on this it would be greatly appreciated!
>> >
>>
>>

Re: Kerberos

Sadly it isn't that simple - the user hasn't visited the site - they could
open up a browser straight to google, and then if they click a link in an
email that takes them to the portal, they will not be challenged.


"Ken Schaefer" wrote:

> Has the user ever visited the SSO page or portal prior to clicking the link
> etc? IE will continue sending the user's credentials until either:
> a) the browser window is closed
> or
> b) the server sends back 401 (Not Authorized)
>
> So, if the user has ever authenticated to this resource earlier in the
> session, they would not nee to authenticate again if re-using the same IE
> process (iexplore.exe)
>
> Cheers
> Ken
>
> --
> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>
> "arduk" wrote in message
> news:63DCB301-6415-4A6A-8858-9077EDB7688F@microsoft.com...
> > Hi Ken, thanks very much for your response!
> >
> > That sounds like it explains the problem, the only question that is left
> > unanwered is why you are not prompted if you already have a browser open
> > (point 2 in my original post). If you have any ideas on that, I would love
> > to
> > hear them.
> >
> > Thanks again for your prompt and helpful reply!
> >
> >
> >
> > "Ken Schaefer" wrote:
> >
> >> I think this KB article will answer your question:
> >> http://support.microsoft.com/?id=258063
> >>
> >> Basically, IE uses those security zones to work out whether to send
> >> credentials to a server without prompting the user. Additionally, sites
> >> that
> >> are netbios style names (i.e. http://servername) are by default, in the
> >> Intranet zone. Check the KB article for more details.
> >>
> >> Cheers
> >> Ken
> >>
> >> --
> >> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
> >>
> >> "arduk" wrote in message
> >> news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
> >> >I have implemented Single Sign On (SSO) between windows and SAP
> >> >Enterprise
> >> > Portal (EP) - so if a user is logged into windows, they can go to our
> >> > EP
> >> > site, and EP knows who they are, and applies permissions appropriately.
> >> >
> >> > I have pretty much got this working, however I have run into a couple
> >> > of
> >> > things which I can't really explain, and would be interested in hearing
> >> > why
> >> > it might be occurring:
> >> >
> >> > 1. If you open a browser, and then type in the address of the portal,
> >> > the
> >> > single sign on works fine
> >> > 2. If you have a browser window open (on any page) and then click a
> >> > link
> >> > (eg
> >> > in an email) that takes you to the portal, the SSO works fine
> >> > 3. If you close all of your browser windows, and then click a link (eg
> >> > in
> >> > an
> >> > email) that takes you to the portal, then the user is prompted to enter
> >> > their
> >> > username and password (this is a windows style login box). After they
> >> > have
> >> > entered their username and password, they are taken straight into the
> >> > portal
> >> > (ie no portal login box)
> >> > 4. If you add the portal site address to either "trusted sites" or
> >> > "local
> >> > intranet" (in IE, this is in Tools->Internet Options->, then do point 3
> >> > above, you are not prompted to login. (if you go to the portal address,
> >> > it
> >> > comes up as being in the local intranet anyway, so am not sure what
> >> > this
> >> > actually achieves)
> >> >
> >> > Point 3 is the issue that I don't understand - why are you prompted to
> >> > login? And what is the difference if you have a browser open or add the
> >> > site
> >> > to "local intranet"?
> >> >
> >> > If anyone could help me out on this it would be greatly appreciated!
> >> >
> >>
> >>
>
>

Re: Kerberos

You will need to get a packet capture or similar to be 100% sure of what is
happening here. At the same time, verify what security zone IE thinks it is
in.

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

"arduk" wrote in message
news:845D76FC-FB7C-471E-BBBE-AB9D8B6CCBB2@microsoft.com...
> Sadly it isn't that simple - the user hasn't visited the site - they could
> open up a browser straight to google, and then if they click a link in an
> email that takes them to the portal, they will not be challenged.
>
>
> "Ken Schaefer" wrote:
>
>> Has the user ever visited the SSO page or portal prior to clicking the
>> link
>> etc? IE will continue sending the user's credentials until either:
>> a) the browser window is closed
>> or
>> b) the server sends back 401 (Not Authorized)
>>
>> So, if the user has ever authenticated to this resource earlier in the
>> session, they would not nee to authenticate again if re-using the same IE
>> process (iexplore.exe)
>>
>> Cheers
>> Ken
>>
>> --
>> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>>
>> "arduk" wrote in message
>> news:63DCB301-6415-4A6A-8858-9077EDB7688F@microsoft.com...
>> > Hi Ken, thanks very much for your response!
>> >
>> > That sounds like it explains the problem, the only question that is
>> > left
>> > unanwered is why you are not prompted if you already have a browser
>> > open
>> > (point 2 in my original post). If you have any ideas on that, I would
>> > love
>> > to
>> > hear them.
>> >
>> > Thanks again for your prompt and helpful reply!
>> >
>> >
>> >
>> > "Ken Schaefer" wrote:
>> >
>> >> I think this KB article will answer your question:
>> >> http://support.microsoft.com/?id=258063
>> >>
>> >> Basically, IE uses those security zones to work out whether to send
>> >> credentials to a server without prompting the user. Additionally,
>> >> sites
>> >> that
>> >> are netbios style names (i.e. http://servername) are by default, in
>> >> the
>> >> Intranet zone. Check the KB article for more details.
>> >>
>> >> Cheers
>> >> Ken
>> >>
>> >> --
>> >> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>> >>
>> >> "arduk" wrote in message
>> >> news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
>> >> >I have implemented Single Sign On (SSO) between windows and SAP
>> >> >Enterprise
>> >> > Portal (EP) - so if a user is logged into windows, they can go to
>> >> > our
>> >> > EP
>> >> > site, and EP knows who they are, and applies permissions
>> >> > appropriately.
>> >> >
>> >> > I have pretty much got this working, however I have run into a
>> >> > couple
>> >> > of
>> >> > things which I can't really explain, and would be interested in
>> >> > hearing
>> >> > why
>> >> > it might be occurring:
>> >> >
>> >> > 1. If you open a browser, and then type in the address of the
>> >> > portal,
>> >> > the
>> >> > single sign on works fine
>> >> > 2. If you have a browser window open (on any page) and then click a
>> >> > link
>> >> > (eg
>> >> > in an email) that takes you to the portal, the SSO works fine
>> >> > 3. If you close all of your browser windows, and then click a link
>> >> > (eg
>> >> > in
>> >> > an
>> >> > email) that takes you to the portal, then the user is prompted to
>> >> > enter
>> >> > their
>> >> > username and password (this is a windows style login box). After
>> >> > they
>> >> > have
>> >> > entered their username and password, they are taken straight into
>> >> > the
>> >> > portal
>> >> > (ie no portal login box)
>> >> > 4. If you add the portal site address to either "trusted sites" or
>> >> > "local
>> >> > intranet" (in IE, this is in Tools->Internet Options->, then do
>> >> > point 3
>> >> > above, you are not prompted to login. (if you go to the portal
>> >> > address,
>> >> > it
>> >> > comes up as being in the local intranet anyway, so am not sure what
>> >> > this
>> >> > actually achieves)
>> >> >
>> >> > Point 3 is the issue that I don't understand - why are you prompted
>> >> > to
>> >> > login? And what is the difference if you have a browser open or add
>> >> > the
>> >> > site
>> >> > to "local intranet"?
>> >> >
>> >> > If anyone could help me out on this it would be greatly appreciated!
>> >> >
>> >>
>> >>
>>
>>

Re: Kerberos

Hi Ken - thanks for your reply.

IE thinks that the site is in the Local Intranet zone.

I have done a packet capture, but really wasn't able to glean any
information from it (I confess I don't have many skills/experience in
actually interpreting the packets captured, so I have probably missed
something - I will go over it again)

Thanks again for the suggestions!

"Ken Schaefer" wrote:

> You will need to get a packet capture or similar to be 100% sure of what is
> happening here. At the same time, verify what security zone IE thinks it is
> in.
>
> Cheers
> Ken
>
> --
> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
>
> "arduk" wrote in message
> news:845D76FC-FB7C-471E-BBBE-AB9D8B6CCBB2@microsoft.com...
> > Sadly it isn't that simple - the user hasn't visited the site - they could
> > open up a browser straight to google, and then if they click a link in an
> > email that takes them to the portal, they will not be challenged.
> >
> >
> > "Ken Schaefer" wrote:
> >
> >> Has the user ever visited the SSO page or portal prior to clicking the
> >> link
> >> etc? IE will continue sending the user's credentials until either:
> >> a) the browser window is closed
> >> or
> >> b) the server sends back 401 (Not Authorized)
> >>
> >> So, if the user has ever authenticated to this resource earlier in the
> >> session, they would not nee to authenticate again if re-using the same IE
> >> process (iexplore.exe)
> >>
> >> Cheers
> >> Ken
> >>
> >> --
> >> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
> >>
> >> "arduk" wrote in message
> >> news:63DCB301-6415-4A6A-8858-9077EDB7688F@microsoft.com...
> >> > Hi Ken, thanks very much for your response!
> >> >
> >> > That sounds like it explains the problem, the only question that is
> >> > left
> >> > unanwered is why you are not prompted if you already have a browser
> >> > open
> >> > (point 2 in my original post). If you have any ideas on that, I would
> >> > love
> >> > to
> >> > hear them.
> >> >
> >> > Thanks again for your prompt and helpful reply!
> >> >
> >> >
> >> >
> >> > "Ken Schaefer" wrote:
> >> >
> >> >> I think this KB article will answer your question:
> >> >> http://support.microsoft.com/?id=258063
> >> >>
> >> >> Basically, IE uses those security zones to work out whether to send
> >> >> credentials to a server without prompting the user. Additionally,
> >> >> sites
> >> >> that
> >> >> are netbios style names (i.e. http://servername) are by default, in
> >> >> the
> >> >> Intranet zone. Check the KB article for more details.
> >> >>
> >> >> Cheers
> >> >> Ken
> >> >>
> >> >> --
> >> >> My IIS Blog: www.adOpenStatic.com/cs/blogs/ken
> >> >>
> >> >> "arduk" wrote in message
> >> >> news:874CD6F9-0684-4464-90B3-D05F04FD8E87@microsoft.com...
> >> >> >I have implemented Single Sign On (SSO) between windows and SAP
> >> >> >Enterprise
> >> >> > Portal (EP) - so if a user is logged into windows, they can go to
> >> >> > our
> >> >> > EP
> >> >> > site, and EP knows who they are, and applies permissions
> >> >> > appropriately.
> >> >> >
> >> >> > I have pretty much got this working, however I have run into a
> >> >> > couple
> >> >> > of
> >> >> > things which I can't really explain, and would be interested in
> >> >> > hearing
> >> >> > why
> >> >> > it might be occurring:
> >> >> >
> >> >> > 1. If you open a browser, and then type in the address of the
> >> >> > portal,
> >> >> > the
> >> >> > single sign on works fine
> >> >> > 2. If you have a browser window open (on any page) and then click a
> >> >> > link
> >> >> > (eg
> >> >> > in an email) that takes you to the portal, the SSO works fine
> >> >> > 3. If you close all of your browser windows, and then click a link
> >> >> > (eg
> >> >> > in
> >> >> > an
> >> >> > email) that takes you to the portal, then the user is prompted to
> >> >> > enter
> >> >> > their
> >> >> > username and password (this is a windows style login box). After
> >> >> > they
> >> >> > have
> >> >> > entered their username and password, they are taken straight into
> >> >> > the
> >> >> > portal
> >> >> > (ie no portal login box)
> >> >> > 4. If you add the portal site address to either "trusted sites" or
> >> >> > "local
> >> >> > intranet" (in IE, this is in Tools->Internet Options->, then do
> >> >> > point 3
> >> >> > above, you are not prompted to login. (if you go to the portal
> >> >> > address,
> >> >> > it
> >> >> > comes up as being in the local intranet anyway, so am not sure what
> >> >> > this
> >> >> > actually achieves)
> >> >> >
> >> >> > Point 3 is the issue that I don't understand - why are you prompted
> >> >> > to
> >> >> > login? And what is the difference if you have a browser open or add
> >> >> > the
> >> >> > site
> >> >> > to "local intranet"?
> >> >> >
> >> >> > If anyone could help me out on this it would be greatly appreciated!
> >> >> >
> >> >>
> >> >>
> >>
> >>
>
>

Re: Kerberos

Hi Arduk,

According to your discussion with Ken, it looks like the issue is regarding
to unexpected behavior of IE authentication. Below are some thoughts of
mine:

1. We can gather and review IIS log to determine if there is some actual
difference when IE prompts for login(without opening a browser window
first) and not(with a window opening). To do this:

1) Reproduce the popup behavior without opening a browser window first.
Then wait for several minutes(to make sure the records are written into the
log file) and collect the lastest log files in \System32\LogFiles\W3SVC[n]\
directory (n here is the Site ID which can be viewed in the right panel by
clicking Web Sites folder in IIS).

2) Gather log again with a IE window opened(no login popup) as the same
steps.

2. To narrow down if the issue is specific to the client machine and IE,
please test with some other machines. If other client doesn't encounter the
bahavior, we can confirm this is not an IIS server-side issue.

I look forward to your update.

Have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Kerberos

Hi WenJun - thanks for your reply.

Firstly, this is not client specific - I have tried this on a number of
client machines, with the same result each time.


The web server that is in use is not IIS (however the theory should be the
same - it is a windows login box that is coming up), as it is an SAP portal
system that I am connecting to. The logs that I can collect from it are shown
below - they appear to be the same both when you are prompted, and when you
aren't.

The logs for the non-prompted login show:

[Nov 22, 2007 8:15:32 AM ] - 10.100.26.37 : GET /irj/portal HTTP/1.1 401 2633
[Nov 22, 2007 8:15:32 AM ] - 10.100.26.37 : GET /irj/portal HTTP/1.1 200
12282
after this the actual content is sent

The logs for the prompted login show:

[Nov 22, 2007 8:12:58 AM ] - 10.100.26.37 : GET /irj/portal HTTP/1.1 401 2634
At this point it is waiting for you to login (windows prompt on screen).
Once you login it then continues below...
[Nov 22, 2007 8:13:35 AM ] - 10.100.26.37 : GET /irj/portal HTTP/1.1 200
12280
after this the actual content is sent

This appears to be correct in my understanding - initially the request is
anonymous and so is unauthorised. After that it should go back and get a
kerberos sso ticket, but if the browser hasn't been opened (or has been
opened to about:blank), it appears to be prompting for login details.

I look forward to any comments you may have.



""WenJun Zhang[msft]"" wrote:

> Hi Arduk,
>
> According to your discussion with Ken, it looks like the issue is regarding
> to unexpected behavior of IE authentication. Below are some thoughts of
> mine:
>
> 1. We can gather and review IIS log to determine if there is some actual
> difference when IE prompts for login(without opening a browser window
> first) and not(with a window opening). To do this:
>
> 1) Reproduce the popup behavior without opening a browser window first.
> Then wait for several minutes(to make sure the records are written into the
> log file) and collect the lastest log files in \System32\LogFiles\W3SVC[n]\
> directory (n here is the Site ID which can be viewed in the right panel by
> clicking Web Sites folder in IIS).
>
> 2) Gather log again with a IE window opened(no login popup) as the same
> steps.
>
> 2. To narrow down if the issue is specific to the client machine and IE,
> please test with some other machines. If other client doesn't encounter the
> bahavior, we can confirm this is not an IIS server-side issue.
>
> I look forward to your update.
>
> Have a nice day.
>
> Sincerely,
>
> WenJun Zhang
>
> Microsoft Online Community Support
>
> ==================================================
>
> Get notification to my posts through email? Please refer to:
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at:
>
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

Re: Kerberos

Hi,

As I know, IIS is the only web server which supports Kerberos auth... To
confirm, you can use WebFetch to capture a trace to confirm.

HOW TO: Use Wfetch.exe to Troubleshoot HTTP Connections
http://support.microsoft.com/default.aspx?scid=kb;en-us;2842 85

To use, please input:

Host: (The site's domainname/hostheader or servername or just IP address)
Port: (The site's port number if it isn't using the default 80)
Path: (The relative path of your page.)
Auth: (Select Kerberos, specify proper user credential)

Press Go! to issue a http request to the server and check what response is
returned. I think the trace should slow us with the details. Please paste
the whole log data here.

I'll wait for your update.

Have a nice weekend.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Kerberos

Hi WenJun,

Below is the output from WFetch.

I have removed ip addresses/internal addresses/port numbers

Hope this helps - I look forward to hearing from you with any ideas


started....WWWConnect::Connect("XXXX.XXXX","XXXX")\nIP =
"IP.IP.IP.IP:XXXX"\nsource port: 64329\r\n
ISC_REQ_MUTUAL_AUTH | ISC_REQ_DELEGATE set\nREQUEST: **************\nGET
/irj/portal HTTP/1.1\r\n
Host: XXXX.XXXX\r\n
Accept: */*\r\n
Connection: Keep-Alive\r\n
Authorization: Kerberos
YFoGCSqGSIb3EgECAgEAbkswSaADAgEFoQMCAQ6iAwMBAKMqYSgwJqADAgEA oQIbAKINMAugAwIBAKEEMAIbAKMMMAqgAwIBAKIDBAEApAwwCqADAgEAogME AQA=\r\n
\r\n
RESPONSE: **************\nHTTP/1.1 200 OK\r\n
Server: SAP J2EE Engine/7.00\r\n
Content-Type: text/html; charset=UTF-8\r\n
Transfer-Encoding: chunked\r\n
Content-Language: en-AU\r\n
expires: 0\r\n
Date: Sun, 25 Nov 2007 21:25:30 GMT\r\n
Set-Cookie: PortalAlias=portal; Path=/\r\n
Set-Cookie: saplb_*=(J2EE17028200)17028250; Version=1; Path=/\r\n
Set-Cookie: JSESSIONID=(J2EE17028200)ID0254879350DB21042558092526389960E nd;
Version=1; Domain=.sanitarium.com.au; Path=/\r\n
\r\n
HREF="/irj/portalapps/com.sap.portal.design.portaldesigndata /themes/portal/sap_tradeshow/glbl/glbl_nn7.css?7.0.11.0.0">\ n REL=stylesheet
HREF="/irj/portalapps/com.sap.portal.design.portaldesigndata /themes/portal/sap_tradeshow/prtl_std/prtl_std_nn7.css?7.0.1 1.0.0">\n\n\n\n\n\n HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> REL=STYLESHEET
HREF="/irj/portalapps/com.sap.portal.design.portaldesigndata /themes/portal/sap_tradeshow/ctrl/ctrl_nn7.css?7.0.11.0.0"
TYPE="text/css" >

Re: Kerberos

Hi,

According to the trace, the Kerberos auth works smoothly. So the
server-side configuration should be fine. The issue looks purely on IE
client side. Could you please check if all the settings are identical on
your IE client per the following doc?

Accessing J2EE Engine with Kerberos Authentication
http://help.sap.com/saphelp_nw04/helpdata/en/43/49a2aefd975f 89e10000000a1553
f6/content.htm

Have a nice week.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Re: Kerberos

Hi WenJun,

thanks for the reply. I have followed the instructions in that link that you
sent me. I guess my real question (as per my original post) is what the
difference is when you add a site to trusted/local intranet sites, or have a
browser open. If the site is not in trusted/local intranet sites, and you
don't have an existing browser open, then you are prompted to login.

Thanks for your assistance on this, but I guess if you don't have any ideas
on what the difference is, then there is no point wasting any more of your
time on this.

thanks again for your help!



""WenJun Zhang[msft]"" wrote:

> Hi,
>
> According to the trace, the Kerberos auth works smoothly. So the
> server-side configuration should be fine. The issue looks purely on IE
> client side. Could you please check if all the settings are identical on
> your IE client per the following doc?
>
> Accessing J2EE Engine with Kerberos Authentication
> http://help.sap.com/saphelp_nw04/helpdata/en/43/49a2aefd975f 89e10000000a1553
> f6/content.htm
>
> Have a nice week.
>
> Sincerely,
>
> WenJun Zhang
>
> Microsoft Online Community Support
>
> ==================================================
>
> Get notification to my posts through email? Please refer to:
> http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
> ications.
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at:
>
> http://msdn.microsoft.com/subscriptions/support/default.aspx .
>
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>

Re: Kerberos

You are welcome. Yes, it's very strange on this IE window open behavior and
I don't have much experience on IE part troubleshooting. You may try post
to the IE newsgroups for some ideas or suggestions though they are not
managed queues in MSDN NG.

If you look for more qualified support on this issue and need to turn up
the root cause, please consider use one of your MSDN Technical Support
Incidents to work with us via telephone based support. This will be the
most effective way to assist you on complicated or project based issue.
Also you won't even need to spend the incident account if the problem is
finally confirmed to be a product issue or can be simply fixed by applying
hotfix. Please refer to the support note below.

About the information of free incident support for MSDN subscribers, please
look at:
http://msdn.microsoft.com/subscriptions/support/default.aspx .

To obtain the phone numbers for Microsoft Customer Service and Support
services technology request, please take a look at the web site listed
below.
http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHON ENUMBERS

Thanks.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.