Category Archives: Active Directory

I came across an interesting (if very frustrating) issue recently when a client provided me with an updated version of Windows Server 2012 R2. Prior to being handed the new media, I was using my own copy of Server 2012 R2 which is Build 6.3.9600.16384. I set up my MDT build which had a task sequence for each version of Server 2012 R2, Standard, Standard Core, Datacenter and Datacenter Core. Everything was fine and the UI language was configured correctly throughout.

I received the new media which was Build 6.3.9600.17415 and replaced my original copy of Server with this new version. All appeared to be fine until I tried to log in to the two Server Core versions where my password wasn’t being accepted. It transpires that these have some kind of bug / difference whereby the Input Locale doesn’t change to the configured language. In my case, I had an American (en-us) keyboard and I wanted to use an English (en-gb) keyboard. Weirdly, this was only the case for the core versions; the GUI versions were fine.

This one was also interesting but the application of the fix wasn’t explained clearly and I gave up on it.

Mostly, the ‘fix’ was to change the HKEY_CURRENT_USER\Keyboard Layout\Preload setting to the proper value and this does seem to work if you log on and change this manually in the registry. However I could not get this setting to stick when I applied it through any scripting mechanism.

I eventually found a solution though through group policy which I applied during the build. The steps below are for MDT but the same can easily be applied for SCCM.

Create a new GPO and browse to Computer Configuration\Policies\Admin Templates\System\Locale Services

Change Disallow copying of user input methods to the system account for sign in to Enabled.

Create a backup of the policy and copy it to your deployment share. Rename it from {GUID} to LogonKB. I created a custom directory to store this in called Custom2012R2. Under this I had a directory called GPOBackup which contain any GPOs I need to apply.

Download a copy of lgpo.exe and stick it in your tools\%architecture% directory (in practice you want the x64 version)

Create a TS step just before the Tattoo step called Copy GPOs Locally as below

It is important these two steps are early in the task sequence as the ‘damage’ is already done if you apply them too late. What is actually happening is that the GPO you have applied is preventing the Input Locale from being copied over to the login screen keyboard locale. You can see this before and after by running up the systeminfo command from a command prompt. On a machine without the application of the GPO the Input Locale will show up as:

Input Locale: en-us;English (united States)

and this will get copied over to the login screen language during build time. The GPO prevents this from happening and keeps the setting at en-gb.

One of the main criticisms of using web services is that they’re inherently insecure. By default anyone can access them and if they have functions to actually change anything then one must proceed with caution.

My current client was somewhat skeptical about their introduction and the only way I could bring them round to the wonderful gifts that they offer was to promise that we’d investigate a secure way to present them. There was some trial and error but I think we came up with a pretty good solution which I shall share here.

Why use web services at all?

There are an awful lot of reasons so I’ll keep it to why I like to use them. They’re a cheap and cheerful way to provide functionality by proxy. They can be used to off-load many tasks which, if you don’t have the budget for something like the wonderful System Center Orchestrator product, can make a great shoe-in. OK a little more explanation…

From a deployment perspective they can provide a mechanism to access Active Directory, MDT and SCCM without a client OS necessarily being part of AD. For example, they could be called from a WinPE session to update a database or query/update an OU. They’re relatively easy to write if you possess basic programming skills but if not, then I fully recommend you check out Maik Koster’s toolset here. Installation instructions are provided but do fall a little short on security, so let me crack on.

Securing the Web Services

First of all, if you run a PKI infrastructure, let me recommend you you change the URL to run under HTTPS. I am not going into detail in this respect here as there are plenty of how-to’s on this topic elsewhere on the web. Suffice to say it’s a no-brainer if you’re truly concerned about security, particularly if there are any services which need to pass confidential information such as passwords.

Next, ensure you have read Maik’s security blog for his web services. They’re basic but a good start. Now to secure it properly:

Securing the website via pass-through authentication

Follow these steps to lock down page to an AD group. I won’t go into detail on clicky-clicky, I assume if you have come this far you’ll know this stuff from within IIS and from the screen shots provided. If enough people tell me otherwise, I’ll review this though.

3. After installation, change authentication model as follows (apologies, image is a little blurry, I’ll try to update in due course).

4. Update Authorisation rules. Note that All Users verbs have been changed to POST. This prevents the web page appearing at all without a login prompt (ie the initial GET action is prevented from running) for all users other than those in that are members of the specified AD group.

5. Providers should remain at their defaults:

6. Update local Intranet sites. If the site isn’t trusted you may need to add this to local intranet sites to prevent a login box appearing.

You should now have full pass-through authentication for your web service, dependent on membership of the AD group of your choice.

There could of course be plenty of reasons you’re experiencing this behaviour but I’ll zoom in on two which I’ve noticed are particularly prevalent with Windows 7 and which may not be immediately obvious.

Server Message Block Signing

The first time I saw this behaviour, it was after I’d introduced a hardened-build policy (yes the very same Win7-EC-Desktop baseline policy I refer to in an earlier post). The problem is to do with the Server Message Block Signing policy. There are two fixes – either update the servers holding your DFS shares to acknowledge the policy so Windows 7 can talk to them securely or simply disable the policy on the Windows 7 clients. The first is preferable, the second solution is easier, your choice.

