One of my customers had problems with certain users being member of a lot of Active Directory groups. This resulted in several client side issues. There’s an easy and well-known “fix” for that: raise the MaxTokenSize registry key on all Windows operating systems in your domain. On Windows 8(.1) / 2012 (R2) the MaxTokenSize is already at its maximum (advised) value out of the box. That value is 48.000 bytes. In order to mitigate these users their access problems we raised the MaxTokenSize to 48.000 bytes on all clients and servers that are running Windows 7/ Windows 2008 R2. After this change the typical issues were gone. However new ones came up:

From time to time, when HTTP is involved, issues were encountered:

• Opening the Direct Access management console (depends on WinRM)
• Open the FIM Portal
• Streaming App-V packages over HTTP
• …

Typically the user would receive several authentication prompts and even after specifying valid credentials another prompt would reappear. Example browser based issue:

As you can see the browser gives an HTTP 400 Bad Request error. Using a network trace we can easily see why it’s considered bad:

And the packet details:

The details clearly state that The size of the request headers is too long.

The problem here is that the token is allowed to be up to 48.000 bytes where it used to be 12.000 bytes. The http subsystem of a windows server has several parameters that are supposed to protect the server from oversized requests. However, as the token can now be a lot larger, the maximum request size has to be tuned as well:

From: KB820129

Below: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters there are two interesting values:

And from: KB2020943 we can find a formula to calculate the MaxFieldLength to set based on the MaxTokenSIze.

If MaxToken is 48.000 bytes (default in Windows 2012 and configure by GPO for 2008 R2/ Win7):

• (4/3 * 48000) + 200 = 64200

We’ll use the maximum allowed value of MaxFieldLength 65534 (=~ 64200) to allow tokens up to 48000 bytes. We’ll also use this value for MaxRequestBytes.

• MaxFieldLength: we can take the maximum allowed value: 65534
• MaxRequestBytes:  65534

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Other useful information:

• http://blogs.msdn.com/b/ashishsingh/archive/2010/04/03/windows-authentication-for-accounts-with-large-kerberos-tickets-may-not-work-despite-having-maxtokensize-in-place.aspx
• http://www.grouppolicy.biz/2013/06/how-to-configure-iis-to-support-large-ad-token-with-group-policy/

I specifically wanted to post this information as in many other only articles/posts I always see people just using the maximum allowed value for MaxRequestBytes and I don’t feel 100% comfortable with that. Second,  in my opinion it’s advised to have these values pushed out to all your server systems. Especially now that Windows 2012 and up have a MaxTokenSize of 48.000 by default. If you don’t push these HTTP.sys parameters, you’ll end up troubleshooting the same phenomena multiple times from different angles. Why waste time?

Recently I helped a customer which was having troubles migrating from a Windows 2003 cluster to a Windows 2012 cluster. The resources they were running on the cluster consisted of many in house developed applications. There were about 80 of them and they were running as generic applications.

Due to Windows 2003 being end of life they started a phased migration towards Windows 2012 (in a test environment). At first the migration seemed to go smooth, but at a given moment they were only able to start a limited amount of applications. The applications that failed gave an Out Of Memory exception (OutOfMemoryException). Typically they could start about 25 applications, and from then on they weren’t able to start more. This number wasn’t exact, sometimes it was more, sometimes it was less.

As I suspected that this wasn’t really a failover clustering problem but more a Windows problem I googled for “windows 2012 running many applications out of memory exception”. I found several links:

HP: Unable to Create More than 140 Generic Application Cluster Resources

IBM: Configuring the Windows registry: Increasing the noninteractive desktop heap size

If the parallel engine is installed on a computer that runs Microsoft Windows Server, Standard or Enterprise edition, increase the noninteractive desktop heap size to ensure that a sufficient number of processes can be created and run concurrently

So it seems you can tweak the desktop heap size in the registry. Here is some background regarding the modification we did to the registry.

The key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

SharedSection has three values: (KB184802: User32.dll or Kernel32.dll fails to initialize)

