Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

AD User Credential Prompts in SD 7.5 SP1?

Created: 12 Nov 2013 | 42 comments
Lark's picture

I have two completely separate environments upgraded to ServiceDesk 7.5 SP1 and I've been noticing a couple of user experience things for user accounts synced from AD:

  1. When first clicking on tasks the authentication (username/password) form is sometimes visible for 3-4 seconds and then it passes through to the next form.  This did happen in prior versions at times but seems to linger a little longer in SP1.
  2. Users logging in from computers not on the same domain as the ServiceDesk server get prompted for credentials on triggering workflows if they use the login format [domain]\[username] to access the Process Manager.  If they use their e-mail address this does not occur.

In both cases this is intermittent otherwise I would have logged a case with support.

I thought I'd mention it in case anyone else is seeing the same sort of thing?

Operating Systems:

Comments 42 CommentsJump to latest comment

mariomendez83's picture

Hi

I have the same situation, but for me that is a issue

I have two new customers where I installed SD 7.5 SP1 and this authentication form appears only first time.

If the final user set the user name and password, the next time don't appear.

It's a little annoying

someone know how remove this issue?

jpellet2's picture

I am seeing the same thing. Often I can log in to ProcessManager and then when I open a form I get prompted to log in again but usually that will be the last time. It won't ask again for other forms or subforms. Its odd but I haven't had time to chase down where the authntication is being dropped/lost.

Lark's picture

I have not solved this or had a chance to dig deeper. In one case we waited about 15 seconds on the authentication page at the start of the advanced incident management form and it did then pass through credentials. This does not always happen. Sometimes we have to enter credentials.

Something has definitely changed in SP1 as MP1 did not exhibit this behaviour on the same server running the same form.

Justin Dybedahl's picture

What browser are you using?  I have yet to upgrade to SP1, but while testing MP1, I noticed some issues with the login.aspx file while using Chrome/Firefox.   I noticed that either of those two browsers it would take longer to do the passthrough authentication.   My memory is foggy but I do know that they changed the login.aspx code in MP1 and they may have done it with SP1 again.   While it's unsupported, you may want to take a look at this file as I know there is some code that makes the page wait for 15 seconds if the authentication process times out.  If you'd like, I can send you the modified login.aspx I have been using with MP1.   Just PM me.

smassie's picture

I am sitting in a customer do an implementation and this is happening here.

It's not browser related and does not seem to be AD User related either

AD users can access the portal but when they go to submit an Incident are asked to authenticate - whether they are end users or full admins in SD

Interestingly when I'm logged in as the internal Admin I can do all the usual submissions (change problem, incident) - but when I go to try to request change from the actions menu while in the process view page for an incident it asks me to authenticate...

Lark's picture

I still have no solution sorry.  This is occuring in Internet Explorer 8, 9 ,10 & 11 with compatibility mode.  The SD server is listed as a trusted site.  I have seen this on multiple installs.

TGiles's picture

I've seen this behavior occur when the login component inside each feeder form isn't set to store the credentials. This ability has 3 options: Don't Store, Store, or User Select. If the Don't Store option is used the pass thru authentication seems to have issues. 

Hope that helps.

Lark's picture

I just checked the Advanced Incident form and this is set to Store.  It seems to happen with every form that uses that login component.  

I'm generally just seeing far more auth prompts than I would expect - even when logged onto the SD server with an AD account that is a member of the Administrators group in SD.

smassie's picture

I have tested this further - and it would seem that if a user logs in at one of these authentication pages comes up any subsequent calls are passed through even if the server is rebooted - i.e. the store works, but doesn't seem to take the credentials from the logged in user when it should.Hope that makes sense?

smassie's picture

These forms seem to use the authenticate session component - and I am wondering if these components will read and use the current user details as per the AD authenitcation, so these authentications don't come up when the user is a valid SD user as per their current AD login?

smassie's picture

Ah looking at the online help for this component it says

If an active Process Manager session exists the component will always try to use this session first. This is the name of the cookie that Process Manager stores and generally should not be changed. In order to read the Process Manager cookie the MachineKey should be the same for both Process Manager and your Workflow project.
 

I am guessing it should use the current login if logged into process manager and am wondering if the fact this is not happening is due to an issue with encryption algorithms used or something along those lines?

Lark's picture

I have had some more information that may only be relevant to ServiceDesk 7.5 SP1.

If you access the Process Manager with anything other than the name of the servicedesk setup that you entered during installation you will likely see more authentication prompts.  So if during setup you entered myservicedesk.mydomain.local then you should always access through http:\\myservicedesk.mydomain.local\processmanager.  Using a shortened name or alias may cause more prompts to appear.

smassie's picture

have checked this and it is the case. if you don't use the myservicedesk.mydomain.local you get these errors. This includes the use of localhost on the sevrer!!! Suggest this is something that needs fixing.

smassie's picture

Correction this is not the solution - even when you put the full server name in it will still regularly prompt for login when accessing pages that use the authenticate session component . Looks like a bug?

Lark's picture

