AD LDS service account as local admin to allow SSL connection?

Question

I am installing Active Directory Lightweight Directory Services (AD LDS, aka ADAM) on a Windows 2012 vm. After finally getting the configuration of the directory and synchronization handled, I am now running into an interesting problem. I have researched online for hours already, and I could use some expert advice.

When I use "Network Service" account as the service account for my LDS instance, I cannot initiate a connection on the SSL port (which I left as the default of 636) at all. We can make connections to the non-SSL port of 389. The same occurs for the domain service account "ADLDSSRVC."

When I use my personal domain credentials as the service account, we can use non-SSL connections on the non-SSL port and SSL connections on the SSL port. On the SSL connection, we can then bind to the LDS using the AD DS accounts via proxy bind redirection. My domain account has local admin rights on the host.

Do I need to make the domain service account, "ADLDSSRVC" a local admin? My boss wants to do this only as a last resort if I can't give it just the permissions I need. More specifically, I would like to know, if it's possible, what permissions the service account needs so that I can make SSL ldap connections to my AD LDS instance. A Technet article indicates that the ADLDS service account needs create, read, and modify access to %ProgramFiles%\Microsoft ADAM\instancename\data, but that didn't seem to make a difference for opening up port 636.

Blog.uvm.edu tells to do the following: Open the AD Users and Computers tool, locate the computer object on which you installed the Instance. Give the LDS service account “create all child objects” to the computer object. I'm not a domain admin, so I can't do that. Is that basically the same as making the service account a local admin?

Answer 1

This sounds to me like a case of the AD LDS service not being able to access the certificate it needs to set up LDAPS, when you set AD LDS to use a service account that does not have permissions to use the Local Machine\Personal certificate store.

From a Microsoft KB:

For AD LDS, put certificates into the Personal certificate store for the service that corresponds to the AD LDS instance instead of for the NTDS service.

So use MMC and add the certificates snap-in. Choose "Service Account" as the certificate store to view and choose the AD LDS service installed on that computer. Your SSL certificate needs to be installed there.

Answer 2

Building off of Ryan Ries's answer, here is how I solved the issue without making "domain\adldssrvc" an admin account:

Give service account permissions to Local Computer certificates

Open the certificate store by running mmc and adding the Certificate snap-in for the local computer.

Right-click the certificate in Certificates (Local Computer)\Personal\Certificates\ and select All Tasks\Manage Private Keys.

This pulls up a normal-looking permissions screen. Just add the appropriate user and give it full control of these private keys.

Remember to reset the LDS service after making this change! (services.msc)

Answer 3

Please refer to this post

https://stackoverflow.com/questions/36402069/solved-using-ad-lds-over-ssl-user-password-changing-with-principalcontext

I have done by configuring Enterprise CA first and then using guidance at this page

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx#Reasons

in the following order

1. Publishing a Certificate that Supports Server Authentication

   At point 5 of this step that is

   "5. On the Duplicate Template dialog box, leave the default selected Windows Server 2003 Enterprise selected and then click OK."

   Carefully select your relevant OS, tutorial saying leave it default but I was using Windows Server 2012 r2, So I choose the one I was using. Choose your relevant OS.

2. Exporting the LDAPS Certificate and Importing for use with AD DS

3. Verifying an LDAPS connection

Why should I need ADLDS connection over SSL?

Because I want the user to change his/her ADLDS password, Non-SSL connection using PrincipalContext was not allowing me to do this. So now I am using the following code, with the help and Grace of Allah Almighty Allhumdullilah it's working like a charm.

PrincipalContext pc = new PrincipalContext(
                    ContextType.ApplicationDirectory,
                    "YourServerUrl:YourSSLPort",
                    "CN=YourPartitionName,DC=partition,DC=com",
                    ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer,
                    "FullDistinguisedNameOfUser",
                    "PasswordOfUser");

bool IsUserValidated = pc.ValidateCredentials(
                    "FullDistinguisedNameOfUser",
                    "PasswordOfUser",
                    ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer);


            if (IsUserValidated)
            {
                UserPrincipal up = UserPrincipal.FindByIdentity(
                "FullDistinguisedNameOfUser", 
                "PasswordOfUser");

                up.ChangePassword("UserOldPassword", "UserNewPassword");
            }