• The first SharedSection value (1024) is the shared heap size common to all desktops. This includes the global handle table, which holds handles to windows, menus, icons, cursors, and so forth, and shared system settings. It is unlikely that you would ever need to change this value.
• The second SharedSection value (3072) is the size of the desktop heap for each desktop that is associated with the "interactive" window station WinSta0. User objects like hooks, menus, strings, and windows consume memory in this desktop heap. It is unlikely that you would ever need to change this second SharedSection value.
• The third SharedSection value (512) is the size of the desktop heap for each desktop that is associated with a "noninteractive" window station. If this value is not present, the size of the desktop heap for noninteractive window stations will be same as the size specified for interactive window stations (the second SharedSection value).

Default on Windows 2012 seems to be 768

Raising it to 2048 seems to be a workaround/solution. A reboot is required! After this we were able to start up to 200 generic applications (we didn’t test more). However after a while there were some failures, but at first sight quite limited. This might be due to the actual memory being exhausted. Either way, we definitely saw a huge improvement.

Disclaimer: ASKPERF: Sessions, desktops and windows stations

Please do not modify these values on a whim. Changing the second or third value too high can put you in a no-boot situation due to the kernel not being able to allocate memory properly to even get Session 0 set up

Bonus info: why didn’t the customer didn’t have any issues running the same workload on Windows 2003? They configured the generic applications with “allow desktop interaction”. Something which was removed from the generic applications in Windows 2008. Because they had “allow desktop interaction” configured, generic applications were running in an interaction session and thus were not limited by the much smaller non-interactive desktop heap size.

I’m a bit stumbled that I’ve only come across this now. Recently I discovered that there are some cases where you can end up with your service account using a temporary profile. Typically this is the case where your service account has very limited privileges on a Server. Like application pool identities which run as a regular AD user, which I consider a best practice. I myself saw this in the context of the application pool identities in a SharePoint 2010 farm or with SQL Server Reporting Services 2008 R2.

The phenomena is also described at: Todd Carter: Give your Application Pool Accounts A Profile So this does not apply to all Application Pool identities! Only those running with “load profile=true”.

In the Application event log you can find the following event:

Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

How to fix it if you see those nasty “c:\users\TEMP” folders?

1. Stop the relevant application pools
2. Stop the IIS Admin Service (in services.msc)
3. See that the TEMP folders are gone in c:\users
4. Follow the next steps

How to make sure your accounts get a decent profile?

We will temporary add the service account to the local administrators group so they can create a profile. In fact all they need is the “logon locally” privilege. The second command will start a command prompt while loading a profile. This will ensure a proper profile is created.

1. net localgroup administrators CONTOSO\AppPoolAccount /add
2. runas /u:CONTOSO\AppPoolAccount /profile cmd
3. net localgroup administrators CONTOSO\AppPoolAccount /del

As a side note: if the TEMP folders are not disappearing, or you are still getting a temporary profile, you can try to properly cleanup the temporary profile:

1. Stop the application pools
2. Stop the IIS Admin Service
3. Using right-click properties on computer, choose advanced tab and then pick User Profiles. There you can properly delete them.

If you’re still having troubles you might need to delete the TEMP folders manually AND cleanup the following registry location: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList Especially look if there aren’t any keys with .bak appended to it.

A while ago I got a tip of a colleague to use the DebugView utility from Sysinternals (Microsoft) to debug code. Once in a while I write a simple rules extension for Forefront Identity Manager, or even an attribute store for ADFS. As simple as they may be, sometimes things don’t go as I wish…

You can use DebugView by using the following lines in your coding: at the top of your class you make sure you have “using System.Diagnostics;” and everywhere you feel like you want diagnostic output you put “Debug.WriteLine(“your string here”);” It might be obvious, but you have to make sure you compile your code in Debug mode!

And perhaps a little sting here: make sure the DEBUG constant is enabled. It’s on by default though.

I’ve used this approach a few times now, but yesterday things went bad. After starting DebugView my server, a VM I was running on my Laptop, became sluggish. I still could reproduce my issue though, but nothing was being captured. Odd. After checking the task manager I found out my DebugView.exe process was using 100% CPU.

Off to google! I quickly found this topic: forum.sysinternals.com: DbgView.exe 100%CPU

Finding the DebugView version 4.76 is not that easy though, there’s a zillion sites just linking through to the Microsoft site and thus giving you version 4.79 every time. Finally I found this site which has the actual 4.76 version:  http://www.myfiledown.com/download/435608/debugview-435608-3.html But the link seems down now… Once I used this version my CPU usage was normal and my debug came out just fine.

