Hi Rob here again. Periodically we’re asked "what is the best way to auto-create home, roaming profile, and folder redirection folders instead of Administrators creating and configuring the NTFS permissions manually?" The techniques in this post requires you to use the environment variable %USERNAME% in the user’s home folder attribute when you create the users account.

We will also make use of the “$” symbol in the share name; which makes the share hidden from anyone who attempts to list the shares on the file server via computer browsing.

Alright let’s get started.

Home directory:

Home folders are created automatically when the user’s account is created and an administrator has enabled the use of home folders. You change the home folders for the user afterwards, but we are all about making the Admin’s life easier.

Create the folder and enable sharing

As you can see we create the share name and added a dollar sign ($) to the end.

Next, we’ll configure the share permissions. It is important to note that there is a difference in the default permissions for a share between Windows NT/Windows 2000 and Windows Server 2003. By default, Windows 2000 gives the Everyone group Full Control permissions. Windows Server 2003 gives the Everyone group Read permissions. However, we’ll change this to:

Administrators: Full Control System: Full Control Authenticated Users: Full Control

If you expect or want users to be able to select their home directory to be available while they are not connected to the network (also known as Offline Files), then you’ll want to make sure you turn on Offline file caching of the HOME$ share. You do this by:

1. Click Offline Settings on Windows 2000 or Caching on Windows Server 2003 or later, which is located on the Sharing tab. 2. Click Only the files and programs that users specify will be available offline. If you would like more information on the different options and what they mean you can click here. 3. Then click OK.

NOTE: You should consider configuring Offline Files settings even if you do not want users to work with files while they are not connected to the network—you’ll want to disable Offline Files by clicking Files or programs from the share will not be available offline.

Configuring NTFS Permissions

Now we need to configure the NTFS permissions, so we need to be on the “Security” tab of the folder we created earlier.

1. Turn off inheritance on the folder and copy the permissions. You do this by:

a. Click the Advanced button found on the Security tab. b. Clear Allow inheritable permissions to propagate to this object check box in the Advanced Security Settings dialog box. c. Click Copy when prompted by the Security dialog box.

2. Click OK to return to the Security tab. Ensure we have the following permissions set:

Administrators: Full Control System: Full Control Creator Owner: Full Control Authenticated Users: Read & Execute, List Folder Contents, Read

3. Change permissions for Authenticated Users so they cannot access other users’ folders. You do this by:

a. Click Advanced on the Security tab. b. Click Authenticated Users, and then click Edit. c. On the Permissions Entry for HOME dialog box, drop down the Apply onto and select This folder only. d. Click OK twice.

Here is a screen shot of this step:

We now have the permissions configured properly. Next, let’s create a user and specify the home folder location. This is done by going to the Profile tab of the user account in Active Directory Users and Computers. In the following screen shot shows an example of a drive mapping.

Yep, the TOM folder got created without a problem:

When we look at the permissions of the TOM folder we see the following:

We see that only Administrators, System, Tom, and Creator Owner have permissions to the folder. Other users do not.

Roaming Profile:Configuring roaming profiles uses the same procedure as the home folder share, except for one difference. You should disable Offline Files and you should always hide the profile share using a dollar sign ($).

Since the setup is pretty much exactly the same (except for the share name) so I’m not going to bore you with the same steps as earlier.

The main difference between the roaming profile folder and the home folder is that the roaming profile folder is not created until the user logs on and then logs off. Windows creates the profile directory and copies the profile to the share once the user has completed one successful logon and logoff.

You configure the profile location on the Profile or Terminal Services Profile tab within Active Directory Users and Computers. Type a UNC path to where Windows should create the user profile. The following screen shot gives you an example a user account configured with a profile path.

Folder Redirection:For the most part the share and NTFS permissions are the same as the Home folder configuration except we need to replace Authenticated Users with the Everyone group. This is required for Windows to automatically create the redirected folders. These two KB articles provide more information:

Create the folder and enable sharing

So, we need to create a folder on a file server and enable it for sharing, again I would recommend that you hide the share using the dollar sign ($) at the end of the share name.

If you expect or want users to be able to select their home directory to be available while they are not connected to the network (also known as Offline Files), then you’ll want to make sure you turn on Offline file caching of the HOME$ share. You do this by:

