Domain Controller SceCli event 1202

Greetings Humans! It is Sunday morning and I had to work very early to do some testing after a migration. There is also a lot of waiting involved so i resolved to run some checks on the health of our domain controllers. We had a lot of SceCli event 1202 warnings on every single DC. Those errors are potentially caused by an account that was deleted or not replicated correctly. That account is also part of the User Rights Assignment policy, most commonly on the “Logon as a service” settings. To figure out the account that is causing the error browse to: %SYSTEMROOT%SecurityLogswinlogon.log Search for “Cannot find” In my case I found the following: Error 1332: No mapping between account names and security IDs was done. Cannot find postgres_eip. That means that the account postgres_eip does not match the SID Active Directory expects it to have. (as it no longer…

Read the complete blog: http://thedesktopteam.com/blog/david/domain-controller-scecli-event-1202/

Windows Azure Pack in a FIPS compliant environment

I am just about to deploy a Windows Azure Pack (WAP) express installation in an environment where they have to turn on FIPS compliancy. There are companies that turn everything in GPOs on that have “security” in the name or description field, but actually don’t really need it, and then there are companies that actually need it. Windows Azure Pack configuration fails Usually installation and configuration of a Windows Azure Pack installation is really easy and straight forward, especially when using the Express install, which puts every feature on one server (only for really small / limited PoCs!). I’ve done that multiple times already, but this time the configuration failed. […]

Configuring Group Policies for your ConfigMgr Servers

Disclaimer: Please test and validate this in your test environment, don’t take the information i provide for granted. This article describes a method to determine correct settings and doesn’t supply the answer to your specific environment !

When you are installing System Center Configuration Manager (ConfigMgr) in environments where group policies are used to control the User Rights Assignment and Security Options security settings of the Servers, you have to be extra carefull.

You can expect some strange behavior after the installation because when the companies policy is applied again, it removes some entries made by either the prerequisite installation (roles and features) and installation of ConfigMgr itself, and this can result in some interesting scenario’s. Therefore my advise would be:

If you know the environment in which you are going to install ConfigMgr in, has a lot of restricing group policies make sure you do the installation of ConfigMgr while the servers are member of an OU with minimal policies applied.

After you have done the installation, you can then profile the different types of ConfigMgr server roles (Primary Site, CAS, Distribution Point, Management Point etc..) and define one or several so called "delta policies" which contain the settings needed by ConfigMgr

How to determine the necessary Policy Settings:

In order to determine the correct settings, its best to build ConfigMgr in a test environment, where the servers are isolated from Group Policies when you are installing them. Start with detailing the configuration of the Security Settings of the machine in the state which you received it, or just after you installed the machine yourself. This can be easily done by exporting the User Rights Assigment and the Security Options settings using the Export List… options when you rights click the User Rights Assignment or Security Options node. Save the output, and make sure you detail the fact that this settings reflect your start position.

The Second step should be that you configure the requirements needed on the Server in order to be able to install Configuration Manager, like IIS, WSUS etc..) and perform the installation. When finished repeat the same procedure and make sure you name the output files to reflect the post ConfigMgr installation state.

There are probably more ways to achieve this goal, but this works with out of the box functionality. Next I used WinDiff (still available in the Windows Server 2003 Service Pack 1 32-bit Support Tools, grab it while you can) to show me the difference between the two text files:

clip_image001

The outcome of my investigation, which is the difference between the first and the last output saved, resulted in the following settings:

User Rights Assignment:

Adjust Memory Quotas for a process: Add NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL

Bypass traverse checking: Add NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER

Generate security audits: Add LOCAL SERVICE,NETWORK SERVICE,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

Impersonate a client after authentication: Add IIS_IUSRS

Log on as a batch job: Add IIS_IUSRS

Log on as a service: Add SYSTEM,SQLServer2005SQLBrowserUser$CM01,NT SERVICEALL SERVICES,NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

Replace a process level token: Add NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

Security Options:

Network access: Remotely accessible registry paths and sub-paths: Add SoftwareMicrosoftSMS

Caution: Keep in mind, that when you configure a so called Delta Policy for your ConfigMgr servers – which only contain the settings needed for that type of machine, you have to provide the default settings plus the above settings in the policy in order for the setting to be applied successfully. Also make sure not just to copy the settings from me above but create your own pre and post export of the User Rights Assignment and Security Options settings.

The Caveat (without it it wouldn’t be fun…)

As always, when implementing these settings you run into some other "Challenges", in my case it was because of the fact that the IIS Classic .NET AppPool and DefaultAppPool accounts weren’t added successfully to the registry after applying the newly configured policy, in an AD environment running Windows Server 2008. When you run a GPResult /H Report.html the report details that the settings are successfully applied, but when opening the local policy editor (Gpedit.msc) or the Resultant Set of Policy tool (RSOP.msc) when troubleshooting further you will notice that the settings are not applied.

clip_image002

The fact that the settings are not applied is also logged in the Application event log and searching for eventid 1202, resulting in the following error:

clip_image003

You can also see how Group Policies are applied by looking at the winlogon.log file created in the %windir%securitylogs folder during logon.

Configuring SeImpersonatePrivilege for this account is not supported.

Configure Classic .NET AppPool.

Error 1332: No mapping between account names and security IDs was done.

After this, then Google or you other favorite search engine is your friend, eventually resulting in finding the following KB article 977695: http://support.microsoft.com/kb/977695

The KB Article describes that when the Group Policy Management Editor changes settings under User Rights Assignment, it translates per-Service SIDs to service names, it does not add the NT Service or IIS AppPool prefix when doing so though, resulting in the behavior that only the supplied name in the Group Policy Management Editor (for example Classic .NET AppPool) is written to the GptTmpl.inf file while this should be IIS AppPoolClassic .NET AppPool instead.

The KB Article provides two solutions, by either requesting a hotfix to fix the Group Policy Management Editor, or by manually editing the GptTmpl.inf file. I decided to just the last option to edit the GptTmpl.inf file directly (search for the GUID of the Policy, and locate the correct .inf file)

[Privilege Rights]

SeIncreaseQuotaPrivilege = LOCAL SERVICE,NETWORK SERVICE,Administrators,NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

SeAuditPrivilege = LOCAL SERVICE,NETWORK SERVICE,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

SeBatchLogonRight = Administrators,Backup Operators,Performance Log Users,IIS_IUSRS

SeServiceLogonRight = IIS AppPoolClassic .NET AppPool,IIS AppPoolDefaultAppPool

SeAssignPrimaryTokenPrivilege = SYSTEM,SQLServer2005SQLBrowserUser$CM01,NT SERVICEALL SERVICES,NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

SeImpersonatePrivilege = LOCAL SERVICE,NETWORK SERVICE,NT SERVICESQLSERVERAGENT,NT SERVICEMSSQLSERVER,IIS APPPOOLClassic .NET AppPool,IIS APPPOOL.NET v4.5,IIS APPPOOLDefaultAppPool,IIS APPPOOL.NET v2.0,IIS APPPOOL.NET v4.5 Classic,IIS APPPOOL.NET v2.0 Classic

After modifying the GptTmpl.inf file and running a GPUpdate /force, i was able to check a Resultant Set of Policy, which gave the expected result.

I did a check if the same issue would occur in my own home lab, but while defining the same settings on my Windows Server 2012 R2 policy while adding the necessary groups I encountered a another issue. I was not able to add groups containing a in the definition resulting in the following error:

clip_image004

So, also here i modified the GptTmpl.inf file adding the groups directly. Resulting in a working policy applying the necessary settings.

Hope this helps.