Serena Single Sign-On does Negotiate/NTLM (Windows Authentication)

over 6 years ago

Many administrators would utilize Serena Single Sign-On with all of its security features if it would log their users on to SBM using the Windows Credentials of the user logged on to the workstation.  As of SBM 10.1.2.x, Serena SSO now does "Windows Single Sign-On".

To setup Single Sign-On and Windows Authentication, setup the authentication tab of the SBM Configurator as follows.  Validate user credentials against Windows domain, and user sessions are managed by Windows Authentication (SSO).  SBM uses both NTLM and Negotiate.


After applying Configurator, your IIS Settings on the WorkCenter and TMTrack virtual directory/applications will be updated to use Anonymous.  Under the authentication icon, Anonymous will be selected and Windows Authentication will no longer be selected.  Users will now access the IIS server under the Anonymous user account and/or the application pool identity. 

SBM SSO will take the user credentials from the browser request and authenticate the user with the Windows server / domain.  The user, of course, must exist in SBM where the loginId in SBM matches the Windows SAM account name.

SBM C API programs, however, will not authenticate with Windows password.  Instead, the C API uses the internal SBM password.  The SBM Webservice API does use the Windows password.

Full setup details are located in the SBM Installation Guide. 


Comment List
  • Thank you David - I'm not as expert with the domain's setup so I've asked some of the other folks on our team to weigh in. Heading out of the office for a planned vacation but I look forward to catching up on this idea when I return. -Jeff
  • Hi Jeff, Does "Users have FIRST_LAST accounts on both domains" mean that they have a username (of the form firstname_lastname) on both domains? If so, there is the low tech approach of having the user maintain the same password on both domains. With the same username / password, pass through authentication will be used which will emulated having the domain trusts. I nicer way to get the single sign-on may be to use ADFS. Each domain would have its own ADFS server where the workstation domain is your user domain and the server domain is the resource domain. Next, in IIS you would add the ADFS agent and protect the /IDP/ URI. This setup should give you SSO. Upon successful login via ADFS, a remote-user header is added to the packet header that SBM reads and accepts as valid login. See Serena KB S138650. I have set this up in Windows Server 2008 R2, but Windows 2012 seems to have changed the location of the IIS ADFS agent, so I am not sure if it will be a valid setup going forward. -David
  • Hi David - is there any way to configure SSO to work against a different domain than the one to which the server is joined? Our scenario is: SBM is running on "servers-domain" User workstations are on "desktops-domain" There is no trust between the two. Users have FIRST_LAST accounts on both domains, and within SBM. I know that using LDAP authentication, it is possible to point at any directory server to authenticate usernames/passwords. However this does not give the benefit of automatic sign-on, it still requires users to enter their credentials. Is there anything similar that SSO provides, where a server in "servers-domain" could authenticate requests coming from clients in "desktops-domain"? Thank you! -Jeff
Related Discussions