I'm replicating (seemingly succesfully) between ADAM 2003 SP1 (Windows Server 2003) and LDS 2012 (Windows Server 2012 R2), but LDS 2012 seems to be a little upset on start-up, logging the following message to the event log:

Internal error: An Active Directory Lightweight Directory Services error has occurred. 
 
Additional Data 
Error value (decimal):
-1073741790 
Error value (hex):
c0000022 
Internal ID:
30007ef

Has anyone encountered this error before?  What does it mean?  And importantly, can it safely be ignored?

Hi Thorsfall,

if you use a domain based service account it has to be member of the local admin group.

(http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/82/Default.aspx)

Hope that helps,

Lutz

Hi Thorsfall,

if you use a domain based service account it has to be member of the local admin group.

(http://www.activedir.org/Articles/tabid/54/articleType/ArticleView/articleId/82/Default.aspx)

Hope that helps,

Lutz

I'm using local accounts (servers in different workgroups) with the same name/password, and I've configured the ms-DSReplAuthenticationMode==0 and applied the appropriate hotfix to the Windows 2003 servers.

I've disabled the publishing of Service Connection Points and this isn't a domain, so SPNs aren't relevant here either.

The article you linked to states that they resolved a similar issue to mine by adding the LDS service account to the local administrators group, but that's never going to fly in an enterprise deployment, so it looks like they weren't able to determine what caused their issue either.

5.      Membership of the local Administrators group.
 
At the time of writing, the AD LDS product documentation indicates that the service account is not required to be a member of the local Administrators group on server running the AD LDS instance. However, my experience is that without this, the following error is generated in the event log corresponding to the instance each time the service is re-started.
 
Log Name:      ADAM (instance1)
Source:        ADAM [instance1] General
Date:          6/04/2009 11:22:08 a.m.
Event ID:      1168
Task Category: Internal Processing
Level:         Error
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred. 
 
Additional Data 
Error value (decimal):
-1073741790 
Error value (hex):
c0000022 
Internal ID:
3000715
 
The fact that the service account requires membership of the local Administrators group makes the choice to use Network Service even more compelling. The Network Service account has a lower level of privilege on the local machine than that of members of the Administrators group. This implies the potential for compromise is lower when using Network Service.

Does anyone know what these error messages are actually complaining about?

I'm using local accounts (servers in different workgroups) with the same name/password, and I've configured the ms-DSReplAuthenticationMode==0 and applied the appropriate hotfix to the Windows 2003 servers.

I've disabled the publishing of Service Connection Points and this isn't a domain, so SPNs aren't relevant here either.

The article you linked to states that they resolved a similar issue to mine by adding the LDS service account to the local administrators group, but that's never going to fly in an enterprise deployment, so it looks like they weren't able to determine what caused their issue either.

5.      Membership of the local Administrators group.
 
At the time of writing, the AD LDS product documentation indicates that the service account is not required to be a member of the local Administrators group on server running the AD LDS instance. However, my experience is that without this, the following error is generated in the event log corresponding to the instance each time the service is re-started.
 
Log Name:      ADAM (instance1)
Source:        ADAM [instance1] General
Date:          6/04/2009 11:22:08 a.m.
Event ID:      1168
Task Category: Internal Processing
Level:         Error
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred. 
 
Additional Data 
Error value (decimal):
-1073741790 
Error value (hex):
c0000022 
Internal ID:
3000715
 
The fact that the service account requires membership of the local Administrators group makes the choice to use Network Service even more compelling. The Network Service account has a lower level of privilege on the local machine than that of members of the Administrators group. This implies the potential for compromise is lower when using Network Service.

Does anyone know what these error messages are actually complaining about?

Hi THorsfall:

Thanks for your response.

>>The article you linked to states that they resolved a similar issue to mine by adding the LDS service account to the local administrators group, but that's never going to fly in an enterprise deployment, so it looks like they weren't able to determine what caused their issue either.

The error value c0000022 usually means access denied.  The account that is used as the AD LDS service account must be able to create, read, and modify files in the directory %ProgramFiles%\Microsoft ADAM\instancename\data.

https://technet.microsoft.com/en-us/library/cc794945.aspx

And according to you description, it doesnt work in an enterprise deployment. It is still limited by permission. Please add the service account to the domain admin groups . Then please have a try. Any problem please feel free to contact us.

Best Regards

Mary Dong

Hi THorsfall:

Thanks for your response.

>>The article you linked to states that they resolved a similar issue to mine by adding the LDS service account to the local administrators group, but that's never going to fly in an enterprise deployment, so it looks like they weren't able to determine what caused their issue either.

The error value c0000022 usually means access denied.  The account that is used as the AD LDS service account must be able to create, read, and modify files in the directory %ProgramFiles%\Microsoft ADAM\instancename\data.

https://technet.microsoft.com/en-us/library/cc794945.aspx

And according to you description, it doesnt work in an enterprise deployment. It is still limited by permission. Please add the service account to the domain admin groups . Then please have a try. Any problem please feel free to contact us.

Best Regards

Mary Dong

• Proposed as answer by Mary DongMicrosoft contingent staff, Moderator Wednesday, May 20, 2015 3:06 AM
• Marked as answer by Mary DongMicrosoft contingent staff, Moderator Friday, May 22, 2015 1:12 AM
• Unmarked as answer by THorsfall 6 hours 42 minutes ago

Hi THorsfall:

Thanks for your response.

>>The article you linked to states that they resolved a similar issue to mine by adding the LDS service account to the local administrators group, but that's never going to fly in an enterprise deployment, so it looks like they weren't able to determine what caused their issue either.

The error value c0000022 usually means access denied.  The account that is used as the AD LDS service account must be able to create, read, and modify files in the directory %ProgramFiles%\Microsoft ADAM\instancename\data.

https://technet.microsoft.com/en-us/library/cc794945.aspx

And according to you description, it doesnt work in an enterprise deployment. It is still limited by permission. Please add the service account to the domain admin groups . Then please have a try. Any problem please feel free to contact us.

Best Regards

Mary Dong

• Proposed as answer by Mary DongMicrosoft contingent staff, Moderator Wednesday, May 20, 2015 3:06 AM
• Marked as answer by Mary DongMicrosoft contingent staff, Moderator Friday, May 22, 2015 1:12 AM
• Unmarked as answer by THorsfall Monday, May 25, 2015 12:19 AM

Adding the AD LDS Service Account to the 'Domain Administrators' group isn't a documented requirement for running AD LDS, and should not be required.  It is equally unpalatable for security reasons as adding the service account to the local 'Administrators' group - It may stop the error message from appearing, but creates opens up the attack surface of the server considerably.

Hi THorsfall,

I understand that you think add the service account to admin account is not security. But according to your event log, this event is logged, because AD LDS wants to respond to auditing policy changes and tries to register a notification for this using a call to LsaRegisterPolicyChangeNotification. The event reports the failure of this API call.

Despite this failure, AD LDS appears to work as expected. It will however require a service restart to respond to auditing policy changes.

To avoid the behavior, either run the service using an administrative user or the default of the NetworkService account.

The LDS Setup allows only an Admin User to be selected as the service user. The use of non-Admin users is not tested by Microsoft and may cause unexpected problems.

Best Regards,

Mary Dong

Hi Mary,

Thank you for the detailed explanation of the error - at least this information is now out in the world for everyone to find.  This requirement seems to contradict Microsoft's documentation on what's required when 'Selecting an AD LDS Service Account': https://technet.microsoft.com/en-us/library/cc794945(v=ws.10).aspx

To perform replication in a Workgroup environment a 'Workgroup User' is required (not NetworkService), and the additional requirements are that the user have create, read and modify access to the underlying 'data' location.  Nowhere is there a documented requirement to run as an Administrator.  Having run the AD LDS setup at least 6 times now, I can assure you that it doesn't require that you configure an Administrator as the service user (else I wouldn't be seeing this error).

I also find it difficult to stomach that Microsoft would document and support a scenario that they haven't tested.  Granted, it can happen, but I'd expect that once these issues become known that a code fix or change to the documentation would be forthcoming.

Regards,

Trevor

Hi Thorsfall,

Yes, we not need to use the admins to install the ADLDS instance. We also can use the default of the network services to run this instance as mentioned in the articles. https://technet.microsoft.com/en-us/library/cc794945(v=ws.10).aspx However,  we high suggest using the admins to setup the instance avoid the unexpected problems, just like this event 1168.
I completely understand your frustrations with this issue and I want to thank you for your feedback on our products & documents again. Please understand that Microsoft strives to engineer our products to satisfy the needs of as many people as possible. Unfortunately, some problems inevitably arise. We do try to resolve these problems to the best of our ability. Having said that, we do appreciate the feedback we receive from our customers such as yourself. I will forward your comments to the appropriate development and usability experts for the purpose of improving user experience in the future.

Thank you for your understanding in advance.

Best Regards,

Mary Dong