Another possibility is one that I'm still experimenting with.  If you use an SQL account as the db runtime access account during SD install then the installation is different to if you used an AD account.  For example, the IIS app pools and the workflow service run as local system.

Lark's picture

To correct what I just said, the Symantec Workflow Server service still runs as local system even with an AD account specified as the SQL runtime account.  The problem with this is that the service then attempts to use the machine account to access network resources.

The ProcessManagerPool and the ServiceDeskPool identities are different depending on whether you use an SQL or AD account as the SQL runtime access.

With an AD account the app pool identity is that same account.

With an SQL account the app pool identity is the stardard "ApplicationPoolIdentity"

mariomendez83's picture

somebody tested this??

To correct what I just said, the Symantec Workflow Server service still runs as local system even with an AD account specified as the SQL runtime account. The problem with this is that the service then attempts to use the machine account to access network resources.

The ProcessManagerPool and the ServiceDeskPool identities are different depending on whether you use an SQL or AD account as the SQL runtime access.

With an AD account the app pool identity is that same account.

With an SQL account the app pool identity is the stardard "ApplicationPoolIdentity"

this is Lark's great idea but I can't try it.

Lark's picture

Since swapping to an AD account AND making sure I use the server name I entered during setup I'm pretty sure I've seen less authentication prompts.  We still see them occasionally - especially when accessing SD from a machine that is not on the same domain.

jpellet2's picture

We use an AD account to run the system throughout (ServiceDesk, SQL, etc) and always use the FQDN and still see a few login prompts. These mostly occur the first time a subwindow is opened after logging in to the portal using an AD login (prompted by the browser) rather than use the email/password option on the login page. 

Lark's picture

If you wait (as much as 15 seconds) does it pass through eventually?  Thats what I often see in slower environments.

jpellet2's picture

It does not. No matter how long we sit at the window, it never passes through.

Justin Dybedahl's picture

I stood up a new ServiceDesk 7.5 SP1 instance for my development server about a month ago and recently found out that I had this issue.  While I'm not saying this is the solution, I'm just posting the random things that I tried and found that it worked in my case.  I didn't have the Symantec Workflow Service running as the app credentials account so I switched it.   That didn't seem to help.  When I first setup the server, I had issues with the default admin account and I worked with tech support on it.  We changed the admin@symantec.com account's password a bunch of times and I couldn't remember if we swapped it in the Local Machine Editor server properties so I re-entered the password and restarted the services (iisreset as well).  That seemed to have fixed my issue.

Justin Dybedahl's picture

Forget what I said above.  It appears that I'm only having this issue with Chrome and Firefox and not IE.  Within Chrome/Firefox pass-through works just fine on the main logon page but does not on the any of the forms/ticket actions.   According to tech support the logon process was changed in 7.5 SP1 to be cookie based and you must use the server name that is listed on the Integrated Authentication URL setting in Local Machine Editor.  Also, it would be good to verify the domain field of the cookie is the same thing.  You can view this in Chrome by pressing F12 and going to the cookies section.

I also received some information from support detailing the logon process in general.  Supposedly when you logon using your email address, it uses a process manager session that has all of your information.  When you use your NT ID (domain\username) or the AD pass-through authentication method (which are one in the same as the pass-through method uses the NT ID), it has to perform a AD lookup for your information with everything you do in the portal.

I've verified that I only have issues if I use my NT ID or if I let the pass-through process complete.   If I logon with my email address, everything works, regardless of browser.  Why this is only an issue in Chrome/Firefox and why IE works fine regardless of logon method, I have no idea.

Can anyone else confirm this?

Lark's picture

IE seems to mostly work but I do still see authentication prompts when I don't believe I should.  I'm still trying to figure out why but it does seem time-out or cache related - everything seems ok with a recently restarted SD server but eventually they start creeping in again.

I have had the same information passed to me about AD IDs ([domain]\[samid]) vs e-mail address.  Performance of the console IS better when using an email address.  I guess thats due to less AD lookups its doing.  Why wouldn't the developers do the same process manager caching for AD IDs?  Almost everyone has AD and pass through authentication to SD makes a significant difference to the user experience.

Justin Dybedahl's picture

According to support they have found a bug with pass-through authentication.   It should hopefully be available in the next few weeks.  No idea if this will fix our issue but it will be available at the link below.

http://www.symantec.com/business/support/index?page=content&id=TECH212326

TGiles's picture

Actually this issue is with Workflow, not ServiceDesk. The knowledge base article listed above is specifically for ServiceDesk 7.5 SP1 point fixes only. Once the fix is made available a different knowledge base article will be used.

Lark's picture

TGiles are you allowed to elaborate on the bug?  Given the experiences described in this thread is it likely this fix will help any of them?

TGiles's picture

The bug was written to address the issue discussed in this thread.

Lark's picture

Awesome - I'm really looking forward to seeing it - thanks.  These authentication prompts are very un-popular with testers.

mariomendez83's picture

my friends,

finally I downgrade to SD 7.5 MP1

In my case, was very easy because my customer did not have information.

I'll test in my enviroment test and post it the result.