Change group policy to reflect the settings in the image and you should be fine. Obviously this is the easier, second option!

Token Size

Assuming this has been ruled out, the second, possibly less obvious reason for failure to connect to DFS shares is user token size. For those unfamiliar with token size, it basically relates to the size of the security ‘token’ you are issued with when you log onto a computer in a domain. This token is responsible for security assessment throughout your logon session. As more groups are added to your user account the token size increases. If you were to add a group that has another hundred groups nested in it, then your token size will increase accordingly!

Although this was a problem with Windows XP, it was generally more forgiving than in Windows 7/8 and for this reason you are more likely to notice the problem if you have recently upgraded. To confirm the issue, you are likely to see a message in the ‘system’ log in event viewer like the one below:

Again there are two choices you can make here. Firstly, you can increase the token size available for domain accounts in group policy. This, in my opinion, is the sensible way to fix the issue if you aren’t able to do much about the group sizes. The second, easier option is to remove groups you can do without until the token size is back to a respectable level. If this proves to be a slightly easier choice for you then you might require multiple accounts, eg one with admin groups to do privileged operations and another which lets you do day to day stuff. You can always use the run as… feature to save you logging off/on all the time.

OK so I decided to take a look at Windows Server 2012 and obviously the first thing you want to do after installation is to add AD DS. This is a pretty straightforward operation, not a whole lot different to how it’s done in Windows 2008. Simply select roles and features, add AD DS and follow the wizard through, creating the new forest, domain and DNS on the way.

However this is where I started to see some problems. I can’t say for sure whether I am the only one to experience this problem but as soon as the installation finished I was unable to open any AD tools and I was presented with an error similar to the following:

“The Specified Domain Does Not Exist or Could not be Contacted”.

My initial reaction after some minor troubleshooting was simply to remove and re-install it, after all this was a brand new installation and I really shouldn’t be seeing these issues on such a virgin server. I removed and reinstalled twice but still saw the same issue. Now as much as I love a challenge, I’ve been a busy man recently with one thing and another and finally this was an opportunity to use one of my support calls up that came with my Technet subscription. Last year I didn’t use any and it annoyed me I couldn’t carry them over. But I digress. I will therefore blog their analysis which finally fixed the issue. Apologies for the slightly iffy grammar, I’ve tried to fix the worst of it! I am still at a loss why I have experienced this issue, I’d be interested to hear if anyone else has had similar issues with server 2012.

___________________

=> On server 2012 made sure we have default shares “Sysvol & Netlogon” available as shared. This wasn’t the case.

=> With server 2012(a New Forest & Domain) the Sysvol replication is done by DFSR, thus checked the events in DFSR for any errors/warnings. We found the following :-

“The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled”

=> We ran the following Command in order to recover from the Issue, and resume the replication :-

With Server 2012 being the first DC in domain, the Sysvol replication is done using DFSR and detailed analysis of the DFSR logs yesterday revealed the DFSR service itself was in a state of error. We were getting an event id 2213 wherein the DFSR Jet database was not shutdown properly. This happens every time the service is stopped. Moreover by default auto recovery is not enabled for DFSR and without this starting and running correctly, he Sysvol & Netlogon shares weren’t getting shared. When we found the event we first fixed the DFSR database for Sysvol as per the KB and then resumed the replication using WMI command. This made sure the database is set correctly and the replication is underway. Sysvol and Netlogon were then shared.

MICROSOFT SUMMATION

PROBLEM DESCRIPTION:-

Unable to Open AD Snap-Ins and Getting The Specified Domain Does Not Exist or Could not be Contacted

RESOLUTION:-

=> We promoted a server to a domain controller running 2012, the dcpromo process went fine without any issues, however when the server was restarted we couldn’t open any of the AD Snap-Ins and not DNS

=> The DNS zones failed to load and the snap-ins error out with “The Specified Domain Does not exist or could not be contacted“

=> When checked the serer we found the Default Shares of “Sysvol & Netlogon” missing

=> The server is running 2012 so the Sysvol replication would be on DFSR, thus we need to make the server authoritative for the same

=> We first made sure we have policies and scripts created fine, once done we followed the steps in KB 2218556 (The steps were followed in LDP as ADSIEDIT would not load the partitions)

=> Once we were able to perform the steps we checked the events, were getting the event for DFSR Database issues, also checked the Debug Logs in Detail, and ran the following :-

Sorry, not the catchiest of titles but it does what it says on the tin (unfortunately).

Essentially, following the application of the Microsoft-recommended Win7-EC-Desktop baseline hardening policy (this baseline and others can be found when you install Microsoft Security Compliance Manager solution accellerator) users on XP desktops are no longer able to reach those Windows 7 machines that are subject to this policy. Two weeks on the phone to Microsoft resulted only in various network monitor captures, procmon captures and general frustration. In the end it was simple. Instead of concentrating on the specific RDP changes made in the policy, it was to do with the new firewall settings.

Just change Allow the connection if it’s secure to Allow the connection:

UPDATE

An fix has been created by Microsoft which both myself and the original customer who raised the bug have recently beta tested and approved. A full KB article and the final approved release version will be made available from the Microsoft site around about the 13th November 2012.