One of my colleagues was having troubles accessing an HTTPS site. The site is secured with a certificate coming from an Active Directory Certificate Authority. Now I know of a bug where if you have a pinned website on your taskbar, and from that browser instance you open an HTTPS site with an untrusted certificate, there’s no "continue anyway” button…

Now this wasn’t the case today. He had the “continue anyway” option, where you typically click on, load the site and check the certificate. However, after clicking, it didn’t go trough, it just remained at the same page. We installed the root CA manually in the trusted root authorities, but still no improvements. When verifying the root certificate in the MMC we also saw it mentioned that the digital signature was invalid.. odd!

Using that as a query for google we quickly came across this:

• RSA keys under 1024 bits are blocked
• Blocking RSA Keys less than 1024 bits (part 2)
• How to identify if your ADCS has issued any certificates with public keys <1024 bits (in preparation for KB2661254)

If you read those first two carefully you’ll see the update will be released as a critical non-security update on august 14th for Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

An example of a bad certificate:

Now how come he was having this issue now already?! Ahah, now comes the clue! He was using Windows 8! Now I am too, and I’m not having that problem with that specific site, but here’s the difference:

• Windows 8 with issue: Windows 8 Release Preview: build 8400
• Windows 8 without issue: Windows 8 Consumer Preview: build 8250

So it seems they’ve included this update somewhere in the build process of Windows 8.

Having certificates with an RSA key < 1024 is probably not really the case for most of us, but be sure to double check those certificates and their (intermediate) roots! Especially for those customer facing sites where you can’t control what updates hit the clients and thus potentially might be denied access to your sites.

In the project I’m currently involved in, we have several virtual machines installed with Windows 7 as the operating system. These workstations are used as administration workstations to manage the server infrastructure. Every once and a while someone would get disconnected from their terminal server session. By simply reopening the session they could continue their work. We stumbled upon the following KB article: KB2083411 The article states:

When the policy is refreshed (by default, every 90 minutes, or manually through GPUPDATE), the policy settings are deleted and then reset. During this period, the configuration on the server is temporarily valid. Therefore, all sessions may be disconnected

Because we were enabling remote desktop through GPO, this was the exact issue we were having.  We could reproduce it by executing gpupdate in a remote desktop session. The disconnection would not occur every time, but every once in a while. To be more precise when enabling remote desktop through group policies (Allow users to connect remotely using Terminal Services ), the following registry key is set:

The workaround suggested in the KB article is to set the registry key fDenyTSConnections below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server to a value of 0. Basically this is just enabling remote desktop through the registry instead of through the GUI.

If you have to do this on a lot of workstations there are a few options. We first thought to just deploy this using our desktop deployment solution (SCCM). However a colleague of mine had the great idea to just try setting it using group policy preferences. Whenever group policies are being refreshed, everything below HKLM\SOFTWARE\Policies is erased and reset, but group policy preferences operate in an other way. Whenever you set something with group policy preferences, it’s set forever, unless you check the option “remove this item when it is no longer applied”. For some additional information on the differences between GP policy setting and GP preference settings.

Here are also some related topics on the TechNet forums: http://social.technet.microsoft.com/Forums/en/winserverGP/thread/10fb967c-c6c8-480b-8d30-70f0da15cdba and http://social.technet.microsoft.com/Forums/en/winserverGP/thread/cd94ea99-a843-4781-bbcf-7538182511c9

To be completely honest this subject has been blogged a lot in the past. However just this Friday I helped a colleague which was having issues setting up DNS aliases for SQL. He seemed to have troubles connecting his Management Studio to SQL. And today I could use the information again when working at a customer which was having issues authenticating to his webserver. So I believe this is still solid information to spread.

So if you hit google with "disableloopbackcheck windows 2008 R2” you get quit some results. And if you search the official KB articles, this registry setting is referenced a lot when dealing with Access Denied errors locally on a machine. All these scenario’s have one thing in common: someone or some service is trying to access a service under an alias and this from on the machine itself.

Simple example scenario: you set up Active Directory Certifcate Services and you choose “pki.contoso.com” as an alias for your Certificate Authority server. After configuring this record in DNS, you try to access this website http://pki.contoso.com/certsrv on the CA itself in vain. After trying to provide correct credentials multiple times it just fails. You are getting that nasty “HTTP Error 401.1 – Unathorized You do not have permission to view this directory or page using the credentials that you supplied”.  Accessing this from a remote workstation using the same credentials works just fine.