Dan B's picture

We have been asked to start piloting this but our production Helpdesk do not want to even try using ServiceDesk while the authentications prompts are so prolific.  Can anyone advise if we are close to a solution being released?

eladio's picture

Hello,

If i make an iisreset my portal will be slow at authentication at first time, at second time it will be more fast now im close not to see the authentication form.

I have correct in Task tray tool, the name of the server like the url that i type to open the portal.

Before i have http://localhost/ProcessManager/WindowsAuthentication.aspx

I change localhost to the name of server,verify if you have select "do not process timeout and escalations" , restart server extensions and iisreset after the second login it will be more fast.

See attachment the image.

I dont know if will resolve your problem... mine is better.

machine settings.jpg
TGiles's picture

Unless the workflow server is a client facing server on a load balanced environment you never want to check 'Do not process timeouts and escalations'. By doing this you are preventing workflow from processing any of the timeout periods defined in any of the workflow projects on your server.

eladio's picture

TGiles,

Thanks for your answer but by default that configuration is enable, so if i just have i one server i wil take it out.

TGiles's picture

By default this option should always be unchecked. However duing an upgrade of Workflow this option gets set from time to time. It's always a good idea to check this setting after you've upgraded Workflow to make sure the installer didn't leave it enabled.

Justin Dybedahl's picture

Any update on the release of this fix?

HarrisT's picture

Hi everyone,

If you're using IE, and logging in with the same URL as the URLs below, AD authentication to forms should work.
When logging into the portal, if AD authentication works correctly, but does not work when accessing forms, confirm the following configurations are correct:

There are 3 places where you need to confirm all URLs match (http://<SN/FQDN>) NO PORT NUMBERS!

1.       LocalMachineInfo Editor (Start -> All Programs -> Symantec -> Workflow Designer -> Tools -> LocalMachineInfo Editor)
Scroll down and confirm the Integrated Authentication URL matches the other two locations. There should be no :80 (port number) in the URL.

2.       Properties.config (%\Program Files\Symantec\Workflow\WorkflowDeploy\Release\<Project_Name>\Properties.config)
Open Properties.config in Notepad, and search for <PropertyName>BaseURLToProject</PropertyName>, Just under BaseURLToProject there will be a URL value. Ensure the http://<ServerName>/ portion of the URL matches what is in the other two locations.
If you have ${DeploymentRootURL} listed in Properties.config, ensure the (local) server contained in LocalMachineInfo Editor has the correct URL.
Note: This needs to be confirmed in all projects that are having problems with pass-through authentication.

3.       Master Settings (Login to the portal. Admin -> Portal -> Master Settings)
Minimize the Account Management section that is open by default, and expand the Notifications section. Confirm the Base URL To Process Manager value matches what is the other two locations.

I hope this helps!

Lark's picture

Thanks for this HarrisT.  

I just checked one of my environments where I'm seeing authentication prompts.  It had the load balanced url or ${DeploymentRootURL} everywhere I looked.

Can you confirm if these settings are appropriate for a load balanced environment?

One of my environments also has a back-end server that is not part of the load balanced pool.  Would the settings be appropriate for this?

Justin Dybedahl's picture

Just so others know, I was given the updated workflow version by Symantec tech support and it fixed my issue.   You'll have to ask them for it.   It's version 7.5.3001.41.

toomas's picture

A little clarification about the specific rollup Justin mentions - This does fix an issue with pass-through authentication on these login pages not working with Firefox and Chrome. Previously, although pass-through authentication worked on the main login page it not always worked on these project login pages with browsers other than IE.

There is still another problem related to these login pages appearing in 7.5 SP1 that we are still looking into (with a high priority). There is very likely going to be another fix (in a newer rollup) to better take care of this issue.

toomas's picture

Thanks guys, this thread along with several support cases helped us get to the bottom of these issues. I will try to do a little wrapping up.

We have created a KB article about the configuration needed for the passthrough authentication in ServiceDesk 7.5 SP1 and have mentioned the known issues there as well. Some of the contents you can see a few posts up in this thread but a KB article is a more official and more easily findable way of stating this.

HOWTO98406 - How to configure and/or troubleshoot Passthrough Authentication in ServiceDesk 7.5 SP1

 will simply copy-paste the short decriptions for the issues that are fixed in the Rollup from that article:

  • With ProcessManager Login component not being able to passthrough login in Chrome and Firefox. Note that this issue does not apply to portal login page, only login pages in projects based on ProcessManager Login component.
  • With how authentication cookies were being created and stored. This issue is evident where portal login with email address allows access to all forms (for example, Service Catalog items or Process Actions) without prompt or delay but using passthrough or domain\user format for logging in has a login prompt or delay opening forms.

For the fixes, you will need rollup version 7.5.3001.43 or newer. In an earlier rollup version that was mentioned above, only the first issue was fixed but not the second one. The same version is required for the current batch of pointfixes in TECH212326.

Another annoyance got fixed along with these bigger issues - the 'undefined' popup that appeared on portal login page with Chrome and Firefox while passthrough authentication was doing its thing.