1. Click Offline Settings on Windows 2000 or Caching on Windows Server 2003 or later, which is located on the Sharing tab. 2. Click Only the files and programs that users specify will be available offline. If you would like more information on the different options and what they mean you can click here. 3. Then click OK.

We will also need to set the following permissions for the share:

Administrators: Full Control System: Full Control Everyone: Full Control

Configuring NTFS Permissions

We need to configure NTFS permissions for the newly created folder. You’ll want to remove inheritance from this folder, as we did when configuring home folders.

1. Turn off inheritance on the folder and copy the permissions. You do this by:

a. Click the Advanced button found on the Security tab. b. Clear Allow inheritable permissions to propagate to this object check box in the Advanced Security Settings dialog box. c. Click Copy when prompted by the Security dialog box.

2. Click OK to return to the Security tab. Ensure we have the following permissions set:

Administrators: Full Control System: Full Control Creator Owner: Full Control Everyone: Read & Execute, List Folder Contents, Read

3. Now we need change the permissions a bit for “Everyone” so that they do not have any permission to other users’ folders. This is done by doing the following:

a. Use the Group Policy Management Console (GPMC) and edit the GPO containing the Folder Redirection settings you want modified. Configure each from the following list to use the Basic – Redirect everyone’s folder to the same location Folder Redirection setting. Type the UNC path listed in the table into the Root Path setting for each folder listed in the following table.

Redirected Folder

UNC Path

Application Data

\\contoso-rt-mem1\FldrRedir$

Desktop

\\contoso-rt-mem1\FldrRedir$

My Documents

\\contoso-rt-mem1\FldrRedir$

Start Menu

\\contoso-rt-mem1\FldrRedir$

Here is a screen shot of Application Data being redirected:

You can see that Windows shows you the entire path used for the Folder Redirection. So although we didn’t specify the user’s name in the Root Path, the redirection example shows the folder path as: \\contoso-rt-mem1\FldrRedir$\Clair\Application Data

b. By default, Administrators do not have permissions to users’ redirected folders. If you require the ability to go into the users folders you will want to go to the “Settings” Tab, and uncheck: "Grant the user exclusive rights to" on each folder that is redirected. This allows Administrators to enter the users redirected folder locations without taking ownership of the folder and files.

When you’re all done, you can kick back and enjoy the easy life of being an administrator. Now when you create the user and define the home path it will create the user’s home folder immediately. When Group Policy applies Folder Redirection; folders are created automatically. And, when the user logs off their roaming profile folders will be created after the first logon.

This last part is for the former Novell Admins out there. Yes, you could use Access Based Enumeration (ABE) on these new shares; however if there is going to a lot of user folders on any one of these shares you could experience degradation of performance. Enabling ABE on a share does come at a price of performance. If you are still all hyped up to enable this feature please read ABE whitepaper available information so that you make an informed decision.

James Carr here and I would like to discuss creating custom certificate request in Windows Vista. When requesting certificates from a Windows 2000/2003 Enterprise Certification Authority, we will use one of the built-in certificate templates. Certificate Templates are used to tell the CA what information should be included in the issued certificate. For more information about certificate templates, please see the following:

Although certificate templates are very useful in typical enrollment scenarios, they are not very useful in situations where we have one time enrollment needs or we need to submit certificates to non-windows CA's. In these scenarios we can use a utility called Certreq to generate the request, submit the request, and then retrieve the issued certificate. To generate a certificate request, we must use a template file (note: this is not the same as Certificate Templates discussed above, which are stored in Active Directory). Typically this template file will have an .inf extension. It will include the same information as an Active Directory certificate template but the big difference is the formatting.

Prior to Windows Vista, we didn’t have an easy way to create the template. We basically had to create the template file and then troubleshoot the syntax errors that were generated. However, now we can use the Certificate Enrollment Wizard MMC in Windows Vista to generate the request file. The wizard automates the process of creating the template file and then creating the actual certificate request. We can then submit the request file to a third-party CA or use the Certreq utility to submit the request to a Microsoft CA. Today, I want to cover the steps of generating a certificate request using the “Custom Certificate Request” wizard.

So, let’s get down to business:

1. Bring up Certificate Manager by selecting the “Start” button and in the “Start Search” window type “Certmgr.msc” without the quotes.

4. On the “Custom request” we have some options that we can configure:

Template – Under template we have the following options.

