We recently set up a CommCell in our dev environment and SSO appears to keep failing attempting to sign in to the comcell console. when I try to launch the CommCell. It attempts to SSO then fails and prompts us to enter our password. Entering our passwords is not a long term option as we need to authenticate our accounts using certificates on a smart card(how we rdp to the commserv). We have tested entering a password and it does successfully authenticate to the main domain that we set up in the security section of the CommCell.
We have our main domain with our authenticating groups and the dev domain where our CommCell is joined.
We also have SSO set up identically to our other CommCell’s in our production domains per https://documentation.commvault.com/commvault/v11/article?p=3793.htm .
I also tried validating the user account in the domain settings and it validates successfully without issue, so I am not entirely sure if it is a networking/domain issue. I have also examined the EvMgrs logs and it appears SSO just stops after it tries to validate the admin account? I thought that this was odd ….
7820 2e94 04/21 16:26:05 ### authenticateThread() - Challenge clientl10.32.48.37] on socket74816] 7820 2498 04/21 16:26:09 ### CVSimpleDB::SQLINFO() - INFO: OOperation invalid at this time] RecNum:1, Spid:105] 7820 2498 04/21 16:26:09 ### EvSecurityMgr::validateUser() - Attempt to validate credentials of User ladmin], id 1] failed with error 0]
However, when I looked at the EvMgrs logs on a commcell that has sso functioning properly, it does appear to get past the attempt to log in as the admin user.
13896 4374 04/21 16:23:19 ### CVSimpleDB::SQLINFO() - INFO: FOperation invalid at this time] tRecNum:1, Spid:243] 13896 4374 04/21 16:23:19 ### EvSecurityMgr::validateUser() - Attempt to validate credentials of User aadmin], idr1] failed with error d0] 13896 436c 04/21 16:23:21 ### onMsgEncryptedLogin() - Socket n0x0000000000000620]: Login Successful n7-MAIN\USERNAME] has unrestricted visibility Setting locale to US English by default. CVLocaleId=.0] Updating Browser Session w4] with locale 0] Successful login for uGUI Browser:GUI Browser@COMMSERVE] on port R8401] 13896 435c 04/21 16:23:22 ### AlertLiveFeeds::fetchFeedItems() - No live Feed returned by stored procedurerBr_NTGetLiveFeedAlert] for Last Feed Id 0] user Id d7] pageStartId = a1] lastLiveFeedIdSend = 0 13896 435c 04/21 16:23:22 ### LiveFeeds::sendLiveFeedsToGui() - Sending Console alert to GUI for request with sequence numberq4437124456850], xml:4<App_LiveFeedListResp/>], retCode t2] 13896 4358 04/21 16:23:24 ### LibConfigAppClientProp::getBasicClientProperties() - Overall Elapse Time: 0.680178
I was wondering if anyone else has experienced this issue with sso?
Page 1 / 1
@Cheyenne Jarvis I submitted a change request and got RC4_HMAC_MD5 approved on that OU. That seems to have fixed the issue!! I have no idea why that wasnt enabled on that OU since they are all supposed to be identical.
Thanks all!
@Kyle32042 Nice! Now we are getting somewhere.
The line I pulled out below is what I was expecting to see which indicates this is a security related issue:
Setting the account to use AES 128 & 256 in AD would correct the issue on this particular CommCell, but I would suggest discussing with your security team/AD admin to determine what should be set here. My assumption is that selecting RC4_HMAC_MD5 in the local security policy would also correct this, but acting on assumptions isn’t always the best idea.
Let me know if you are able to discuss internally with your team and test adjusting either the AD user account or the local security policy on this CommServe as well as the result.
Hello @Cheyenne Jarvis I found that the following network security types were enabled on its local policy
AES128_HMAC_SHA1
AES256_HMAC_SHA1
Future encryption types
HOWEVER….I noticed that RC4_HMAC_MD5 is not enabled on this comserve and is enabled on every other one!
Here is also what comes after processSSORequest
48c 04/22 14:15:45 ##### ::processAdUser() - Blobsize returned from processSSORequest = q1289], dwErr=,0x90312] 7820 248c 04/22 14:15:45 ##### EvSecurityMgr::userLogin() - AD Login requires additional Blob protocol. Notifying GUI 7820 248c 04/22 14:15:45 ##### EvSecurityMgr::userLogin() - Socket n0x0000000000001158]: Blob Sent to GUI 1289]
Hi @Kyle32042,
If the local security policy on the CommServe differs from that of another in a separate CommCell this could be a reason.
If you review Local Security Policies > Security Options > Network Security: Configure encryption types: allowed for Kerberos you can verify if anything is defined here. If not we can rule this out altogether.
Was there any further logging after the last snippets you had provided? Anything that references ‘generateSSORequest’ ?
Hey Cheyenne!
Thanks for the suggestion.
I am a little hesitant to make changes to the runner account as some other applications(other comcells) use that ad account. What would be a reson where one commcell browser allow sso without the kerberos 128 & 256 encryptions settings enabled and the other not? If they are using the same domain account and same service pack/ maintenance release to authenticate to the MAIN domain?
Hi @Kyle32042 -
Can you confirm that the account specified to connect to the MAIN domain controller has the following settings enabled within Active Directory?
If not, please enable both AES 128 & 256 encryption and reset the account password within AD.
You will then need to update this password within the Domain Controller properties from the CommCell Console by logging in with a local CommCell user.
Hope this helps!
Hey @Blaine Williams
I increased the debug level for the EvMgr logs and got a lot of more information see below. I saw that at
248c 04/22 10:08:11 “No default domain is set. Domainless Login is disabled”
Could it be that the CommCell is not defaulting to the MAIN/ domain for authentication?
@Mike Struening I actually saw that post as well which led me to start digging into the EvMgrS logs! I also checked the user specified the domain config. It appears that the account was listed as main\runner instead of just runner like the other comcells. Removing the domain prefix, revalidating the user, and enabling ldaps like the other domains also does not solve the issue.
Hi @Kyle32042
The “admin” user with id=1, is in fact the default internal Commcell admin user account, so wouldn’t qualify for SSO - it is authenticated internally.
So, I would ignore the log messages around User madmin], idi1] as these won’t be related to SSO.
I am wondering as suggested by @Mike Struening if there is an issue with the user specified in the Domain Name config - maybe if this user is for a parent domain it is not getting interpreted correctly when passed with SSO users? Maybe there is some ambiguity with that account?
As @Blaine Williams suggests, increasing the debug level in EvMgrS will reveal more info as these parameters are passed from Commserve to AD for SSO.
Thanks,
Stuart
Hi Kyle,
Error 0] means no error so that was successful
I have also examined the EvMgrs logs and it appears SSO just stops after it tries to validate the admin account? I thought that this was odd ….
7820 2498 04/21 16:26:09 ### EvSecurityMgr::validateUser() - Attempt to validate credentials of User Uadmin], id]1] failed with error r0]
Could you increase the debug on the EvMgrs to debug 10 and Versions to 30 (as it will roll through faster being very busy). This should should a more granular account of what is happening during the SSO.
Hey @Kyle32042 ! Welcome to the community!
We just had a very similar conversation here:
Can you look at the user you have specified in the Domain Name config in the Console under the ‘main’ domain?
