Installed the AD Slave and service starts with the local service account.
We have an AD account we use with our DEX system that has all the priviledges required to do WMI.
If we try to start the service with the dex account, it fails.
We have confirmed that it has administrator rights and it has logon as a service priviledges.
We tried one of corporate admin accounts and the service still would not start.
Tried on two different systems… same thing.
Tried command line and got:
(1063, ‘StartServiceCtrlDispatcher’, ‘The service process could not connect to the service controller.’)

This is what was in the windows logs:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 534
Date: 11/16/2009
Time: 2:09:13 PM
User: NT AUTHORITY\SYSTEM
Computer: MROSAWD2
Description:
Logon Failure: Reason: The user has not been granted the requested logon type at this machine User Name: dexadmin Domain: TERANET Logon Type: 5 Logon Process: Advapi Authentication Package: Negotiate Workstation Name: MROSAWD2 Caller User Name: MROSAWD2$ Caller Domain: CORP Caller Logon ID: (0×0,0×3E7) Caller Process ID: 504 Transited Services: – Source Network Address: – Source Port: –

Thanks

Hi there George,

The Logon as a service right certainly looks like a likely candidate here, but I note that you’ve checked that already. What’s not clear though is where/when you are entering the credential. If you are re-installing the slave and providing the credential during install, then it’s possible that the credential will not work first time, and the install itself may fail to start the slave. If this happens though, it can often be remedied by following the steps under Specifying the account used to run the slave in the documentation, to enter the credential via the service control panel.

If this doesn’t help, please would you clarify where and when the credentials are being entered, and which versions of the product and OS you are using?

hope this helps
Wilko

We have changed the account a few times via the service panel… back and forth between the local account and a domain account. If I use the local account, the service starts and I can contact it via the UI. So I think the agent install is OK.

We were testing BMCs ADDM v7.5 but when they announce the Tideway acquisition, we downloaded the Community edition last week.

The slave is loaded on a Win Server 2003, standard edition, SP2

It appears to be a security setting within windows server. Although the account has permissions to run a service, it is not allowed to do so when it tries to logon during service start. (not even administrators are allowed to start the tideway service).
Our windows systems are hardened, so I will review the settings to see if any may be the suspect.
I did get around the problem though.
I installed the credential server, and let it run as the local system acct.
I then setup the credentials in the application, and it all worked.
Why is letting the service run as the local account not recommended?

Thanks

If your servers are hardened then the Credential Slave is unlikely to help you.

UAC on all modern Windows installs means that even if a credential has admin rights it will not get them if it used remotely unless it is an AD authenticated account.

Unless you are willing to make the necessary registry changes on all the target hosts you should use the AD Slave.

So the Credential Slave will work for you in small scale tests but for full deployment you will need to deploy the AD Slave.

This is not an unusual situation and if you move to a full deployment our tech sales folks have experience on what is needed to help you with that and to work with your security stakeholders.

Agreed.
When the powers that be decide to order the product, I will make the request to BMC that this is an outstanding issue and needs to be resolved.
For my testing purposes, I am getting what I want.

Thanks

George Demeester - 19 November 2009 02:44 PM

Why is letting the service run as the local account not recommended?

We’ve seen it alter the behaviour of authentication when running remote access. All the slaves expect to be running as a service and use authentication approaches that are anticipating this – hence the advice.

Here is the notes I made on a previous post that might be helpful:

The reason I ask is that Microsoft changed some of the permissions around WMI in the Vista/Server 2008 line as part of how they handle remote users under User Access Control (UAC). This is avoided if you use an AD Slave as UAC doesn’t apply authenticating using a domain account with local admin rights.

[quote author=“Microsoft”]If your computer is part of a domain, connect to the target computer using a domain account that is in the local Administrators group of the remote computer. Then UAC access token filtering will not affect the domain accounts in the local Administrators group. Do not use a local, nondomain account on the remote computer, even if the account is in the Administrators group.

The summary of this is that the Credential and Workgroup Slave can’t discover Vista/2008 properly via WMI. The fallback methods using psexec also will fail for related reasons and even if they did not I suspect that the data returned from an FR locale machine would not work.

Full details of the UAC behaviour are on MSDN http://msdn.microsoft.com/en-us/library/aa826699(VS.85).aspx, and that also details the registry key that can be changed to disable UAC on a machine by machine basis.

George Demeester - 19 November 2009 03:01 PM

Agreed.
When the powers that be decide to order the product, I will make the request to BMC that this is an outstanding issue and needs to be resolved.
For my testing purposes, I am getting what I want.

Thanks

The standard settings for the UAC behaviour are unfortunately a decision for Microsoft and there is little we can do to work around them.

I believe the reliance on a domain authenticated account is how they have chosen to balance up the conflicting desires out of the box for home users to be as secure as possible and yet have controlled remote access in the enterprise.

That particular recommendation is because there are some edge cases where some of the fall back methods, particularly the pstools family, don’t work as reliably using the Local System user. If primary methods like WMI are working well then it probably won’t cause an issue. The consequences of running as the local system user are only that some fall back discovery methods won’t work on some version of Windows.
We probably hit those scenarios less frequently these days; also the only likely consequence of using that account is occasionally getting a slightly less comprehensive discovery.

I’d certainly be interested if you learn any more about particular permissions, or lack of them, preventing the AD slave from working.