(No template) CNG Key – Cryptography Next Generation is the long term replacement for CryptoAPI. One of the most exciting features of CNG is that it allows developers to use their own cryptographic algorithms or implementations of standard cryptographic algorithms. So as not to put anyone to sleep, I won’t cover this topic right now. However, for more information on CNG, take a look at the following white paper:

(No template) Legacy key – Allows for the complete customization of a certificate request. This will be covered later in the blog.

Built-In Certificate Template – Each template includes a standard set of extensions that indicate additional subject identification information and/or additional key usage information. I.e. what the key can be used for such as signature or encryption.

Suppress default extensions (Checkbox) - This setting allows for the suppression of these extensions so that we can specify only our custom extensions.

Request Format – A certificate request consists of a distinguished name, a public key, and optionally a set of additional attributes.

PKCS #10 – The most widely used format for certificate request.

CMC - Typically used for non-Microsoft CAs. However, it must be used when specifying Key Archival.

For our purposes we will select “(No template) Legacy key” for “Template” and “CMC” for “Request Format”. Then select “Next”.

5. On the “Certificate Information” page, we need to select the “Details” drop-down arrow and then the “Properties” button.

6. Selecting the “Properties” button will bring up the “Certificate Properties” tab page. We will be configuring a “Client Authentication” certificate. I will provide a brief overview of the purpose of each option.

General

Friendly Name – A name that refers to the certificate.

Description – A brief description of the certificate purpose or other relevant information.

Subject – The holder of the private key of a certificate is referred to as the subject. This can be a user, computer, service, or device. Subject names can be presented in the following formats:

Common Name (CN) – Can refer to the full name of the subject i.e. “CN = John Smith”. Typically we don’t specify just the CN for Active Directory authentication. Whereas the CN has to be unique on a per domain basis, it may not be unique in the enterprise.

Full DN - This refers to the user’s full distinguish name. I.e. “CN=John Smith,CN=Users,DC=<Domain>,DC=Com”. Whereas the CN may not be unique in the enterprise, the FQDN is always unique.

Email – The email name can be used in place of the CN or FQDN or as part of either as the subject name. The email name would be in the format of johnsmith@domain.com.

None – A subject name may not be required in all circumstances. A subject alternate name (SAN) can be used instead.

Alternate Name – The subject alternate name is simply a different name by which we can refer to the subject by.

E-mail name – same as above.

DNS name – Refers to the FQDN of the subject that requested the certificate. This is mostly used for computer certificates.

User principal name (UPN) – The user principal name is part of the user’s object in the active directory. The format is the same as the email attribute.

Service principal name (SPN) - Thisis part of the computer’s object in the active directory.

Application Policies – Determine the specific purpose that the certificate can be used for.

Issuance Policies – Define measures that are used to identify the subject of the certificate.

Certificate Subject Type – This is the certificate template information.

Key Usage – Our first extension is Key usage which describes what the certificate can be used for. I.e. encryption, decryption, signing etc. For our purposes, we will select the option “Digital signature” and then the “Add” button.

Note: Check Box: Make these key usages critical – This is an indicator that identifies whether or not the information contained in the extension has to be included in the certificate for it to be valid.

Extended Key Usage (application Policies) – Where as Key Usage determines what the certificate can be used for, Extended Key Usage determines how it can be used. I.e. for Client authentication, server authentication, code signing, etc. For our purposes we will use “Client Authentication” and then select the “Add” button.

Note: Check Box: Make the Extended Key Usages critical – This is an indicator that identifies whether or not the information contained in the extension has to be included in the certificate for it to be valid.

Basic Constraints – Allows a certificate to designate whether the certificate is issued to a CA or to an end entity, i.e. user, computer, devices, etc. Nothing needs to be configured.

Include Symmetric algorithm – Thisoption allows for the inclusion of symmetric algorithms used for encryption. For our purposes, nothing needs to be configured.