If this is your problem, are it sounds similar, then this is your solution:

• kb926642: You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
• kb926642: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"
• kb887993: Users experience authentication issues when they access a Web page in IIS 6.0 or query Microsoft SQL Server 2000 after you install Windows Server 2003 Service Pack 1
• kb914060: A logon window appears in Windows Server 2003 Service Pack 1 NLB when you try to browse the virtual NLB cluster name
• kb971382: Errors when crawling content sources in SharePoint Server 2007: "Event ID 2436" and "Access is denied"

And the list goes on. The workaround is very easy and active immediately: just create a REG_DWORD called DisableLoopbackCheck below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and give it a value of 1

One of the articles actually references the DisableStrictNameChecking registry key. I remember setting this one when accessing a share didn’t worked when using an alias. Must but it’s older brother. Here’s an explanation: kb281308: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name The reason we’re probably hearing this one a lot less is because since SMB 2.0 (Windows 2008 and up)  this is no longer required.

I wanted to test something involving Exchange so I opened my d:\Virtual Machines folder on my system and searched for something with exchange on it. I found MBX01 and booted the VM. Oddly I couldn’t log on using my domain admin. It got an error saying the password was wrong. So I logged on using the local administrator. In the event viewer we can see that the machine has been offline for a year + 7 days. However according to AskDS: Machine Account Password Process a machine which is offline for a long period of time should be able to connect to the domain without issues.  Either way, if you got the following events in your event log:

NETLOGON, Event ID 3210

This computer could not authenticate with \\DC01.home.local, a Windows domain controller for domain HOME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

GroupPolicy, Event ID 1129

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has succesfully processed. If you do not see a success message for several hours, then contact your administrator.

TerminalServices-RemoteConnectionManager, Event ID 1067

The terminal server cannot register 'TERMSRV' Service Principal Name to be used for server authentication. The following error occured: Access is denied.

Then I would suggest you reset the machine account password as a possible solution. KB325850: How to use Netdom.exe to reset machine account passwords of a Windows Server domain controller has a nice explanation on how to perform this procedure. The following command can be used:

netdom resetpwd /s:dc01.home.local /ud:home\tvl /pd:*

The command is run on the server which is having issues and the dc01.home.local is a reachable DC. home\tvl is a user with enough privileges in AD to reset the password for the given computer. /pd:* will ensure the command prompts for the password. To finalize the procedure, reboot the server.

As a possible alternative solution: you can re-join the server to the domain. I prefer the password reset though, seems cleaner. When rejoining a server to the domain I like using the following trick: instead of the traditional workgroup,reboot, domain & reboot again, I just change the FQDN of the domain into the NetBIOS name of the domain. Hence I only have to reboot the server once and the server never left the domain…

A while ago I wanted to view the event log of a server. For this task there is no need to log in using remote desktop. However when I fired up the event log viewer and tried to connect to the NetBIOS name of my server I got the following error:

Using remote desktop I could connect just fine to the server. At least that’s what it looked like. Locally I could open the event log without issues. But I saw events which couldn’t possibly be logged on this server. And then it came clear, there was an IP conflict! To be honest it’s a lab environment so these things can happen occasionally.

The reason this fails is because my client (my administration pc) asks AD for a Kerberos Ticket for server x whilst when connecting I’m actually presenting this Kerberos Ticket to server y. This results in a server receiving a ticket encrypted with a password other than it’s own. Result: the above error.

Thomas, we should have updated the CMDB, Vuylsteke

Most Windows management tools behave pretty well with User Account Control (UAC), at least they prompt you for your credentials before actually launching. In the past I already described some of the naughtiness of UAC: Explaining UAC related behavior One of the things that has been bothering me ever since I first met UAC is how the file browser (Windows Explorer) handles UAC.

The problem(s)

One of the dirty things it does for you is adding your account to the ACL of files you normally have access if you are member of the local administrators. This is the prompt you can click continue o-so-easy:

At first sight you’ll be satisfied, after clicking continue and providing your credentials you will see the files & folders. But below the hood your account just got granted access. This doesn’t breaks things, but it’s not nice. The second issue I encounter a lot is when trying to edit a configuration file for an application or service. Or even a easier example: adding an entry to the hosts file. You browse to c:\windows\system32\drivers\etc double click hosts, make your modification and when trying to save…

And after clicking OK you are prompted for a filename and location. Now that’s a lot of hassle to add something to the hosts file.

The workaround:

UAC elevation allows you to start a given application (process) in an other context with your elevated token (where you do have administrator privileges). And that’s where things go wrong with Windows Explorer. Out of the box when a user logs on, one instance of explorer.exe is started and all subsequent instances are running from this instance. As the explorer starts with your limited token (non administrator privileges), all other instances are limited as well.

Below you see multiple explorers open, but only one explorer.exe is listed.

Now there is a modification we can do to alter the behavior of Windows Explorer. We can check “Launch folder windows in a separate process” in the Folder and Search Options.

Whenever we now start multiple Windows Explorer instances, they will all open below the second explorer.exe instance:

This is actually quit remarkable and very subtitle: after setting this option, the first Windows Explorer instance you open, determines under which token the following instances will run.

Automating the workaround:

The “Launch folder windows in a separate process” is a per user setting, and is stored in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced as the value SeparateProcess.

But since we have those almighty cool Group Policy Preferences, we can click this setting together in no time:

1. Create a GPO, or alter an existing one and create a new “Folder Options (Windows Vista) below User Configuration > Preferences > Control Panel Settings > Folder Options

2. At first all settings will be underlined in green, meaning all these will be pushed to the user as listed. We can actually alter this behavior with the F5-F6-F7-F8 keys.

3. Press F8 so all settings are underlined in red: none will be applied to the user

4. Check “Launch folder windows in a separate process” and press F6 to underline that specific setting in green so it will be pushed to the user.

Testing the workaround

The easiest way to start Windows Explorer in elevated mode is to locate in in your start menu below Accessories (or type a part of the name in your start menu) and right click and choose Run As Administrator.

After editing something like the hosts file, you’ll be able to save it without prompts:

Whether you set the setting by hand or by GPO, it’s immediately effective. But as the first instance determines the context, you’ll have to close all open Windows Explorer instances first before you can run Windows Explorer as Administrator. This does not include the explorer.exe process which is started immediately at logon. A lot of workarounds for UAC and Windows Explorer explain how to kill the explorer.exe process and relaunch it from an elevated task manager, but in this case there’s no need to do that.

In my opinion this a rather nice workaround. You still have to elevate the Windows Explorer application yourself. The disadvantage is that everything you launch from within that instance is instantly elevated which defeats the purpose of UAC a bit. But then again, this is nothing different from a command prompt you start as an administrator. In both cases administrators should be aware of the risks which launching items from within elevated processes, be it a command prompt or a Windows Explorer instance.

