CODEWITHSUNDEEP
c#active-directorywindows-services
Joseph Willcoxson
Joseph Willcoxson

Reputation: 6040

When does domain controller machine account NOT have permissions to change password

I have a Windows service running on a domain controller, let's call it DC-BoxX. The Windows service is running as DC-BoxX$, so it is running as the machine account.

My service occasionally rotates passwords for certain designated AD accounts under management. On my test boxes and on most customers installations, everything works fine. When it is time to rotate the password, it rotates.

At the appropriate time, there is a function that gets the AD user:

UserPrincipal GetADUser(string ADUserSamAccountName);

Another that creates a random password using uppercase, lowercase, numbers, and valid symbols:

string CreateRandomPassword(int len=25);

Then at some point, something like:

void UpdatePassword(UserPrincipal up, string password)
{
    try
    {
        up.SetPassword(password);
    }
    catch (Exception x)
    {
        Log("Failed to change password");
        LogException(x); // unpacks nested exceptions, not the problem
    }
}

On that certain server, it throws the exception, and I see this in the log.

Failed to change password Exception has been thrown by the target of an invocation. TargetInvocationException: Exception has been thrown by the target of an invocation. UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

It's not a null reference exception. I can duplicate with a simple command line program if I try to do the same thing with an account that doesn't have permissions to change the password. If I try to change the password with an account that is a member of Domain Admins, and the session is elevated, then I can change the password. Do the same thing with a non-elevated account and I get the same exception reported in the service.

My only thought is that the machine system account on the AD domain controller doesn't have permissions to change passwords (and probably other limitations too). If I look at my good local DC, if I open some admin tools and look at the members of the Domain Admins group, I see accounts, but no entry for the domain controller itself (this is on a machine where it is working, not problematic one.) So, there doesn't seem to be a way to view if the problematic DC had it's machine account as member of the Domain Admins. Why would it not be?

What could possibly cause this problem? I thought the machine account (NT_Authority) of the domain controller would always be a Domain Admin and always have omnipotent powers over the AD it manages.

Would there be some setting on the account that would block password changing by a service running elevated as the machine account on the DC? (An admin at the customer site could change the password, fwiw.)

Upvotes: 0

Views: 266

Answers (1)

Gabriel Luci
Gabriel Luci

Reputation: 40928

What could possibly cause this problem? I thought the machine account (NT_Authority) of the domain controller would always be a Domain Admin and always have omnipotent powers over the AD it manages.

Your assumption is incorrect. A DC's computer account does not automatically have Domain Admin.

I don't know if adding the computer account to the Domain Admins group would work. If you want to try, you can. There may be reasons not to, I don't know.

I have always used a user account specifically created for automation (AKA "service account") when I need to automate administrative tasks.

Upvotes: 0

Related Questions