locked
PAS Server asks user for username and password unexpectantly. RRS feed

  • Question

  • Hi,

     

    We have PAS 6.3 installed on it's own 32 bit server.   Users can use this resourse either through a dashboard or the desktop version.   While working with views the PAS server will ask for the windows username and password and then fail.  We have Kerberos implemented but I'm thinking we may have some settings not quite right?   The login can happen just through a user refreshing the page with explorer refresh button?

     

    Any idea's would be greatly appreciated.

     

    Neal Hannath

    Monday, January 14, 2008 8:58 PM

Answers

  • Hi Neal,

     

    In addition to Sean's latest posting; if you believe this to be a Kerberos failure you could try enabling verbose logging and then reviewing the errors being logged.  Here are instructions (and you'll need to reboot after making these changes):

     

    v  On both your web and data server, you should have the following registry path:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters


    You may here have a value called LogLevel. If you do not, add it as a DWORD value, and set it to 1.

    Once you have done this on the web server and on the data server, your event logs will begin to give you detailed information on user activity on those boxes, with relation to Kerberos authentication. On the web server you will look for event log entries that are authenticating users to the PAS virtual directory using Kerberos. Once you've confirmed that this is happening, you will then look for corresponding entries on the data server to see if it is also authenticating using Kerberos.

    Before beginning this testing, it is highly recommend that you clear your event logs, as the entries are many. Also, once you've finished testing, you will want to be sure to clear the registry entry, as this kind of logging will cause performance degradations.

     

    Another option would be to test using Basic authentication only.  If the views always render successfully when using Basic then you can focus your efforts on Kerberos failures.  On the other hand, if the views fail upon using Basic authentication only for the PAS vd then you may find that something else is prohibiting these pages from displaying.

     

    When testing Kerberos I recommend using Integrated authentication only, uncheck Basic for the PAS virtual directory.  Also ensure that all client IE browsers are set to Use Windows Integrated Authentication (in the IE advanced options).  HTH.  If the problem persists and you're running into usability issues (especially for the President of the company) I recommend opening a Support ticket with the ProClarity team or the Windows Platform Team; both groups troubleshoot Kerberos failures.

     

    As with any troubleshooting scenario, try to get as basic as possible to narrow down the cause.  You might eliminate the Dashboard altogether and test only the PAS web pages.  Once PAS is working appropriately, then take a look at the Dashboard.  Fixing PAS could also fix the Dashboard.  I always recommend focusing on PAS first.  More often than not, if PAS works the Dashboard will work as well.

    Tuesday, January 15, 2008 8:43 PM

