|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
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! 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 Show quote "arduk" <arduk@nospam.nospam> 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! > 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! Show quote "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" <arduk@nospam.nospam> 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! > > > > 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 Show quote "arduk" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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! >> > >> >> 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. Show quote "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" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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! > >> > > >> > >> > > 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 Show quote "arduk" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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! >> >> > >> >> >> >> >> >> 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! Show quote "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" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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" <arduk@nospam.nospam> 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! > >> >> > > >> >> > >> >> > >> > >> > > 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/default.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. 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: Show quote > 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/default.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. > > 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;284285 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/default.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. 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 YFoGCSqGSIb3EgECAgEAbkswSaADAgEFoQMCAQ6iAwMBAKMqYSgwJqADAgEAoQIbAKINMAugAwIBAKEEMAIbAKMMMAqgAwIBAKIDBAEApAwwCqADAgEAogMEAQA=\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)ID0254879350DB21042558092526389960End; Version=1; Domain=.sanitarium.com.au; Path=/\r\n \r\n <html><head><LINK REL=stylesheet HREF="/irj/portalapps/com.sap.portal.design.portaldesigndata/themes/portal/sap_tradeshow/glbl/glbl_nn7.css?7.0.11.0.0">\n<LINK REL=stylesheet HREF="/irj/portalapps/com.sap.portal.design.portaldesigndata/themes/portal/sap_tradeshow/prtl_std/prtl_std_nn7.css?7.0.11.0.0">\n\n<!-- HTML Business for Java, 645_VAL_REL, 445303, Mon May 07 06:18:30 EST 2007 -->\n<!-- HTMLB: begin VARS -->\n<script language="JavaScript">\nur_system = {doc : window.document , mimepath :"/irj/portalapps/com.sap.portal.design.urdesigndata/themes/portal/sap_tradeshow/common/", "/irj/portalapps/com.sap.portal.design.urdesigndata/themes/portal/sap_tradeshow/ur/", stylepath : emptyhoverurl : "/irj/portalapps/com.sap.portal.htmlb/jslib/emptyhover.html", is508 : false, dateformat : 1, domainrelaxing : "MINIMAL"};\n</script>\n<!-- HTMLB: end VARS -->\n<title >SAP NetWeaver Portal</title><meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"><link 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" ></head><body class="prtlBody urFontBaseFam urScrl"><table border="0" cellspacing="5" cellpadding="0"><tr> <td class="ctrlMsgBarImgError"> </td><td class="ctrlTxtEmph"><SPAN CLASS="ctrlLblReq">iView is not compatible with your browser, operating system or device. Contact your system administrator.</SPAN></td></tr></table></body></html>finished. ""WenJun Zhang[msft]"" wrote: Show quote > 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;284285 > > 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/default.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. > > 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/49a2aefd975f89e10000000a1553 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/default.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. 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: Show quote > 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/49a2aefd975f89e10000000a1553 > 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/default.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. > > > 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;PHONENUMBERS Thanks. Sincerely, WenJun Zhang Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to: http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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.  |
|||||||||||||||||||||||
Other interesting topics