Custom extension definition – This allows for the inclusion of custom application policies. The policy can be defined by specifying the object identifiers (OID's). For our purposes, nothing needs to be configured.

TAB: PRIVATE KEY

Cryptographic Service Provider – A CSP is a program which generates and manages certificate key pairs. There are several built in CSP’s with “Microsoft Strong Cryptographic Provider” being the most popular. This is the CSP that we will use for our blog.

Key Options –

Key size –The larger the key size the longer the encryption/decryption process. But the stronger the key protection.

Make private key exportable – We may want the key to be exportable if we’re going to need the certificate on multiple machines. Allow private key to be archived – This option allows for a copy of the end entities private key to be stored on the CA. Strong private key protection – With this option the private key is password protected in the certificate store. Then when access is needed to the private key the user receives a prompt for the password.

For our purposes, set “Key size” to 1024 and select the option “Make private key exportable”.

Key Type – The best way to describe key type is to think in terms of S/MIME. S/MIME provides both a digital signature and encryption services for the delivery of email.

Exchange - Refers to how encryption keys are exchanged. With S/MIME the sender encrypts email with the recipient’s public key and the recipient decrypts the message with their private key.

Signature – Refers to proving the identity of the sender. The message itself is not encrypted, however, if the message is tampered with while in transit, it invalidates the signature.

For our purposes we need to prove our identity to a remote server so we will use “Signature”.

TAB: SIGNATURE

Registration Authority – The RA is used to sign all certificate requests prior to them being submitted to a CA. This is used when requesting certificates on behalf of another entity. For now we will leave this setting as not configured and then select “Ok”.

This brings us back to the “Certificate Enrollment” page where we can now select “Next”.

7. On the “Where do you want to save the offline request?” page, set “File Name” to “C:\Temp\Request.req” and “File Format” to “Base 64” and then select “Finish”.

Binary – DER (Distinguished Encoding Rules) for ASN.1, as defined in ITU-T Recommendation X.509, might be used by certification authorities that are not on computers running Windows Server 2003, so it is supported for interoperability. DER certificate files use the .cer extension. (RFC 2511 - Internet X.509 Certificate Request Message Format)

To see the contents of the certificate we can go to the “Certificate Enrollment Requests” container:

We can bring up the request by double-clicking on it:

The error message under “Certificate Information” is expected since at this point the certificate is a self-signed certificate and is not included in the “Trusted Root Certification Authorities Store”. The error will go away once we have issued the certificate and verified that the issuer of the certificate has been placed in appropriate store i.e., “Trusted Root Certification Authorities” if the issuer is a root CA or “Intermediate Certification Authorities” if the issuer is a subordinate.

Lastly, we can go to the “Details” tab to verify the Subject Name:

We will also want to verify the “Subject Alternate Name”:

Finally “Enhanced Key Usage”:

Issuing the Certificate

Now that we have the request file, we can submit the certificate to a Certification Authority (CA). For our purposes we will submit the certificate to a Microsoft CA. However, this can be submitted to any third party CA. For our purposes, we can run Certreq, to submit the request. The commands are as follows.

The cool thing about submitting the request in this way is that we can select the CA that we would like to use. After hitting “Enter” we will see the following dialog:

Select the CA and then select OK. We will then get our issued certificate. The output will look as follows:

Now that we have our certificate, we will need to add the certificate to the appropriate store. A common mistake is to simply import the certificate into the personal store via the MMC. However, this will not re-associate the key pair. Remember that the private key was created when we submitted the certificate request to the CA. Now for the certificate to be valid, we associate the public/private key pair. We can do this by running the following command:

Please note that for a user certificate we use “–User” for a machine we will use “-Machine”.

At this point the certificate has been added to the store. We can confirm this by running the following command:

So as you can see, this is much easier than the old way, where we had to manually build a .inf file and then use Certreq to generate the certificate request. Not only does Vista make this process much easier but it’s also gives administrators complete control on how to customize certificate requests. I hope you’ve enjoyed the blog and please take a look at the links below for some additional information.

Mike here. Windows Vista made numerous changes with how user profiles work. In fact, the changes are too numerous to describe here (you can read more about the changes with user profiles in the Managing Roaming User Data Deployment Guide(http://go.microsoft.com/fwlink/?LinkId=73435). However, the policy settings for user profiles from earlier versions of Windows remain and Windows Vista introduces five new policy settings.

Four of the five new policy settings for user profiles exist under Computer Configuration\Administrative Templates\System\User Profiles (the remaining policy setting uses the same path under User Configuration). These five policy settings apply only to computers running Windows Server 2008 or Windows Vista, however; these policy settings can co-exist in GPO's applicable to clients earlier than Windows Vista. Operating systems other than Windows Vista ignore the policy settings. Let me begin with the policy settings under the computer configuration and then close with the single user setting.

The first of these policy settings is Delete user profiles older that a specified number of days on system restart. This policy setting accepts a numeric value, represented in number of days. Windows uses this value to determine the how long it retains dormant user profiles. When you enable this policy, Windows deletes all user profiles older than the value provided. This policy setting measures one day as 24 hours since the last time Windows loaded the profile.

NOTE: Microsoft released a hotfix to correct problems specific to this policy setting. You can view more about the issue and related fix from Microsoft Knowledgebase article 945122 (http://support.microsoft.com/?kbid=945122).

Sometimes, in earlier versions of Windows, the registry portion of the user profile fails to unload. Many times this failure prevents the user from subsequent logons to the same computer. Windows Server 2008 and Windows Vista always unload the registry portion of the user profile, even if it must forcefully do so. The policy setting Do not forcefully unload the user registry at user logoff counters the default behavior of Windows Vista. When enabled, Windows Vista does not forcefully unload the registry and waits until no other processes are using the user registry before it unloads it.

The policy setting Set roaming user profile path for all users logging onto this computer provides you a way to create a shared user profile path for a specific computer. When you enable this policy, all users use the profile path specific in the policy when logging onto a computer receiving the policy. There is a small catch-there is an order of precedence. Windows reads profile configurations in the following order and uses the first configured setting.

For example, if you configure the Terminal Services roaming profile path using the Terminal Services policy settings and, you also configure the per-computer roaming user profile policy setting, then Windows uses the roaming profile path from the Terminal Services policy. This result is due to the order in which Windows reads the roaming user profile path.

The last policy setting for user profiles under the Computer configuration is the Set maximum wait time for the network if a user has a roaming user profile or remote home folder. At logon, Windows Vista typically waits 30 seconds for an active network connection, when you configure the user with a roaming user profile or remote home directory. In cases such as wireless, VPN, or NAP-protected networks, it may take more time before the network connection becomes active. When enabled, Windows waits up to the number of seconds specified in the policy setting for an active network connection. Windows immediately proceeds with logging on the user as soon as the network connection is active or the wait time exceeds the value specified in the policy setting. Windows does not synchronize roaming user profile or use the remote home folder if the logon occurred before the network connection became active.

One policy setting for user profile exists under the User Configuration category. Actually, it is more of an Offline Files/ Folder Redirection policy setting. Windows Vista automatically marks all redirected folders as available offline. Windows Vista keeps track of all folders marked offline and synchronizes the contents of these folders between the local computer and the network location where you store the files. This synchronization process occurs at logon, periodically throughout the user session, and at logoff. You configure the policy setting by entering network paths that you only want synchronized during logon and logoff. Windows then places these specified network paths offline during the user session.

Windows Server 2008 and Windows Vista Service Pack 1 provide several new Group Policy settings that affect User Profiles. Many of these new policies settings help overcome profile limitations with earlier versions of the operating system. Be sure to evaluate these settings to see how can help with your environment.

Hi, Steve here. Kerberos Double Hop is a term used to describe our method of maintaining the client's Kerberos authentication credentials over two or more connections. In this fashion we can retain the user’s credentials and act on behalf of the user in further connections to other servers.

The Kerberos TGT is the user’s identity. When we pass this ticket along with the service ticket we can re-use the KrbTGT to request other service tickets to speak with our service resources on our network.

There are requirements for a service to be able to perform Kerberos double hop. The service account needs to be trusted for delegation. Meaning it must be trusted to act upon another user’s behalf. Source and target servers must be in the same forest or there must be a forest level trust between forests and the first level service account must be in the trusted forest root.

Specific Example:

Client is running IE7 and connecting to a web server that is using windows authentication. The client machine needs to be a member of the forest or a trusted forest and IE needs to be enabled for integrated windows authentication.

Web server machine name WEB1.mydomain.com and is using a service account, mydomain\webadmin. The webadmin account has SPN registered for both HTTP/WEB1 and HTTP/WEB1.mydomain.com. The webadmin account is enabled for constrained delegation to MSSQLSVC/SQL1.mydomain.com.

The SQL server machine name is SQL1.mydomain.com and is service account for SQL is mydomain\sqladmin. The sqladmin account has SPN’s registered for MSSQLSVC/SQL1.mydomain.com.

In the example configuration above the client is connecting to http://web1 to get access to data that is stored on a backend SQL server named SQL1. The web page hosts the code that retrieves the data from SQL. The user account is used to authenticate to the web server. The web server uses its constrained delegation ability to request a Kerberos ticket on the user’s behalf for connection to SQL1. If we were to audit the connections we would see the users account is being used to access the web page and the data on the SQL server. This is a classic example of Kerberos double hop but we could easily expand the scenario to include more hops. We could theoretically keep expanding the example as long as we enable delegation and retain the correct service principal name registrations.

Constrained vs. General Delegation:

General delegation will allow the first hop server to request Kerberos tickets on the client behalf to any other resource in the forest.

Constrained delegation is not supported by all Kerberos aware applications. The domain functional level must be 2003. It allows the administrator to selectively allow an account to request Kerberos tickets limited to specific services on specific servers. This is a much more secure method of delegating Kerberos delegation. The service accounts and the computer accounts hosting the applications need to be in the same domain. If the service account is a user account the delegation tab maybe missing. Until the account has a service principal name registered for it there will not be a delegation tab and you will not be able to setup constrained delegation.

Protocol Transition:

So far we have assumed the client is using Kerberos. Common scenarios where Kerberos is not used are when the client does not support Kerberos. In these examples the initial authentication to Server 1 can be transitioned into a Kerberos request in order to maintain the client’s credentials when connecting to Server 2.

Troubleshooting and Common Problems:

Setspn.exe will help confirm the service accounts have the proper service principal name registered correctly.

At each stage one of the members requests and receives a Kerberos ticket. These tickets are cached on the client and the front end servers. We can use Klist.exe or Kerbtray.exe to examine our cache. Frequently when there are configuration problems the client will be prompted for credentials and this may mean NTLM is being used instead of Kerberos. NTLM credentials cannot be delegated off the system so authentication to the backup server will be in the form of anonymous authentication.

We can increase Kerberos event logging (KB262177) When kerberos authentication is failing and we have increased the logging level we should see indicators in the system event log for kerberos errors.

A packet capture utility may also be useful in recording the Kerberos requests and responses. Make sure to clear the client cache before enable a utility like Network Monitor. You could filter on Kerberos, use care that Kerberos requests may use the default UDP port 88 or fail over to TCP port 88.

We are still using the same setup as part 1 with all the same computer account names. So we will not go over the setup or cover how to take proper network traces. We will not go into much detail on most of the network trace data since this has already been covered.

When they type in the user name of “FABRIKAM\Administrator” and the password, they again get prompted for user name and password.

After the 3rd attempt to enter in the credentials and we see the below:

If you have Kerberos Event logging enabled (KB262177) we see the following event listed here.

So, we now know that the error we are getting back from the Kerberos Authentication attempt is KRB_AP_ERR_MODIFIED (some network analysis tools show this as KRB5KRB_AP_ERR_MODIFIED). Basically this is stating that the Account that is running the service (in this case the IIS Web Application Pool account) could not decrypt the Kerberos ticket that the KDC gave to the client. This can happen for several reasons, but the most common are listed below:

There is an account with the same SPN within the forest (Keep in mind in a multi-domain forest you need to search all domains to include other domain trees in the forest). As shown in the previous blog posting the KDC will give an error back of KRB_S_PRINCIPAL_UNKNOWN, but there are instances where it will give a Kerberos ticket that the service cannot decrypt and thus get a KRB5KRB_AP_ERR_MODIFIED.

The Service Principal Name is on the wrong Active Directory account (Computer or User).

The Active Directory account that is running the service has updated / changed its password and you are experiencing the problem because of an Active Directory Replication Latency or Active Directory Replication problem.

So now let’s look at the network trace of this attempt.

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP Address of 10.10.200.105 (frames 3 & 4)

2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 7 -14).

3. The machine then gets a TGT from the domain controller (see the AS-REQ and AS-REP) (frames 15 & 16)

4. The machine then requests and gets a Service Ticket for http/webapp.fabrikam.com (frames 17 & 18). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

5. The machine then goes back to the web server and attempts to authenticate to the http://webapp.fabrikam.com/webapp site using the Kerberos ticket that it just got from the domain controller (frames 19-22). During the authentication the web server responds back with KRB5KRB_AP_ERR_MODIFIED (frames 23-24).

6. The machine then attempts to get a service ticket (TGS-REQ / TGS_REP) from the domain controller two more times in the trace, but each time the web server reports the same error of KRB5KRB_AP_ERR_MODIFIED (frames 15-18, 25-26, 34-37). The reason why you are seeing three different TGS-REQ / TGS_REP) requests to the domain controller is because you were prompted three times for user name and password when attempting to access the site before you got the 401.1 unauthorized error from the web server.

We need to do more investigation when you get the KRB5KRB_AP_ERR_MODIFIED. Keep in mind that this error really just means that the Service you are attempting to connect to could not decrypt the Kerberos ticket using its password Hash.

The first thing that we will test is to see if the Service Principal Name is registered to the correct account. If you remember from the previous blog the Web Application pool account that is running the website is Fabrikam\KerbSvc, as shown below:

So we will use the QuerySPN.vbs script again to find out what account(s) have the http/webapp or http/webapp.fabrikam.com SPN defined. Review KB321044 if these tools are new to you.

As you can see the SPN is on the Web Server computer account. Well, this will just not work; we will need to take it off of this account and add it to the FABRIKAM\KerbSvc account using SetSPN.

Now we see that we are able to access the website, and authenticating to the website using Kerberos Authentication.

NOTE: If we would have found that there were no duplicate SPN’s and that the only SPN registered in the Active Directory forest was correct we would have looked into a possible Active Directory Replication problem that might be causing the issue. You might be asking how could AD replication be causing the issue?

Let’s think about that. When a user, or Service Account, or computer password gets changed one domain controller in the environment accepts the password change. Through normal AD replication all domain controllers in the domain get the updated password. If you remember the Kerberos service ticket (the TGS) is encrypted with the service’s password hash. When the service decrypts the ticket it is going to use its current password hash to decrypt the ticket. So if the Kerberos service ticket was generated by a KDC (Domain Controller) that has not received the latest password for the service account then it will encrypt the ticket with the wrong password hash and thus the service will not be able to decrypt the ticket; you then get the KRB5KRB_AP_ERR_MODIFIED message.

Well, this is the last blog for Service Principal Name problems. I hope that you have enjoyed learning how to troubleshoot Kerberos authentication using network trace analysis to help find the cause of the failures.

Rob here. So, we saw in Part 1 what kind of error you could expect when there is no Service Principal Name defined for the Kerberos ticket the application is requesting. The next part I would like to show you is what might be the error message you would get if there were multiple accounts with the same SPN defined on them.

We are not going to cover the basics of how to capture a network trace and how to review it this time so this part should be fairly quick. We are going to be using the same configuration as the previous blog post.

Again, we notice that the website shows that we are authenticating with NTLM and the web server’s auditing log also shows that we authenticated using NTLM.

Now when we look at the network trace, we see the following:

1. We see proper name resolution, for webapp.fabrikam.com and the DNS server response back with the IP address of 10.10.200.105 (frames 11 & 12)

2. The machine then makes an http connection to the web server, and gets “401 Unauthorized” (frames 18 -21). Note, I am showing you in the detail pane that the web server responded back with “WWW-Authenticate: Negotiate” and “WWW-Authenticate: NTLM” to let you see that the web server is configured properly to support Kerberos Authentication.

3. The machine then goes to the domain controller and gets its TGT (see the AS-REQ and AS-REP frames 23 & 24) then it does a TGS-REQ request but the domain controller responds back again with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (frames 25 & 26). As you can see below, the machine was asking for a Kerberos ticket of HTTP/webapp.fabrikam.com.

If you read the previous blog posting, your first thought might be to just add the Service Principal Name to the KerbSvc account and call it a day. If you did this, you would be wrong! If we look at the domain controllers System Event log we will see this really nice Event log entry.

This event log basically is stating that there are multiple computer or user accounts that have a Service Principal Name of HTTP/webapp.fabrikam.com within the Active Directory Forest. You can use LDP, LDIFDE or QuerySPN.vbs to find where the SPN's are registered. When you use these tools to search for duplicate SPN’s you should always start at the forest root and target a global catalog server. I prefer to use the queryspn.vbs and use wildcards in my statement. Review KB321044 if these tools are new to you. Just because the event shows that the FQDN is duplicated, you might be surprised by a duplicate SPN of the NetBIOS name HTTP/webapp too.

As you can see from this output, the account FAB-RT-MEM1 (Computer Account) and the account “Kerberos Service” (User Account) both have “http/webapp” and “http/webapp.fabrikam.com” assigned to them. No wonder the domain controller reported the KDC 11 event.

The resolution to this issue is fairly simple. If you remember from the previous blog, the web application is running in a Web Application Pool that is running under the context of the KerbSvc account. So in this instance we would want to use SetSPN to delete the HTTP SPN's from the computer account FAB-RT-MEM1.

Now, when we test the application, we can see that Kerberos authentication is used to access the website.

I am not going to show the network traces of it working again. If you would like to review what a working trace looks like please review Part 1.

Summary

In support we see duplicate Service Principal Name issues quite frequently. Usually this is when the Administrator has used the SetSPN on different accounts in an effort to get Kerberos Authentication to work. One great example of this is MS SQL. If you install MS SQL as an Administrator of the domain, it will add the MSSQLSVC SPN to the SQL Server’s computer account; later an Administrator changes the SQL Service startup account from Local System to a domain account and Kerberos Authentication starts to fail. Usually we will find that the MSSQLSVC SPN is configured on both the computer account as well as the domain user account that is used to run the service.

I hope that you have learned something new on how to troubleshoot a Kerberos Service Principal Name issue and that you’re starting to feel more comfortable using network traces to determine why Kerberos Authentication might be failing. Stay tuned for Part 3 where we will cover some more ways in which Kerberos Authentication can fail when Service Principal Names are not correctly configured.

Windows Server 2008 Core introduces some challenges in administering servers without an explorer shell. Here are some netsh commands that will help you administer your Server Core installation remotely through MMC snap-ins.

AllowingAdministration of Server Core from a Remote MMC

To administer the Server Core installation from a remote MMC you must configure the Windows Firewall.

If you do not configure the firewall to allow remote administration via MMC you will get an error.For example:

When you attempt to connect to a Windows Server 2008 Core installation via Device Manager you may receive the following message:

Unable to access the computer “ComputerName” Make sure that this computer is on the network, has remote administration enabled, and is running the “Plug and Play” and “Remote registry” services.

The error was: Access Denied

When you attempt to connect to a Windows Server 2008 Core installation via Event Viewer you may receive the following message:

When you attempt to connect to a Windows Server 2008 Core installation via Event Viewer you may receive the following message:

Disk Management could not start Virtual Disk Service (DS) on “ComputerName”.This can happen if the remote computer does not support VDS, or if a connection cannot be established because it was blocked by Windows Firewall.

In order to run the Netsh advfirewall commands you must have the correct permissions.

·If you are a member of the Network Operators group you can run the commands from any command prompt.

·If you are not a member of the Local Administrators or Network Operators group and do not have delegated permissions to run the netsh advfirewall command, you can only run the commands that display information.You cannot make any changes to the settings.

Before you can make any changes to the firewall settings remotely you must first enable remote administration of the firewall by typing the following command at a command prompt:

Once the firewall has been configured for remote administration you can began to allow remote management through MMC snap-ins.You can configure the firewall to allow remote management via all MMC snap-ins or you can specify particular MMC snap-ins.

The following command will allow you to remotely manage a Server Core installation through all MMC snap-ins.

Note: You can reference the table below for available rulegroups. Some snap-ins will require more configuration before you can connect to them through a firewall.Also, some MMC snap-ins do not have an associated rule group that allows connections through firewalls.

If you look at the chart above you will see Disk Management and its corresponding rule group.This is one of the MMC snap-ins that will need additional configuration.In order to use this snap-in for remote management you must first start the Virtual Disk Service (VDS) on the computer that is running the Server Core installation.You also have to configure the Disk Management rules on the computer that is running the MMC snap-in. The command to enable the Remote Volume Management Rule group is as follows.

Running this command will enable the Remote Volume Management – Virtual Disk Service Loader (RPC), Remote Volume Management – Virtual Disk Service (RPC), and Remote Volume Management – Virtual Disk Service (RPC-EPMAP) inbound rules.Remember these rules must be enabled on both the server that is running the MMC and the remote Server Core installation.

Summary

You now know some of the commands you can run to enable remote management through MMCs.There are other commands besides netsh that would allow you to enable remote management through MMCs not covered in this blog.Check out the NETSH Technical Reference it has a lot of this information in it, as well as a ton of other netsh commands.You can download it from the link below.