All replies

  • Hi Neal,

     

    Could you provide some additional information?  Is the problem intermittent, and if so how often does it happen?  When a user gets prompted for credentials when accessing the dashboard views and then the user attempts to connect directly to the PAS website, what happens?  Does the entire website break or does the login appear once and then everything works fine?  Does the problem affect everyone or just certain users, and if the PAS website breaks entirely what steps do you take to fix the issue?

     

    The Kerberos delegation shouldn't affect IIS authentication as you need to get past IIS authentication to the PAS database, retrieve a view, and then Kerberos is used when going out to the cube to retrieve the cube data.  Kerberos delegation also will not prompt for credentials.

     

    Thanks,


    Sean Flanagan

    Tuesday, January 15, 2008 2:34 PM
  • Thanks for the response Sean.   Hopefully I can answer some of the additional questions:-

     

    Yes the problem is intermittent and seems to affect some users more than others.   I'm not sure if it is more affected by the user being on xp / vista.  One of the most affected users is our President who has continual problems with views.

     

    When the login appears (it can be PAS or Dashboards) entering your correct Active Directory account credentials does not work.  We always get an error page after saying that the user hasn't got the priveledges to view the page.  This happened yesterday simply by refreshing the page when viewing a dashboard.   Closing down the browser and reopening it fixed the problem.

     

    Our PAS server and Cube are on different servers and integrated security and basic security and set up in the security tab for the website in IIS.

     

    Let me know if I can answer any more questions to help.

     

    Cheers

     

    neal

     

     

    Tuesday, January 15, 2008 7:33 PM
  • Neal,

     

    From the additional information it sounds like a number of users are affected by this and you're seeing the same issue with both the dashboard and PAS website.  Do you ever have trouble connecting to the dashboard website itself and get a "not authorized to view this page" error?  The dashboard is a little different when configured to integrated windows authentication because the security provider links the dashboard application to a specific domain controller using a domain account/password.  If this link is not at 100% or the specific domain controller the dashboard is connected to is unavailable, overloaded, or offline for a certain amount of time, then users could have intermittent problems connecting to the dashboard.  If the users can connect to the dashboard website but the views within the dashboard are showing the "not authorized" error, then this would not apply and the issue would be with the PAS website and not the dashboard.

     

    If the PAS website itself is having problems, or having the same problem as connecting to the main dashboard website, then the issue may be with IIS on that machine.  Do your users get a long prompt every time they connect to the dashboard or PAS, or only when the authentication is not working?  IIS permissions are the first line of authentication when navigating through the ProClarity security model, and the only stage where you would see "not authorized to view this page".  Kerberos enters the picture only after authenticating to IIS and clicking through the briefing books and attempting to load a view. 

     

    Can you provide some additional information as to how often the issue happens, say for the company President?  Does clearing temp files and cookies on the browser resolve the issue, or only for a limited time?

    Tuesday, January 15, 2008 8:00 PM
  • Hi Neal,

     

    In addition to Sean's latest posting; if you believe this to be a Kerberos failure you could try enabling verbose logging and then reviewing the errors being logged.  Here are instructions (and you'll need to reboot after making these changes):

     

    v  On both your web and data server, you should have the following registry path:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters


    You may here have a value called LogLevel. If you do not, add it as a DWORD value, and set it to 1.

    Once you have done this on the web server and on the data server, your event logs will begin to give you detailed information on user activity on those boxes, with relation to Kerberos authentication. On the web server you will look for event log entries that are authenticating users to the PAS virtual directory using Kerberos. Once you've confirmed that this is happening, you will then look for corresponding entries on the data server to see if it is also authenticating using Kerberos.

    Before beginning this testing, it is highly recommend that you clear your event logs, as the entries are many. Also, once you've finished testing, you will want to be sure to clear the registry entry, as this kind of logging will cause performance degradations.

     

    Another option would be to test using Basic authentication only.  If the views always render successfully when using Basic then you can focus your efforts on Kerberos failures.  On the other hand, if the views fail upon using Basic authentication only for the PAS vd then you may find that something else is prohibiting these pages from displaying.

     

    When testing Kerberos I recommend using Integrated authentication only, uncheck Basic for the PAS virtual directory.  Also ensure that all client IE browsers are set to Use Windows Integrated Authentication (in the IE advanced options).  HTH.  If the problem persists and you're running into usability issues (especially for the President of the company) I recommend opening a Support ticket with the ProClarity team or the Windows Platform Team; both groups troubleshoot Kerberos failures.

     

    As with any troubleshooting scenario, try to get as basic as possible to narrow down the cause.  You might eliminate the Dashboard altogether and test only the PAS web pages.  Once PAS is working appropriately, then take a look at the Dashboard.  Fixing PAS could also fix the Dashboard.  I always recommend focusing on PAS first.  More often than not, if PAS works the Dashboard will work as well.

    Tuesday, January 15, 2008 8:43 PM
  • It is everytime with all users.    A user can close down the application wither this is IE or desktop professional to rectify the problem.  No user account information entered seems to re-validate the user.  We have tried username / password and DOMAIN/user / password.   We have looked at timeouts etc in IIS and changed some to no avail.  It's worth noting that desktop professional fails when trying to access views or publish views to PAS with a message that the user is not logged on.  I can still open and cube and query it.

     

    Let me know if there is any other information that I could provide that would help.

     

     

    Kind Regards. 

     

     

    Neal Hannath

    Friday, May 30, 2008 3:41 PM
  • It certainly seems to be an authentication issue between the client and IIS.  Have you tried any of the troubleshooting steps Amanda suggested in her post?  If so, what were the results?  If not, I would recommend stepping back and trying basic authentication to see if the issue lies only with integrated.  You might also post to a more IIS-centric forum for a general discussion on why the user's session might be going bad.

     

    Wednesday, June 4, 2008 5:24 PM