A user was setting up ControlUp with split accounts and was facing issues when connecting with the console. It appeared that the impersonation activity was using the wrong account, causing access denials. Support explored the issue but couldn’t find a rootcause. It turned out changing the account for a specific application pool in IIS to the SVC_CU_DB account fixed the issue, suggesting it was an installer problem. An event log in security was making logon failures with a STATUS_WRONG_PASSWORD code.
Read the entire ‘Issues Setting Up ControlUp with Split Accounts’ thread below:
Hi,
I’m trying to setup ControlUp with split accounts. So one as the service account (SVC_CU) and one specific account for access to the database (SVC_CU_DB).
During setup everything is fine and installs correctly.
But as soon as I connect with the console to the server I get errors in the UserManagementService log regarding the connection to the database. It logs an access denied for the SVC_CU account.
I expected it to only use the SVC_CU_DB account for connections to the database so the SVC_CU has no access. Otherwise the split accounts make no sense.
I have been talking about this with support but we have no specific rootcause yet so I was wondering if others noticed this as well?
I suspect that impersonation is failing. The COP server uses this to run the SQL queries as a different user. It similar to right clicking a process > choosing run as. Just programmatically.
You should be able to see these failures in the security windows event log. Try looking for events with logon failures around the time that the logs mention impersonation.
This link has all the status codes you’ll find in the logon failure event log. In my example below the sub status is
0xC000006A. Which is STATUS_WRONG_PASSWORD
@member the impersonation is using the completely wrong account so yes it’s failing because SQL says no 🙂
In IIS several application pools are created during the install. 2 of them are setup to use the SVC_CU account.
HandshakePool and 8_WS.Pool
The rest is setup to use the SVC_CU_DB account.
Changing the account for the 8_WS.pool to the SVC_CU_DB account fixed the issue.
So this seems to be an installer problem?
Changing that account within IIS might break a bunch of other stuff internaly?
Continue reading and comment on the thread ‘Issues Setting Up ControlUp with Split Accounts’. Not a member? Join Here!
Categories: All Archives