Some additional information: KB2273047 (User Account Control (UAC) and Windows Explorer)
And my UAC settings are those as described in the Enterprise Client security model ( http://technet.microsoft.com/nl-be/bb679962(en-us).aspx –> Table A30. Security Option Setting Recommendations - User Account Control)

Happy elevating,

Thomas.

Today some quick tips regarding FIM:

Usage Keywords

In the portal configuration here and there Usage Keywords have to be configured. They can be used on Navigation Bar Resources and Home Page Configurations. If you use them there you can choose them as you like them. All you have to do is use those same keywords in the appropriate set creation (condition: Usage Keyword contains keywordOfChoice) and then apply MPR’s so users  can see those items on the Portal. In other words these Usage Keywords are used to control permissions.

Search Scopes however also use Usage Keywords, although in a slightly different way: these keywords determine if the Search Scope will appear in the Search within: drop down list for the resource page that the Keyword relates to. Explained in other words: if you want a Search Scope to appear whenever your showing a page which contains set, the correct Usage Keyword will be Set. If on the other hand you create a new object like “Computer”, then your Search Scopes will have to use the Usage Keyword “Computer”. This might be obvious, but it took me a while to figure out.

Search Scope based on the members of a set

If you want a given Search Scope to only return the members of set, you can use the following filter, watch out: filters are case sensitive. I used the ObjectID of the set so it would survive renames.

/Set[ObjectID='511dc29b-efa7-4c9f-9d77-f2f9b1e0480']/ComputedMember

Modification in portal fails, but is actually executed

Sometimes when configuring creating items in FIM like a Synchronization Rule, an MPR or just a simple Set, after submitting an error is shown. You click the error away, the page refreshes and there is your object… Huh? Is the Portal going nuts? Not at all, it’s just a timeout which might be to edgy, Darryl Russi has a nice post about it: Extending FIM Timeouts and it seems that his advice has been added to the FIM troubleshooting tips section on TechNet (Troubleshooting FIM 2010) as well.

And completely unrelated to FIM:

Since Windows 2008 the network connections, the overview of the network adapters, was put deeper away. Well the Network and Sharing Center came in between to be more precise. If you want to change or verify a network adapter its settings, it’s a lot more easier doing Start – Run – ncpa.cpl.

A colleague of mine pointed me the following facts:

• Windows 2008 RTM does not support Windows 7 as KMS clients
• Windows 2008 RTM + SP2 + KB968912 does support Windows 7 as KMS clients
• Windows 2008 (in any version) does not support Office 2010 KMS clients
• Windows 2003 does support Office 2010 KMS client (with the Microsoft Office 2010 KMS Host License Pack)
• Windows 2008 R2 supports both (probably the Microsoft Office 2010 KMS Host License Pack is required as well)

So there are two options: Windows 2003 based KMS or Windows 2008 R2 based KMS.

Reference: Microsoft Volume Licensing: Product Activation

It seems like there is some graphical tool to manage or check KMS statistics: “Volume Activation Management Tool (VAMT) 2.0”, I’ll definitely try this one out if I find some time.

A screenshot from VAMT from the Manage Activation Using VAMT 2.0_White Paper 

[update 9/06/2010] The following URL is a reference for KMS related stuff: Volume Activation Deployment Guide

Another requirement for ADMT to start migrating SIDhistory is the “Audit Account Management” setting on both source and target domain DCs. This should be set to both success and failure. When the domain still has Windows 2003 domain controllers, then this is as easy as setting the following setting in the domain controllers GPO:

However when dealing with Windows 2008 (or 2008 R2) domain controllers, the new fine-grained auditing settings come in play. Setting the above might have no effect. See how the setting is managed by GPO, but the setting says “no auditing”:

The reason for this is the “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” (wow what a setting) which is enabled.

When this setting is active, we have to configure the auditing configuration through auditpol.exe (a built-in command line utility). Try using “auditpol /get/ category:*” to find out the current settings. Or use “auditpol /set /category:”Account Management” /success:enable /failure:enable”. In the end the Account Management category should look like:

Remember: the auditpol commands have to be executed on each domain controller! If you have the MS Enterprise Client model implemented, as referenced in my previous blog entry, you will have to edit the template auditing settings files in the sysvol folder which come with the EC accelerator.

A nice place to start when considering ADMT is the ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains The above requirement comes from this guide.

When users and groups are migrated using the Active Directory Migration Tool (ADMT), there is an option to copy the SID’s of the objects in the source domain to the target domain. The reason for this is to allow migrated users to access resources which are still located in the source domain, and hence are secured with SID’s of the source domain.

By default a trust doesn’t allows users to access resources by using SID’s from their SID history. This is security feature. When creating a trust the following message is shown:

SIDhistory can be temporarily enabled until all resources are migrated from the source domain. SID history should be enabled on the outgoing trust of the trusting domain. The following example will explain the roles of the domains in the commands:

• Source domain
  • contains the user & group objects before migration
  • contains the resources to be accessible during the migration
  • is called the “trusting” domain
• Target domain
  • contains the user & group objects after they are migrated
  • is called the “trusted” domain

Which command to use depends on the type of the trust:

• External trust: netdom trust trustingDomain /domain:trustedDomain /quarantine:no
• Forest trust: netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes

It might seem contradictory that one command requires yes and the other no, but in fact these both enable the use of SIDhistory across the trust. If you want to determine the current state, simply execute the command without the “:no” or “:yes” behind them. An example:

Depending from which side of the trust you launch this command, you might have to specify additional credentials, you can specify (optional) credentials for both the trusting and the trusted domain. The commandline options for netdom trust are explained at TechNet.

Today I received “access is denied” both at trying to enable SIDhistory or simply trying to determine the current setting.

The reason? "Network access: Allow anonymous SID/Name translation" has to be enabled on the domain controllers. This settings can be found in the domain controllers GPO’s (either the default or your custom ones) at "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options". On a Windows 2003 domain this is not disabled by default, but in my Windows 2008 R2 target domain, the Microsoft Enterprise Client security model is implemented and this disables the anonymous SID/Name translation. if you want additional information about this setting, check KB823659

I think it might actually be necessary to enable this when configuring or reading the current setting concerning the SIDhistory. I don’t think this has to be enabled for SIDhistory to actually work. If it does, I’ll post an update in the following weeks.

My source: sid-filtering access is denied

In the end all is fine:

I do not like it when a newly installed environment has event log entries with other than informational events, especially if these warnings are recurring. But I guess this one is an example which can be safely ignored. By design the KDC service periodically tries to locate a Certificate Authority to request a certificate. When no CA is present, warnings are logged.

The event: event id 29, source: Microsoft-Windows-Kerberos-Key-Distribution-Center

The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons, or the KDC certificate could not be verified. Smart card logon may not function correctly if this problem is not resolved. To correct this problem, either verify the existing KDC certificate using certutil.exe or enroll for a new KDC certificate.

Additional information KB967623

In the past year I’ve become more and more interested and familiar with Kerberos authentication. While I’m not saying that you should “Kerberize” everything, I think everyone installing and configuring apps on the Windows platform should have a basic understanding of it.

Below is a decision-based workflow I created to counter some simple pitfalls. Although some of it might seem easy, it gets forgotten a lot. In the example a user is browsing a web-based application which is reachable at “webapp.contoso.com”. In fact this website is hosted on a server called web01.contoso.com.

Important to note that ending up in the orange field (“client uses NTLM”) isn’t necessarily bad, but it might be when your web app does some form of delegation afterwards. On the other hand, if you end up in the “authentication impossible”, you will never-ever get granted access to the application.

This example is based on a web-based application, but the reasoning is exactly the same when the IE browser is a SQL client and the application pool for the website is a SQL Server service.

Perhaps the most common one to be encountered is the one where someone uses a service account for an application pool instead of the network service. If you then try to access the website with the name of the machine, you will always end up in the “authentication impossible”.

Any feedback or comments is highly appreciated. The chart, click the picture for a clearer view:

Since Windows 2008 there is a new well-known security principal called “Owner Rights”. In the past there were some scenario’s in a delegation situation which could be hard to solve. The following example is specific to Active Directory, but the same principle goes for file permissions.

One problem was the delegation of creating objects without being able to delete them. As the creator is also the owner of the object, he is able to alter the permissions of the object. Another was the situation in which someone gets removed from the groups granting permissions. Because that person originally created the objects and is in fact still listed as owner, he still can also change permissions. In both cases the original creator of the object is capable of granting him or herself full permissions on the objects. Below an example.

The following command allows the group “DL_GroupAdmins” to create groups in the groups OU.

• dsacls "ou=groups,ou=corp,dc=home,dc=local" /I:T /G "home\DL_GroupAdmins":CC;group

After creating a DL_Test group as a member of DL_GroupAdmins, we can clearly see our permissions are very limited (create group objects) and our user “deleg” is listed as owner:

Because our user is listed as owner of the group, he can change permissions to grant himself full control on the object. On the left is a picture showing he can control security, on the right is a screenshot of the general tab after giving himself full control.

And this is where “owner rights” comes in handy. Because the owner can always change permissions, we will redefine what an owner of an object can do. With the following command we will ensure owners of objects will only have generic read permissions.

• dsacls "ou=groups,ou=corp,dc=home,dc=local" /I:T /G "Owner Rights":GR

In my opinion a must: it is really easy to implement and it ensures permissions aren’t being tampered with.

Mostly when I have issues logging on to a server, it's due to DNS problems. Sometimes the secure channel is messed up, but the last time it was actually quit simple: there was no SPN for the server in Active Directory.

The error: "The security database on the server does not have a computer account for this workstation trust relationship."

• Run scripts under "local system"
• Use the following workaround: remkoweijnen blogpost
• Insert a sleep inside the HP RDP job. This is the part where you configure which script will be executed. This is the content who gets copied to a file called rxscript.bat and thus executed. Note: for the sleepcommand: download the Windows 2003 resource kit tools.