Microsoft's official enterprise support blog for AD DS and more
Designing and Implementing a PKI: Part I Design and Planning
Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation
Designing and Implementing a PKI: Part III Certificate Templates
Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival
Designing and Implementing a PKI: Part V Disaster Recovery
Chris here again. This is part of a five part series. In Part I, I will cover design considerations, and planning for deploying a PKI. When implementing a PKI planning is the most important phase, and you can prevent a lot of issues by properly planning your PKI implementation.
I recommend reading the following MSPress books on PKI and Certificate Services before implementing a Windows PKI, or any PKI for that matter. Both books are written by Brian Komar.
Here is a link to the Windows 2003 Book: http://www.microsoft.com/learning/en/us/Books/6745.aspx
And a link to the Windows 2008 Book: http://www.microsoft.com/learning/en/us/books/9549.aspx
They are both excellent resources for anyone implementing, managing, or designing solution that use a Microsoft PKI. And both books go into far more detail then I can here.
There are a host of reasons to deploy a PKI; a few are listed here:
In addition a number of applications can use certificates in some fashion. Here is a brief list:
Another thing to consider is what future applications you may need to support with your PKI. This may not be an answerable question, nor should you be expected to know for sure. In fact some of the applications or technologies that your PKI may be required to support may not have even been conceived of yet. My point here is that your design should incorporate plenty of flexibility. Not only do you want to deploy a PKI solution that supports existing technologies, but one that is scalable, and can support future technologies.
The next thing you want to think about is cost. I understand how difficult it can be to get budgets approved in any business. Despite our wishes as technology professionals that we could implement the appropriate solutions, sometimes we are handicapped by the budget that we have to complete a project. How much money is your business willing to invest in the PKI solution? What are the costs for implementing a PKI? Here are some items that may need to be included in your budget:
Hardware Costs
Software Costs
Human Capital
Cost Savings
While you are planning your budget, it is important not to forget the cost savings that a Windows PKI solution can provide. The two key areas of savings that I see in a PKI solution are:
Integration
Microsoft CA’s, especially Enterprise CAs, have a tight integration with Microsoft products. The integration makes managing and requesting certificates from Microsoft Operating Systems and applications fairly straight forward, to the point that you do not really need any PKI experience to be able to request a certificate.
Automation
The greatest advantage of the Windows PKI solution is automation. An Enterprise CA is tightly integrated with Active Directory. Using autoenrollment, a simple group policy can be configured to automate the deployment of certificates to computers and users. The deployment is so transparent, that users do not have to do anything to request a certificate.
In designing your PKI solution you will have to take into account the resources you have to manage the PKI solution. Day-to-day management for the most part is very limited, but you will need someone to provide the care and feeding of your PKI. You will need someone to issue and revoke certificates. You will need to have someone manage the hardware, apply patches, take backups. In other words, you need a Server Administrator. Also, you will need to have someone that publishes Certificate Revocation Lists and manages the CA itself.
You will need to determine the level of security required for your PKI. In order to determine the level of security it is important to step back and understand what a Public Key Infrastructure and the certificates associated with the Public Key Infrastructure can be used for. Certificates can be used for identification, encryption, non-repudiation, and in some cases authentication. In your organization you probably have some standard on how a user receives a user account. When hired there was some form indicating that he/she needs a domain user account and the manager approves this form; in other words, the manager was assuring the identity of the user. Since certificates can be used for identification the same standard should be used when issuing certificates, if they are going to be used for that purpose. If you are using certificates just for encryption, you may be less concerned with the user’s identity. If using the keys from the certificate for encryption, it would depend on what data is being decrypted. If a user is just encrypting his/her recipes you may perhaps not require the same level of protection of the private keys as you would if the user is encrypting top secret government documents. In other words the level of security is going to be determined by the level of risk. This determination should include any corporate security policies for PKI and certificates. When creating your PKI security policy, you should also consider any industry or government regulations.
The flexibility and scalability of your solution should be taken into consideration. If you have a high level of confidence that you will not need to change or adapt your PKI solution you can have a fairly simple design. However, if you need a solution that will need to support a variety of technologies, different levels of security, and a global presence, then your solution can get much more complicated.
When designing your PKI solution you will have to determine the hierarchy that you will use. There are generally three types of hierarchies, and they are denoted by the number of tiers.
Single/One Tier Hierarchy
A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility. The level of security can be enhanced if the CA’s keys are protected by an HSM, but at the expense of higher equipment and management costs.
Two Tier Hierarchy
A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical location, as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s. Cost is increased marginally. I say marginally, because all you need is a hard drive and Windows OS license to implement an Offline Root. Install the hard drive, install your OS, build your PKI hierarchy, and then remove the hard drive and store it in a safe. The hard drive can be attached to existing hardware when CRLs need to be re-signed. A virtual machine could be used as the Root CA, although you would still want to store it on a separate hard drive that can be stored in a safe.
Three Tier Hierarchy
Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage. And, of course, cost goes up.
Private Key Protection
One of the key aspects of designing a PKI solution is to make sure the proper controls are in place. Security for a PKI solution mostly revolves around protecting the private key pair of the CA. Each CA has a private/public key pair. The private key is used to sign CRL’s as well as certificates that are issued by the CA. Clients and application verify the signature so that they can be assured that a certificate was issued by a particular CA. If you install a Microsoft CA, the private key is protected by software, or more specifically the Data Protection API (DPAPI). Although this method does provide protection it does not prevent a user that is a member of the Administrators group on the CA from accessing the private key. This can be a cause for concern, because you may have administrators whose job is just to patch the system, and yet they have access to the private key which violates the concept of least privilege.
There are generally two methods for protecting the private key of a CA. The first method is to keep the CA offline and the hard drive stored in a safe. By controlling the conditions the hard drive can be used, the opportunities for key compromise are reduced. The second method is to use a hardware device to protect the private key. For example, a smartcard can be used to store the private key of the CA. This is not the best solution since the smart card must remain in the reader attached to the CA in order to be used. Also, a smart card may not be as resilient, or provide the level of security that is required. It is however a low cost solution. A more standard solution is to use a Hardware Security Module (HSM). HSM’s are fairly expensive, but are normally certified for FIPS compliance -- a standardized measure of relative security. HSM’s are accepted as the most secure way to protect the private key for a CA.
Role Separation
Aside from private key protection you will most likely want to have some control as to the level of administrative access to a CA. In some cases you may have administrators that are responsible for performing every function on the CA. But in larger or higher security environments you will want to have some granular control over what access different role holders have. Below is a list of common roles on a CA:
In addition to these roles that have direct interaction with the CA, you also will have ancillary roles that support the CA. These include:
Physical Security
Certificates issued by CAs are used in many cases for very sensitive operations such as establishment of identity, authentication and encryption. As such, it is important to not only protect the private key but to protect physical access. Law #3 of the Ten Immutable Laws of Security, states: “If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.” For this reason you will want to protect physical access to the CAs. This will depend on the resources you have available, but typically in larger organizations the CAs are stored in a locked cage in a data center. Only individuals that need physical access to the CA to perform their duties should be given access.
Policy
Generally the security requirements, such as those mentioned above, are dictated by a corporate security policy. A security policy usually takes into consideration regulatory and industry requirements as well as unique requirements for the individual company. The policy may also specify technical aspects of the PKI such as the encryption algorithms that must be used as well as operation of the Certificate Authorities.
In addition to security policies there may be CA-specific policies that need to be developed before implementing the PKI. These include Certificate Policy and Certification Practice Statement. The Certificate Policy explains what methods are used to establish the identity of a subject before issuing a certificate. A Certification Practice Statement outlines the operation of the PKI from a security perspective. Many companies, especially third parties companies that issue certificates, have their Certificate Policies and Certification Practice Statements available publicly. It may be helpful to view one of these public documents when writing your own policy documents.
Additional Security Considerations
In addition to the topics discussed it is important to apply any relevant security patches to your online CAs and to install them in a timely manner. In addition to patches, you should have an anti-malware solution installed on your CA.
So far we have covered reasons to deploy a Public Key Infrastructure. We also have covered the various costs involved in a PKI infrastructure, as well as the impact of various design considerations. Now we will dive a little deeper into specific configuration decisions and technical aspects of the Certificate Authorities.
Certificate Validity Period
Digital certificates have a lifetime, a start date and an end date for which they are considered valid. You should determine what values for this lifetime are appropriate for each CA certificate and end-entity certificate issued by your CA’s. For CA’s, this lifetime is set when the CA is installed and when the private key is renewed. For end-entity certificates there are a number of factors taken into account:
The certificate issued will be configured with the validity period that is the shortest of these items.
Key Length
The length of a key definitely affects security of information protected with that key. Thus, you will need to determine the key lengths you will use with each key pair. First you will need to determine the key lengths that will be used for each of the CA key pairs. Additionally, you will need to determine the key lengths for any certificates issued by the issuing CA. The key lengths for the CA certificates are determined by the key size requested when the CA is installed and when the key pair is renewed. The key length at installation is set during the CA Setup process. The key length for renewal is determined by a value set in the CAPolicy.inf configuration file installed on the CA.
For certificates issued by the issuing CA the maximum key size is limited by the CSP that is being used. The specific key size that is required can be specified in the certificate request or in the Certificate Template if using an Enterprise CA. As a general guideline, the longer the lifetime of the certificate the longer the key length should be. For applications that will be using certificates you will need to determine the maximum key length they support. Some applications have limitation on the key size not only in the actual certificate it is using, but also for any certificates in the CA hierarchy. From a security standpoint it is recommend that 4096 bit key is used for Certification Authorities key pair. However, if you wanted to insure maximum compatibility with network devices and applications a 2048 bit key would be the better choice.
AIA Locations
When a client or application is validating a certificate it needs to not only validate the certificate that is being used but also the entire chain of the certificate. In other words, the application or client needs a certificate from each CA in the chain beginning with the issuing CA and ending with the Root CA. If the application or client does not have access to the certificates in the chain locally the application or client needs a place from which to obtain the certificates. This location is called the Authority Information Access or AIA. The AIA location is the repository where the CA certificate is stored so that it can be downloaded by clients or applications validating a certificate. The AIA location is included in the AIA extension of a certificate. Before implementing your PKI it is important to think about what types of clients will be validating the certificates and where they reside. If you are using Windows clients that are internal to your network and are domain members then LDAP locations in Active Directory are a good place for clients to access the AIA repository. If you have non-Windows clients or Windows clients that are not domain members that are internal then an internally hosted web site would be the ideal location for the AIA repository. However, if clients may need to validate a certificate when outside the network, then you will need an AIA repository that is available externally, perhaps on the public network.
CDP Locations
A CRL Distribution Point (CDP) is where clients or applications that are validating a certificate download the certificate revocation list (CRL) to obtain revocation status. CA’s periodically publish CRLs to allow clients and applications to determine if a certificate has been revoked. CRLs contain the serial number of the certificate that has been revoked, a timestamp indicating when the certificate was revoked, as well as the reason for revocation. Similar to AIA Locations, you need to keep in mind what types of clients you are supporting and where they are located.
CRL Validity and Overlap Periods
Like certificates, CRLs have a start date and an end date denoting a period for which they are valid. As such, you will need to consider what the CRL lifetime should be for each CA. In general, the CRL lifetime is proportional to the number of certificates the CA is expected to issue. Offline CA’s that issue relatively few certificates, and those only to other CAs, would tend to have CRLs with a more extended lifetime, for example, six months to a year. This reflects the fact that, in a properly managed PKI, an offline CA would rarely revoke a certificate. Issuing CAs, on the other hand, can be expected to issue large numbers of certificates to end-entities. It is quite common to revoke an end-entity certificate for any number of reasons, so the lifetime of an issuing CA’s CRL can be quite short; a few days or even hours.
Another thing to consider is the overlap period. The overlap period is a short time interval beyond the expiration date of the CRL, and reflects the period between when a new CRL is published, and when the old CRL actually expires. During this time both CRLs are valid. This allows time for the new CRL to replicate to all of the repositories before the old CRL expires.
Delta CRLs
Delta CRLs are CRLs that contain revocation information for certificates that have been revoked since the base CRL was last published. For example, you have a Certificate A and it is revoked. The CA then publishes a new Base CRL that includes the revocation information for Certificate A. Shortly thereafter, Certificate B is revoked. At the designated interval a Delta CRL is published which contains the serial number and reason for revocation for Certificate B. When a client needs to determine revocation status Certificates A or B it downloads both the base CRL and the Delta CRL. The client determines that Certificate A is revoked from the base CRL, and then determines that Certificate B is revoked from the Delta CRL.
The reason for Delta CRLs is due to limitations with base CRLs. Base CRLs can grow rather large over time as they contain the serial number and revocation reason for every valid certificate that has been revoked from a CA. Instead of publishing a large CRL over and over again, revocation status can be updated with the smaller Delta CRL. In this way clients that have a time valid CRL will just need to download the Delta CRL. Like base CRLs you will need to determine how often Delta CRLs are published. It should be noted that the use of Delta CRLs is completely optional and is not normally used with offline CAs for obvious reasons.
OCSP URIs
Windows Vista, Windows 7, Windows 2008 and Windows 2008 R2 can obtain revocation information from an Online Responder via the Online Certificate Status Protocol. If you are using an Online Responder to provide revocation status, you should include the URI that points to the Online Responder.
Other than the benefits of the Windows PKI, most of the things I have mentioned so far apply to any Public Key Infrastructure. I am now going to focus on a Microsoft-specific implementation.
Operating System Version
Currently both Windows 2003 and Windows 2008 are supported so you need to determine which OS you’re going to use for your CAs. In order to make that decision you will need to know what additional features Windows Server 2008 has over Windows Server 2003. Here are a few of the many new features in Windows Server 2008:
Windows Server 2008 R2
Windows Server 2008 R2 adds a number of new features to Certificate Services. These features include:
Operating System Edition
There are three editions of the OS on which you can install the Certificate Authority role. Those editions are Standard, Enterprise, and Datacenter. Standard or Enterprise Editions are normally used.
Below are the key features that Enterprise and Datacenter Edition supports and Standard Edition does not. It is important to note that Datacenter Edition does not offer any additional functionality in terms of Certificate Services over Enterprise Edition.
Certificate Authority Type
Next, you need to consider what type of Windows CA is required. A Standalone CA does not require Active Directory and can be installed on a non-domain member server. Requests for certificate enrollment can be sent through Web Enrollment if installed, or by sending a request file to the CA. The request files are usually generated through the Certreq.exe tool. Also, in Windows Server 2008 and Vista you can use the Certificate Management Console to build custom requests.
An Enterprise CA is integrated with Active Directory and requires AD in order to function. The Enterprise CA supports the same enrollment methods as the Standalone CA. In addition, however, an Enterprise can receive requests submitted through the Certificates MMC console. An Enterprise CA also allows for computer or user Autoenrollment which allows certificate request and issuance to be automated through a Group Policy setting. Enterprise CAs also use certificate templates which allow define what types of certificates a user or computer request from the CA.
Additionally, PKI related configuration information is stored in Active Directory. This makes it easy for applications and clients to locate an issuing CA, associated Certificate Templates, CRL’s and AIA information.
Certificate Templates
Certificate Templates allow you to create a template from which the values in the certificate request are generated. When a user requests a certificate based on a Certificate Template, the request generated by the client is built based upon the configuration of the template. Certificate templates are key to Autoenrollment, since Autoenrollment requires certificate templates. The importance of certificate templates is that it reduces management cost, and makes the CA easier to use. This is due to the fact that the user does not have to use complicated methods such as using certreq.exe and the associated configuration file to generate requests. Certificate Templates are stored in Active Directory and replicated to all domain controllers in the forest. This makes them highly available in order to support all clients in the forest.
For more information about Certificate Templates, please visit the following URLs:
Another important aspect to consider is how clients will enroll for certificates. There are several methods to enroll for certificates and the actual method you choose may vary. But for the majority of customers most enrollments will be done through Autoenrollment. For one off situations and testing enrollment, manual enrollment or Web Enrollment will typically be used. Beginning with Windows 2008 there is Network Device Enrollment Service that can be used for network devices to enroll.
Autoenrollment
Autoenrollment adds a high level of automation to certificate issuance. In order to deploy Autoenrollment, you must first configure a certificate template from which clients will generate their requests. You then need to enable a Group Policy setting that enables Autoenrollment. Once you enable autoenrollment the computer or user, depending on what template is configured will automatically request a certificate based on the template after Group Policy refreshes.
For more information about Autoenrollment, please visit the following URLs:
Manual Enrollment
There are several different methods for manual enrollment. The first method is to use the Certificates Management Console to enroll for certificates directly. The second method is to use the Certificate Management Console to generate a request file that can later be submitted to the Certification Authority. Third, a tool called certreq.exe can be used to create requests that can later be submitted to the CA. Certreq.exe can also be used to submit the request to the CA and also to download, and install the resulting certificate.
Web Enrollment
Web Enrollment is a web page that can be used to submit requests and download issued certificates from a CA. Web enrollment has typically been used to generate custom requests. However, with the ability to create custom requests in Windows Vista and Windows 2008 there is less of a need to use Web Enrollment
Application Specific Enrollment
Many Microsoft applications, such as Internet Information Services and Office Communication Server have built in wizards that assist with enrolling for certificates that are used by those applications.
Network Device Enrollment Service (NDES)
NDES is a role that uses the SCEP protocol to allow network devices to enroll for certificates.
Key Archival and Retrieval
Key Archival is a feature that allows the CA to archive the private key associated with a certificate in its database. A Key Recovery Manager can than recover the private key for a certificate if required. Although separate from Key Archival, an EFS Recovery Agent can be configured to recover EFS encrypted files.
For more information about Key Archival and Retrieval, please visit the following URLs:
Active Directory and Group Policy
Aside from Autoenrollment, Active Directory and Group Policy allow the configuration of PKI related settings for clients. This includes EFS-related configuration, automatically publishing Root CA certificates to the Trusted Root Certification Store on clients, revocation checking configuration, and more…
For more information about PKI-related Group Policy settings, please visit the following URL:
Configure Public Key Group Policy: http://technet.microsoft.com/en-us/library/cc962057.aspx
I attempted to cover many aspects of the PKI implementation you will need to consider before deploying a Public Key Infrastructure. There is a great deal of information out there. As I mentioned before I would strongly recommend reading the Brian Komar books. I would also invite you to review PKI related posts on the Ask Directory Services Team Blog:
http://blogs.technet.com/askds/archive/tags/PKI/default.aspx
and the Windows PKI Blog:
http://blogs.technet.com/pki/default.aspx
As well as the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure, which is located at:
http://www.microsoft.com/downloads/details.aspx?familyid=0BC67F4E-4FCF-4717-89E8-D0EE5E23A242&displaylang=en.
And the Windows Server 2003 PKI Operations Guide that can be downloaded from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e25369f-bc5a-4083-a42d-436bdb363e7e&DisplayLang=en .
- Chris “two-fer” Delay
Hello, this is LaNae Wade from the Directory Services team.
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.
Allowing Administration 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:
Event Viewer cannot connect to computer “ComputerName”. The error reported is: The RPC server is unavailable
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:
Netsh advfirewall firewall set rule group=”Windows Firewall Remote Management” new enable =yes 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.
Netsh advfirewall firewall set rule group=”remote administration” new enable=yes To allow remote management via specific MMC snap-ins, run the following command.
Netsh advfirewall firewall set rule group=”<rulegroup>” new enable=yes 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.
Netsh advfirewall firewall set rule group=”Remote Volume Management” new enable=yes 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.
http://www.microsoft.com/downloads/details.aspx?familyid=f41878de-2ee7-4718-8499-2ef336db3df5&displaylang=en&tm
- LaNae Wade
Ned here again. The AD Replication Monitor utility (Replmon.exe) was introduced with the Windows Server 2000 Support Tools many years ago as a GUI mechanism for performing certain DC admin tasks. With the release of Window Server 2008 Replmon was not included and we stopped making add-on Support Tools. Every few weeks someone asks me ‘where do I download the Windows Server 2008 version of Replmon? Nowhere. It’s done. Buried. Gone. Kaput. If you want it, you must run the old Windows Server 2003 version. Today I will talk about moving on with its supported replacement, Repadmin.exe.
Background
Replmon grew out of the need for a more useful tool than the AD Sites and Services snap-in (dssites.msc). DS Sites offered only a basic view of the topology, and had very limited options for forcing replication or seeing errors in the topology.
On the other hand, Replmon exposed more information and had a deeper view into the AD partitioning structure. It was designed not by the Windows Product Group but rather by an engineer in PSS. Like all Support Tools, it was not truly supported but instead provided ‘AS IS’.
Replmon gave an administrator the ability to quickly force replication, get basic status reports, and see information about the environmental configuration.
It was also written in a graphical format rather than a command-line interface. When Active Directory was first released 10 years ago, most tools were given more attention in their GUI rather than command-line versions. Customers were already overwhelmed with the radical changes of AD over NT and having a GUI was a highly desirable feature for a complex and not well-understood product like Active Directory.
That was then.
Now AD is as ubiquitous as Windows in most customer environments. Windows administrators are much more comfortable with the command-line, and that’s great – because repadmin.exe is now equal or superior to Replmon. Don’t believe me? Let’s compare.
Moving On with Repadmin Syncall
The most common operation with Replmon was to have it ”push” AD replication outbound from a given DC where someone had made a change and wanted it to propagate quickly to all partners. I put ”push” in quotes because AD replication is always pull-based; there is no such thing as push. What Replmon was actually doing was contacting the partner DCs and telling them to replicate inbound immediately. To do this you would:
1. Start Replmon. 2. Type in (or search for) the DC. 3. Right click the DC or partition and choose Synchronize to force replication. 4. Select if you wanted to pull or push, cross AD sites or not, and disable transitivity or not.
1. Start Replmon.
2. Type in (or search for) the DC.
3. Right click the DC or partition and choose Synchronize to force replication.
4. Select if you wanted to pull or push, cross AD sites or not, and disable transitivity or not.
Then you waited for it to finish. There were no immediate results to view, and you weren’t always going to see useful messages when something was shown at all. The only progress was a small status bar:
And you might also see:
If there was a problem you would get an error, but it could be misleading. For example, here is the error you get when forcing replication of the Domain partition and one of the DCs is offline for maintenance:
Now contrast this with the Repadmin.exe steps for the same server, doing a push replication of all partitions:
1. Run: Repadmin /syncall DC_name /APed 2. There is no step 2, we’re done. :-)
1. Run:
Repadmin /syncall DC_name /APed
2. There is no step 2, we’re done. :-)
By running a repadmin /syncall with the /A(ll partitions) P(ush) e(nterprise, cross sites) d(istinguished names) parameters, you have duplicated exactly what Replmon is doing. Except that you did it in one step, not many. And with the benefit of seeing immediate results on how the operations are proceeding. If I am running it on the DC itself, I don’t even have to specify the server name.
What about the situation I showed earlier where one of the DCs was offline for maintenance? In this case I am going to have Repadmin synchronize just the Domain partition, pushing across site boundaries:
Repadmin /syncall /Pe dc_name naming_context
With Repadmin we get a much more specific error:
Those are legitimate errors that are documented and can be researched.
Status Checking
Replmon had the option to generate a status report text file. It could tell you which servers were configured to replicate with each other, if they had any errors, and so on. It was pretty useful actually, and one of the main reasons people liked the tool.
Repadmin.exe offers similar functionality within a few of its command line options. For example, we can get a summary report:
Repadmin /replsummary *
Several DCs have been taken offline. Repadmin shows the correct error of 58 – that the other DCs are not available and cannot tell you their status.
You can also use more verbose commands with Repadmin to see details about which DCs are or are not replicating:
Repadmin /showrepl *
If you want to generate a ‘repadmin status report’ that generates a bunch of useful status information, give this simple batch file a try:
@echo off
echo. echo Gathering Report for DCLIST = %1 echo. Echo Report for DCLIST = %1 > replreport.txt
echo. >> replreport.txt echo. >> replreport.txt
echo Gathering Verbose Replication and Connections echo Verbose Replication and Connections >> replreport.txt echo. >> replreport.txt repadmin /showrepl %1 /all >> replreport.txt echo. >> replreport.txt
echo Gathering Bridgeheads echo Bridgeheads >> replreport.txt echo. >> replreport.txt repadmin /bridgeheads %1 /verbose >> replreport.txt echo. >> replreport.txt
echo Gathering ISTG echo ISTG >> replreport.txt echo. >> replreport.txt repadmin /istg %1 >> replreport.txt echo. >> replreport.txt
echo Gathering DRS Calls echo Outbound DRS Calls >> replreport.txt echo. >> replreport.txt repadmin /showoutcalls %1 >> replreport.txt echo. >> replreport.txt
echo Gathering Queue echo Queue >> replreport.txt echo. >> replreport.txt repadmin /queue %1 >> replreport.txt echo. >> replreport.txt
echo Gathering KCC Failures echo KCC Failures >> replreport.txt echo. >> replreport.txt repadmin /failcache %1 >> replreport.txt echo. >> replreport.txt
echo Gathering Trusts echo Trusts >> replreport.txt echo. >> replreport.txt repadmin /showtrust %1 >> replreport.txt echo. >> replreport.txt
echo Gathering Replication Flags echo Replication Flags >> replreport.txt echo. >> replreport.txt repadmin /bind %1 >> replreport.txt echo. >> replreport.txt
echo Done.
Copy and paste into notepad, save as a CMD file and run it with a server name, a partial server name with wildcards, or an asterisk. It supports whatever Repadmin supports.
So to get data from one server, like with Replmon:
Replreport.cmd server1
Or to get data from all DC’s (which Replmon cannot do):
Replreport.cmd *
Or to get data from all servers that have names starting with “SANFRAN“:
Replreport.cmd sanfran*
It will output to a text file called replreport.txt. Anything Repadmin can do, you can do in this batch file.
More More More
Repadmin can do even more for monitoring. Such as:
Tell you the last time your DCs were backed up, by reading the DSASignature attribute from all servers:
Repadmin /showbackup *
Or output all replication summary information from all DCs to a CSV format that you can open in a spreadsheet or database. Here I’ve brought my DCs back online and replicated any pending changes. Then I get a replication report:
Repadmin /showrepl * /csv
Or you can see what your replication backlog is currently in the queue, like here:
Repadmin /queue *
Or you can see which changes have not yet replicated from a server, as well as what changes have replicated since the last time the command was run, with /showchanges:
repadmin /showchanges destination_DC source_DSA_GUID domain_DN
(69) add CN=Ned Pyle,CN=Users,DC=adatum,DC=com 1> parentGUID: a90a9633-2682-4896-be86-21220cf24f0c 1> objectGUID: e8f0e0a2-69aa-4e4e-9f74-3db79ad6f3b7 4> objectClass: top; person; organizationalPerson; user 1> sn: Pyle 1> givenName: Ned 1> instanceType: 0x4 = ( WRITE ) 1> whenCreated: 6/21/2009 9:05:32 AM Pacific Daylight Time 1> displayName: Ned Pyle 1> nTSecurityDescriptor: O:DAG:DAD:AI 1> name: Ned Pyle 1> userAccountControl: 0x10200 = ( NORMAL_ACCOUNT | DONT_EXPIRE_PASSWD ) 1> codePage: 0 1> countryCode: 0 1> pwdLastSet: 6/21/2009 9:05:32 AM Pacific Daylight Time 1> primaryGroupID: 513 = ( GROUP_RID_USERS ) 1> objectSid: S-1-5-21-3776065869-1984782319-1196103478-1107 1> accountExpires: (never) 1> sAMAccountName: nedpyle 1> sAMAccountType: 805306368 = ( NORMAL_USER_ACCOUNT ) 1> userPrincipalName: nedpyle@adatum.com 1> objectCategory: <GUID=4ed8da23575bed48b12cd36061257c14>;CN=Person,CN=Schema,CN=Configuration,DC=adatum,DC=com
Neat right? That’s a user I created while the other DC was offline, in the list of pending changes. I snipped out another long list of changes that were also pending. Pretty useful to see if a DC that has not been replicating for a while is worth spending time trying to fix or is better off demoting.
Other Repadmin capabilities
Repadmin has plenty of other secrets you can use for monitoring, administering, and troubleshooting – most of which Replmon cannot do:
Need to see all the help?
Basic help - Repadmin /?
Help on selecting DCs - Repadmin /listhelp
Advanced command help - Repadmin /experthelp
Help and examples for every parameter- Repadmin /?:Your specific parameter here
Wrapping it up
Repadmin may not be as pretty as Replmon or Dssites.msc, but it is far more powerful than both of those utilities combined. Being an AD administrator brings a lot of responsibility – you are accountable for identity management, authentication, authorization, and general network availability for your entire company. You owe it to yourself to learn and use AD’s most powerful tools, even if they don’t support a mouse.
Update July 2 2009: One of our readers also points out that we have an excellent whitepaper on using Repadmin to troubleshoot problems. Grab it here: http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en
(Nice one, Mike!)
- Ned ‘Cursor’ Pyle
Mike here. Sometimes you need to enable additional logging when you are troubleshooting a particular component in Windows. Group Policy Preferences includes the ability to create verbose debug logging for each included client-side extensions. You activate Preference debug logging through Group Policy. Preference debug logging policy settings are located under the Computer Configuration\Policies\Administrative Templates\System\Group Policy node when editing a Group Policy object.
Figure 1 Group Policy Preferences debug logging
You can individually enable each preference client-side extension. Logging and tracing entries provide you with a several configuration options including what type of data to write to the event logs (Informational, Errors, Warnings, or all), enable trace logging and the location of the trace log file, and the size of the file.
Figure 2 Preference Logging and Tracing policy settings
You can configure the location of the trace files; however, keep in mind that file system permissions changed on Server 2008 and Windows Vista. Make sure permissions do not interfere with creating the log file. You'll notice the default location for all three log files is %COMMONAPPDATA%\GroupPolicy\Preference\Trace. The variable %COMMONAPPDATA% is not recognized by Windows, however; it is meaningful to Preference client-side extensions. Preference client-side extensions recognize this variable and expand it according to operating system on which the client-side extension is installed. For Windows Server 2003 and Windows XP, %COMMONAPPDATA% expands to %SYSTEMDRIVE%\Documents and Settings\All Users\Application Data. The equivalent path for Windows Server 2008 and Windows Vista is %SYSTEMDRIVE%\ProgramData (this folder is hidden by default, but you can manually type the path in Windows Explorer).
You've installed Windows Vista Service Pack 1; you've downloaded and installed RSAT. You try to enable Logging and tracing, but it's not there. Well, there is a reason for this.
Figure 3 Logging and tracing missing from RSAT
Administrative Templates show in the user interface because of two files: an .ADMX and an .ADML. Logging and tracing does not appear because the GroupPolicyPreferences.admx and .adml files are not included with RSAT. You need to copy these to your local or central store.
You have two options as to how to get a copy of the Group Policy Preferences ADMX files. You can download the entire Windows Server 2008 ADMX file set, or you can download just the Group Policy Preferences ADMX file set. You can download the installer for either of these file sets from http://www.microsoft.com/downloads/details.aspx?FamilyID=927fc7e3-853c-410a-acb5-9062c76142fa&DisplayLang=en. These MSI applications install their contents to the default location of %PROGRAMFILES%\Microsoft Group Policy.
The Group Policy Preferences ADMX installation creates an additional folder named Preferences, which contains a single ADMX file with multiple locale folders. You want to copy the GroupPolicyPreferences.admx file into your policydefinition folder. If you are using a central store, then you must copy the file to the policydefinition folder on SYSVOL, otherwise; copy the file to your local store. You'll then want to copy the .ADML file to the corresponding locale folder located in your policydefinition folder. See the Managing Group Policy ADMX Files Step-by-step guide for more information on managing ADMX Files and creating a central store. After you've copied both the .ADMX and .ADML file into the proper store, then close all instances of GPMC and its editor. Restart GPMC and edit the GPO in which you want to add Logging and tracing policy settings. Expand the nodes under Computer Configuration and you should now see Logging and Tracing options.
- Mike Stephens
Hi all, Rob Newhouse again, and today I am talking about errors that you may see while running ADPREP. Normally I do not like to create a laundry list of errors, however I believe it should be beneficial and save you some time and (maybe) money by posting these common errors. This is a follow up to my previous post So You Want to Upgrade to Windows 2008 Domain Controllers (ADPREP).
So you have run ADPREP and it has failed. The first thing that you need to do is open your C:\Windows\Debug\Adprep\Logs folder. There will be a separate file each time that you run ADPREP. At the bottom of the file, you will see what the problem is. Common failures include:
Errors Running Adprep /Forestprep
Adprep Was Unable to Extend the Schema
Adprep was unable to extend the schema.
[Status/Consequence]
The schema master did not complete a replication cycle after the last reboot. The schema master must complete at least one replication cycle before the schema can be extended.
[User Action]
Verify that the schema master is connected to the network and can communicate with other Active Directory Domain Controllers. Use the Sites and Services snap-in to replicate between the schema operations master and at least one replication partner. After replication has succeeded, run adprep again.
Solution
This error indicates that there are AD replication problems in the environment. In order to continue the replication issue must be resolved.
To check what replication problems you are having install your Windows Support tools and run Repadmin /Showrepl or Repadmin /Showreps on the Schema Master. This should show you which DC’s you are having problems with.
Once you have determined the DC (s) that has the problem, check to see if you can connect to \\server(servername) and \\FQDN(servername)
If both are unsuccessful then you may have a networking problem, a broken secure channel or a 5 minute time difference between the two machines.
If one is unsuccessful you have a networking problem involving DNS or Netbios name resolution.
If both are successful:
On both the DC that is not replicating with the Schema Master as well as the Schema Master:
On the Schema Master
These are just some basic troubleshooting steps. If you get an error message, go to Support.Microsoft.com and in the search type in the error message in quotes.
User Not a Member of Required Groups
Adprep detected that the logon user is not a member of the following groups: Enterprise Admins Group, Schema Admins Group and Contoso.local\Domain Admins Group.
Adprep has stopped without making changes.
Verify the current logged on user is a member of Enterprise Admins group, Schema Admins group and Contoso.local\Domain Admins group.
- Or -
Adprep was unable to check the current User's group membership
Verify the current logged on user is a member of Domain Admins Group, Enterprise Admins group and Schema Admins group if /forestprep is specified, or is a member of Domain Admins group if /domainprep is specified.
Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied
Check your group membership. If you are a member of many nested groups, you may experience the problem due to your token size. In this case, you may choose to create a new account in Active Directory Users and computers, make the new account a member of the Domain Admins, Enterprise Admins, and Schema Admin groups only, logon to the Schema Master as that account and rerun the Adprep /ForestPrep command.
As an alternative to creating a new account you can
1. Increase Maxtokensize in the registry
a) Open Regedit b) Navigate to HKLM\System\Current Control Set\Control\Lsa\Kerberos\Parameters c) Add a new Dword d) MaxtokenSize e) Value 65535
or
2. Remove all unnecessary groups
ADPREP not Running on Schema Master
ADPREP WARNING:
Before running adprep, all Windows 2000 Active Directory Domain Controllers in the forest should be upgraded to Windows 2000 Service Pack 4 (SP4) or later.
If ALL your existing Windows 2000 Active Directory Domain Controllers meet this requirement, type C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.
C
Forest-wide information can only be updated on the Active Directory Domain Controller that holds the schema operations master role.
Adprep has stopped on this Active Directory Domain Controller and must be run on the current schema operations master, which is Rob731.Contoso.local.
[User Action] Log on to the Rob731.Contoso.local Active Directory Domain Controller, change to the directory of adprep.exe on the installation media, and then type the following command at the command prompt to complete the forest update: adprep /forestprep
On rare occasions you may experience this message when you are on the schema master. In these cases transfer the schema master to another DC and then transfer it back to the original and run Adprep /Forestprep again. See also How to view and transfer FSMO roles in the graphical user interface.
If your schema master was on another machine that was removed from Active Directory then you will have to seize the schema master Role using Ntdsutil. See also Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller.
In your Adprep log you see “Error 0x80070020 (Error_sharing_Violation)”
This is normally caused by antivirus programs' on-demand scanning. To resolve the issue, disable the antivirus software on-demand scanning feature.
Adprep /Forestprep Fails Due To OID Conflict On Any Schema Attribute
“OID will not be changed resulting in probable failure to add a new class.”
This error happens when custom schema changes have been made, or when a third-party software makes schema changes that conflict with Microsoft’s.
What you will see is “OID will not be changed resulting in probable failure to add a new class.”
To resolve this issue, open the ADPREP log to see what the failed object is. If you know the third-party software that is using the attribute, contact them and determine if there is a fix. Otherwise I would recommend opening a case with Microsoft for assistance resolving this issue.
Schema update failed: An attribute with the same link identifier already exists.
This error occurs when you are trying to update/add an object in the schema and the link identifier already exists for another attribute. Some third party apps will modify the schema with a link identifier set that is owned by the OS.
You will see the following in the CMD prompt window. The key here is the message about link identifier.
Connecting to "Machine" Logging in as current user using SSPI Importing directory from file "D:\Sources\adprep\schXX.ldf" Loading entriesAdd error on line 249: Unwilling To Perform The server side error is "Schema update failed: An attribute with the same link identifier already exists." 15 entries modified successfully. An error has occurred in the program ................ Opened Connection to Machine SSPI Bind succeeded Current Schema Version is 30 Upgrading schema to version 44 ERROR: Import from file D:\Sources\adprep \sch34.ldf failed. Error file is saved in ldif.err.34.
When you look in the ldif.err.XX log you will see the attribute we are trying to add:
Entry DN: CN=ms-PKI-AccountCredentials,CN=Schema,CN=Configuration,DC=Contoso,DC=local Add error on line 249: Unwilling To Perform The server side error is "Schema update failed: An attribute with the same link identifier already exists."An error has occurred in the program."
In this instance please contact Microsoft for a resolution. This error indicates that there is a link identifier that is already in use that shouldn’t be there.
Errors Running Adprep /Domainprep
Forestprep Not Run Or Not Recognized As Having Been Run
Running domainprep ... Forest-wide information needs to be updated before the domain-wide information can be updated. [User Action] Log on to the schema master Rob731.Contoso.local for this forest, run the following command from the installation media to complete the forest update first: adprep.exe /forestprep and then rerun adprep.exe /domainprep on infrastructure master again.
This problem can happen if you haven’t run Adprep /Forestprep yet, or if replication is broken and you are running it on a different DC or Domain than you ran the Adprep /Forestprep on. To resolve this issue either run Adprep /Forestprep or resolve the replication issue depending on the situation.
Not In Windows 2000/2003 Native Mode
Adprep detected that the domain is not in native mode
[Status/Consequence] Adprep has stopped without making changes. [User Action] Configure the domain to run in native mode and re-run domainprep Raise the domain functional level to 2000 Native mode To raise Windows 2003 to native mode 1) Open Active Directory Users and computers 2) Right click on your domain name and select Raise Domain Functional Level 3) Use the drop down to select Windows 2000 Native Mode 4) Click Raise
Unable To Contact Infrastructure Master
Adprep was unable to check the domain update status. [Status/Consequence] Adprep queries the directory to see if the domain has already been prepared. If the information is unavailable or unknown, Adprep proceeds without attempting this operation. [User Action] Restart Adprep and check the ADPrep.log file. Verify in the log file that this domain has already been successfully prepared. Adprep encountered a Win32 error. Error code: 0x3a Error message: The specified server cannot perform the requested operation.. Check connectivity to the Infrastructure Master.
If you have already run Adprep domain prep, there is really only one error that you can get. When you run the Adprep /Domainprep /Gpprep after you have done the normal Domainprep you are only setting permissions on the policies folder. Below is the error that you will receive if they are inaccessible.
Group Policies Missing Or Inaccessible
Adprep was unable to complete because the call back function failed. [Status/Consequence] Error message: (null) [User Action] Check the log file ADPrep.log, in the C:\WINDOWS\debug\adprep\logs\20080806171216 directory for more information
Check to make sure that your sysvol\sysvol\policies\{6ac…………..} and {31b…………….} folders exist and are accessible. If either or both are missing and you have a backup of these folders, restore the folders. If you do not have a backup and the folders are not in an NTFRS_Policies folder, then contact Microsoft for assistance in recreating the folders.
Errors Running Adprep /Rodcprep
Adprep /Rodcprep Fails Due To Insufficient Permissions
Adprep connected to the domain FSMO: Rob731.Contoso.local.
Adprep found partition DC=ForestDnsZones,DC=Contoso,DC=local, and is about to update the permissions.
Adprep connected to a replica DC Rob731.Contoso.local that holds partition DC=ForestDnsZones,DC=Contoso,DC=local.
Adprep was unable to modify the security descriptor on object DC=ForestDnsZones,DC=Contoso,DC=local. [Status/Consequence] ADPREP was unable to merge the existing security descriptor with the new access control entry (ACE). [User Action] Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080813153240 directory for more information. Adprep encountered an LDAP error. Error code: 0x32. Server extended error code: 0x5, Server error message: 00000005: SecErr: DSID-03151D54, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
Adprep failed the operation on partition DC=ForestDnsZones,DC=Contoso,DC=local. Skipping to next partition.
You will see other partitions DC=domainDnsZones,DC=Contoso,DC=local as well. To fix this issue make sure you are in the Domain Admins and Enterprise Admins groups.
Adprep /Rodcprep Fails Because It Cannot Connect To Domain Naming Master
Adprep could not contact the Domain Naming FSMO to read the partitions. The Domain Naming FSMO must be reachable for this operation to proceed. [Status/Consequence] The Active Directory Domain Services DNS partitions are not prepared for Read Only DCs. [User Action] Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080813175105 directory for possible cause of failure. Adprep encountered a Win32 error. Error code: 0x54b Error message: The specified domain either does not exist or could not be contacted..
This error indicates that there is a problem with the domain naming master. Verify that you can contact the Domain Naming Master for the forest. You can check the operations master role in Active Directory Users and Computers.
Adprep /Rodcprep Fails Because It Cannot Connect To Infrastructure Master
Adprep found partition DC=Contoso,DC=local, and is about to update the permissions. Adprep could not contact the Infrastructure FSMO for domain DC=Contoso,DC=local. The Infrastructure FSMO must be reachable for this operation to proceed. [Status/Consequence] The Active Directory Domain Services DNS partitions are not prepared for Read Only DCs. [User Action]
Check the log file ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080814090356 directory for possible cause of failure. Adprep encountered a Win32 error. Error code: 0x3a Error message: The specified server cannot perform the requested operation.. Adprep failed the operation on partition DC=Contoso,DC=local. Skipping to next partition.
Adprep completed with errors. Not all partitions are updated. See the ADPrep.log in the C:\WINDOWS\debug\adprep\logs\20080814090356 directory for more information. To successfully update all partititions, the current logged on user needs to be a member of Enterprise Admins group. If that is not the case, please correct the problem, and then restart Adprep.
On the Schema Master run the following command:
Netdom Query FSMO
You should see the five FSMO roles including the Infrastructure Master. Once you have determined who the Infrastructure master is type \\Servername and \\FQDN(servername). Ensure that you can connect to the Infrastructure master
If you need to transfer or seize the Infrastructure master for any reason follow:
Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
Or
How to view and transfer FSMO roles in the graphical user interface
This concludes this post on many of the errors that you may encounter while running ADPREP. For those reading this after running into an error, I hope that it helped to resolve the issue.
- Rob Newhouse
Hi Rob here. I thought I would show you how we in Microsoft Commercial Technical Support typically troubleshoot Kerberos authentication issues. This discussion should do much to get you more comfortable viewing network traces for Kerberos authentication problems. There are other ways to troubleshoot Kerberos; one could use the Kerberos event logging outlined in KB 262177. Although you could rely on this method, it will take longer to resolve the issue and involves making some educated guesses without the network trace.
I am going to layout my lab configuration in case you want to reproduce the problem and look at the network traces on your own.
Forest layout:
The root domain litwareinc.com has one domain controller in the domain, and one member server.
Domain Controller network configuration:
Host Name: LTWRE-RT-DC1 IP Address: 10.10.100.20 DNS: 10.10.100.20 WINS: 10.10.100.60
Member Server network configuration:
Host Name: LTWRE-RT-MEM1 IP Address: 10.10.100.21 DNS: 10.10.100.20 WINS: 10.10.100.60
The child domain litware-chld.litwareinc.com has one domain controller in the domain, and one member server.
Host Name: LTWRE-CHD-DC1 IP Address: 10.10.200.20 DNS: 10.10.200.20 WINS: 10.10.100.60
Host Name: LTWRE-CHD-MEM1 IP Address: 10.10.200.21 DNS: 10.10.100.20 WINS: 10.10.100.60
NOTE: I’m stating the obvious here, I know, but this configuration is for testing only. Having only one DC per domain usually means you’ll be rebuilding the forest at some point.
Network based troubleshooting (network captures) is the fastest way to determine the problem, and by learning a few short filters you can effectively troubleshoot most Kerberos-related problems.
You can use any network capture utility that you feel comfortable with. I prefer Netmon, nmcap (part of Netmon 3.x) or netcap (XP and 2003 support tools) to collect the network trace, and I use Wireshark to view the network capture. This is in no way an endorsement of Wireshark – feel free to use Ethereal, Packetyzer, etc.
Problem scenario:
There is a service running on LTWRE-RT-MEM1 server that runs starts /runs as “LocalSystem” account. This service connects to a file share on LTWRE-CHD-MEM1 named “AppShare” to access some files. The Service is failing to retrieve the files and is giving you an error of “Access is denied”. When you attempt to access the share as a domain user account on LTWRE-RT-MEM1 you are able to access the share.
Auditing for Logon/Logoff was enabled on LTWRE-CHD-MEM1, so you start by examining the security event log.
When the LITWAREINC\Administrator attempts to access the share we get the following Audit Event:
Notice how the user that authenticated to the server is the “LITWAREINC\Administrator” account. It used NTLM authentication and the source machine name is LTWRE-RT-MEM1.
When the Service attempts to access the share we get the following Audit Event:
Notice that when the service attempts to authenticate to the server it is doing it anonymously.
Hey, why is the computer authenticating to the other machine using NTLM authentication? I thought we were in the 21st century with Kerberos authentication?
As it turns out, starting with Windows XP and Windows Server 2003 a computer cannot not use NTLM authentication when accessing a remote resource. If it does, it will use Anonymous Logon credentials and typically fail.
That means we have to figure out why Kerberos authentication is failing on LTWRE-RT-MEM1 when accessing a share on LTWRE-CHD-MEM1.
Typically when you troubleshoot using network captures, you want to install the network capture utility on both ends of the communications to make sure that there are no network devices (firewalls, routers, switches, VPN appliances, etc.) that are manipulating the packet in between the two systems. We call this taking a double-sided trace.
When working with a customer, we will typically request a double-sided network capture be taken. In this scenario I would start with installing the network capture utility on the source and destination server to see what is going on.
So the next question I guess becomes what are the steps to taking a good network capture?
Well, we want to see all name resolution, and we will also want to ensure that we see the Kerberos tickets (Authentication) in the capture. We also want to make sure that we can reproduce this problem at will to see this problem for ourselves.
So, how can we reproduce the problem?
1. Get a command prompt as the “SYSTEM” and attempt to access the remote system.
On Windows 2000, Windows XP, and Windows Server 2003 we can use the AT command to get a command prompt as the “SYSTEM” account by type the following command:
AT <Military Time in Future> /Interactive “cmd.exe”
i.e. if the time is currently 7:04 PM you would type in: AT 19:06 /Interactive “cmd.exe”
Then at 7:06 PM you should see a command prompt pop up
NOTE: You have to do this while logged into the console session. If you are RDP’ed in you need to start the RDP session with the /console switch otherwise you will never see the command window start.
2. Start the network capture utility.
3. Clear all name resolution cache as well as all cached Kerberos tickets.
The above commands need to be done in the command prompt that came up for “SYSTEM”
4. Now you need to run a command that will require authentication to the target server. Either of the following will do:
5. Once you get the error message, stop and save the network captures.
Reviewing the network capture:
If you are using Wireshark to view the trace, the Filter is simple: “dns || Kerberos || ip.addr==<IP Address of Target machine>”. Basically, this filter means “Show me all packets sent to or from the target machine, all DNS name queries and responses, and all Kerberos authentication.”
It should look similar to this:
Once you have the network capture, you should see all DNS, Kerberos Authentication (As well as Packets that have Kerberos tickets in them), and anything destined for the remote system.
Before we go over the capture too much, we should probably cover at a high level the steps taken to connect to a remote file share.
1. Resolve the host name for the target system to an IP address.
a. Look in the HOSTS file. b. Query DNS. c. Look in the LMHOSTS file. d. Query WINS / NBNS.
2. Ping the remote system. 3. Negotiate an Authentication protocol. Kerberos is preferred for Windows hosts. 4. Request a Kerberos Ticket. 5. Perform an SMB “Session Setup and AndX request” request and send authentication data (Kerberos ticket or NTLM response).
Let’s look at those steps in more detail.
Step 1 - resolve the name:
Remember, we did “IPConfig /FlushDNS” so that we can see name resolution on the wire. Frame 1 is the query out. Hmm, this looks kind of funny: querying for LTWRE-CHD-MEM1.litwareinc.com. Well, that part should be fine, I suppose, since the DNS server should not find the record. But wait Frame 6 shows that the DNS Server responded to the query with 10.10.200.21, and sure enough that is the correct IP Address for the target server.
Step 2 - ping the remote system:
Yep, the remote system is ping able. See the Echo request and reply. So the system is up and available.
Step 3 - Negotiate Authentication:
So now we negotiate the authentication protocol and the remote system responded; the response is the more important part of the packet. We see that it supports MS KRB5, KRB5, and NTLMSSP; it even gave us the principal name of the system.
Step 4 - Request a Kerberos ticket:
Alright, now to the meat of Kerberos authentication and viewing it in a network trace. If you remember, we used KList Purge command to clear out all tickets on the system. That means that the server has to get a Ticket Granting Ticket (TGT) first, and this is why you are seeing the AS-REQ and AS-REP frames. If Kerberos ticketing is new to you, I would suggest reviewing the blog on how Kerberos works.
Next, we see the TGS-REQ in Frame 18; let’s take a closer look at this packet in the details pane.
You can see that the system is handing its TGT to the Kerberos Key Distribution Center (KDC) under “padata: PA-TGS-REQ” section, and requesting a ticket for server “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the LITWAREINC.COM realm (Windows Domain) under “KDC_REQ_BODY” section.
OK, since we now know that we are requesting a Kerberos ticket for “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the litwareinc.com domain. This will not work since the remote system actually lives in the “litwareinc-chld.litwareinc.com” domain. So you see why the KDC responded back with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. Again, if you do not understand this please review the blog on how Kerberos works.
Step 5 - Perform a SMB “Session Setup AndX request”:
So we see in the following Frames:
So where do you think things start to go wrong here in the trace?
If you answered DNS name resolution you would be correct. If name resolution is not working properly in the environment it will cause the application requesting a Kerberos ticket to actually request a Service ticket for the wrong service principal name. So if you remember the remote file server I am attempting to connect to “ltwre-chd-mem1.chd.litwareinc.com”, however the DNS Server found a record for “ltwre-chd-mem1.litware.com”. Since we found the remote file server in the “litwareinc.com” domain the Kerberos client requests a service ticket for “cifs/ltwre-chd-mem1.litwareinc.com” as noted in the Kerberos ticket request, and the KDC responds with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
I did another net view specifying the FQDN of LTWRE-CHD-MEM1 and WOW, look at the output:
That actually worked! So, how can we fix this problem?
Actually, there are several different ways to “fix” the problem:
a. Find out why DNS is resolving the machine name incorrectly.
i. Is there a HOST or CNAME record for this name? ii. Did you configure the DNS Zone for WINS lookup?
b. Configure your application to use the FQDN of the system instead of NetBIOS name.
c. We could add an Service Principal Name to LTWRE-CHD-MEM1 for “CIFS/LTWRE-CHD-MEM1.litwareinc.com”
The best way to “Fix” the problem is to actually fix DNS name resolution. By the way, the lab was configured with “WINS Lookup” enabled on the litwareinc.com DNS Zone. If you are failing to use Kerberos authentication using the LocalSystem account, you are more than likely failing to use Kerberos authentication when users are going to the remote system. However, they are not getting “Access is denied” because user accounts, unlike machine accounts, can fail over to NTLM and authenticate with credentials rather than as Anonymous.
If you find that fixing the DNS problem is not possible, then the next best solution would be to make the application use the FQDN of the server. Keep in mind that the application vendor would need to be involved to use this fix.
The least favorite method to resolve the issue would be to add the SPN to the destination server using the SetSPN.exe tool. This is the least favorite because you are adding another name to the machine account in another domain. What would happen if in the future you bring up a new computer in the root domain with the same name? Now you have a duplicate SPN and this will lead to other Kerberos authentication problems.
Well, I hope that you have learned a few new things like:
Please keep in mind that there are several other ways that name resolution could cause Kerberos authentication to fail. You could have static WINS entries in the database, or you could have wrong entries in HOSTS / LMHOSTS files. You could be failing because of a CNAME / “A” (HOST) record within your DNS zone, or simply because of the DNS Zone is configured for “WINS Lookup”.
Robert Greene
Hi, Ned here. From time to time customers ask us what their options are to document their Active Directory environments – site topologies, domains and trusts, where group policies are linked and what their settings are. Until recently we didn’t have an easy way to do this and they were forced to invest a lot of manual labor in creating a map. Today we’ll talk about some free tools we can use to make this task very easy and accurate. I’m going to focus on the most common areas:
• Domain and Forest information • OU Structures • Sites • Exchange • Group Policy settings and links
To do this we’re going to use two automation utilities that you will need to download and install:
• Active Directory Topology Diagrammer • Group Policy Management Console
For the ADTD you will also need Microsoft Office Visio 2003 or 2007 and .NET 2.0 Framework. If you’re using the GPMC that comes with Windows Vista you will need to download the GPMC scripts separately. For this example we’ll assume you’re on XP.
GPMC is a centralized management and reporting tool for administering group policy. It includes some very useful (and well-hidden) scripts. ADTD is a newly released tool that can interrogate domain controllers about configuration data and create Visio diagrams that document your environment. When combined using the techniques below, that extremely boring and time-consuming documentation project you had in front of you is only going to take hours instead of weeks, leaving you free for more important things.
So let’s get started:
1. Install Visio, ADTD, and GPMC on a Windows XP Professional workstation or Windows Server 2003 server.
2. Start ADTD (it’s called ‘Microsoft Active Directory Topology Diagrammer’ on the Start Menu)
3. Now we’ll walk through the settings tabs to configure our data collection:
Enter in a local (to you) Global Catalog Domain Controller that you can interrogate with the tool. The actual LDAP queries to the GC only take a few seconds in most cases and should not generate any appreciable load – most of the heavy lifting in ADTD is local to your client in Visio. Add your trust settings (if you have more than one domain or multiple forests with trusts). You can also count your users per domains and identify all your GC’s. Using the default of ‘Use DNS and connect to each domain’ means that the tool will also connect to one DC in any trusting domains as well, but again, the amount of data returned will tend to be fairly small.
On the OU’s tab you can select to draw out all your Organizational Units. Most of the time you’ll want to avoid limiting the depth since your diagram will be incomplete. On the Sites tab you can specify that Site Links, Replication Connections, and subnets are drawn. Avoid using the ‘suppress empty sites’ setting as it’s useful to see locations using Automatic Site Coverage.
On the OU’s tab you can select to draw out all your Organizational Units. Most of the time you’ll want to avoid limiting the depth since your diagram will be incomplete.
On the Sites tab you can specify that Site Links, Replication Connections, and subnets are drawn. Avoid using the ‘suppress empty sites’ setting as it’s useful to see locations using Automatic Site Coverage.
If you’re using Microsoft Exchange the Exchange tab can help diagram your Exchange Organization, where the connections are, the number of mailboxes per server, and even tie them to their logical AD sites so that you know which DC/GC combinations are servicing your messaging infrastructure.
If you're using Windows Server 2003 domain or forest-based AD-integrated DNS, you can also opt to show which DC’s are hosting those partitions.
Finally, with ADTD you can get additional server information such as fully qualified domain names, operating systems and service pack, then color-code them for easier reading. This is especially useful in extremely large, complex environments where DC’s from many different domains are collocated in the same AD site within the same forest.
4. To execute your query, click Discover. After a few moments it will complete the LDAP lookups and will gray out. Click Draw, and go get a cup of coffee (or lunch, if you’re running hundreds of DC’s) – Visio will crank away creating all of the diagrams for some time. When it’s done, control will return to the ADTD application and you can close it.
So now we have some Visio diagrams that will be in your My Documents folder (by default; you can change this in ADTD's options menu). In the example below we have:
So let’s look at what Visio gave us:
Above is the AD Domains.vsd. It shows our four domains and their trusts. Let’s zoom in on the FABRIKAM domain:
We have 45 total users on our two DC’s. All the FSMO role holders are identified, as well as the schema version and what domain functional mode we’re in. If we move on to the AD Sites.vsd:
We can see that my Fabrikam.com forest has two sites, has several subnets bound to them, and there are connections between the DC’s. Let’s zoom in on that Main-Office site:
Nifty – we can see the GC’s, the subnet details, the intra and inter-site connections, the Site Link costs and schedule, and even the DC running the ISTG. If you want more detail on all these components check out the highly detailed How Active Directory Replication Topology Works.
Moving on to the AD Application Partitions.vsd, we can see that only two root domain DC’s are using 2003-style integrated DNS:
Since we have an Exchange 2003 server in this environment, Ex Organization.vsd shows us that it has affinity with the Main-Office site.
By zooming in we can see that server 2003SRV12 is part of the ‘First Administrative Group’ and is running Exchange 2003 Service Pack 2. It has 32 mailboxes. Any DC/GC lookups it’s doing should be happening against the two DC’s in this site.
Finally for ADTD, we come to the OU diagram. The diagrammer can list out all the OU’s (below is a snippet), but other than telling us that that a Group Policy Object is linked to a given location, it doesn’t give much about the policies themselves.
So here’s where GPMC scripting kicks in:
1. We open a CMD prompt on our data gathering machine and (assuming we installed to default path) navigate to:
C:\Program Files\GPMC\Scripts
2. We type:
MD c:\GPMCReports
3. We execute (using our example domain):
Cscript ListSOMPolicyTree.wsf /domain:fabrikam.com > c:\gpmcreports\fabrikamgpotree.txt
4. This returns us the c:\gpmcreports\fabrikamgpotree.txt. If we open it we see:
=== GPO Links for domain fabrikam.com ===
DC=fabrikam GPO=Default Domain Policy GPO=AllCheck OU=Domain Controllers GPO=Default Domain Controllers Policy OU=csc OU=UserRepros OU=foo OU=rar OU=RenamedPuters OU=gpotest OU=FolderRedir OU=RedirectedTest OU=nested1 OU=nested2 GPO=Logoff Screensaver OU=nested3 OU=nested4 GPO=Password Screensaver OU=wmi OU=Admins OU=Exchange GPO=No Boot
=== GPO Links for sites in forest DC=fabrikam,DC=com ===
CN=Main-Office CN=Remote-Office
5. We execute in our command prompt:
Cscript GetReportsForAllGPOs.wsf c:\gpmcreports /domain:fabrikam.com
6. This returns all of our policy settings for Fabrikam.com to the c:\gpmcreports folder:
== Found 6 GPOs in fabrikam.com
Generating XML report for GPO 'No Boot' Generating HTML report for GPO 'No Boot'
Generating XML report for GPO 'Default Domain Policy' Generating HTML report for GPO 'Default Domain Policy'
Generating XML report for GPO 'Logoff Screensaver' Generating HTML report for GPO 'Logoff Screensaver'
Generating XML report for GPO 'Password Screensaver' Generating HTML report for GPO 'Password Screensaver'
Generating XML report for GPO 'Default Domain Controllers Policy' Generating HTML report for GPO 'Default Domain Controllers Policy'
Generating XML report for GPO 'AllCheck' Generating HTML report for GPO 'AllCheck'
Report generation succeeded for 12 reports. Report generation failed for 0 reports.
7. If we open one of these HTML reports, we can see everything there is to know about that policy. For example, we’ll open the ‘Password Screensaver’ GPO which is linked at OU ‘nested4’; there’s great stuff here…
Like settings detail above.
Or version history and status.
Or delegation.
Since all this is HTML and XML, you could simply link these live into your OU VSD’s, or get fancier and automate the importation of XML data (using Visio skills far better than mine!). Worst case you’re doing a little copying and pasting from the fabrikamgpotree.txt to update your GPO information instead of hand-crafting thousands objects and settings.
Now all you need is that $20,000 color plotter so you can print out your diagram wall-sized…
Further useful group policy information:
Group Policy Management Console Scripting Samples
GP Settings Reference
Thanks for your time. If you come up with some slick Visio tricks please comment here and share them with the world!
- Ned Pyle
Hi Rob here again. I recently had a customer that needed the functionality of MoveUser.exe from the Windows 2000 Resource Kit available in Windows Vista. The customer had quite a few Windows Vista machines that were not joined to the domain but were now migrating to Active Directory. For their own business reasons they were previously unable to join the machines to the domain, instead all the users logged on with local user accounts. Since they had this new fancy Active Directory they created user accounts in AD for the users and joined the machines to the domain. They then found that they needed a way to attach the users’ existing local profile to their Active Directory user accounts so that the users would have their normal setup and desktop when they logged in-a seamless experience. Now if you have been around forever like most of us here in support in Windows 2000 and up we used a utility named MoveUser.exe to accomplish this.
Well, in Windows Vista moveuser.exe is no longer supported. However, now we expose this functionality with a new WMI provider called Win32_UserProfile, which is discussed in KB930955. This is awesome because we expose things about user profiles in WMI now… and we can also move the profile to another user as well as delete user profiles. However, once I started looking at MSDN to understand what methods were available I quickly found that MSDN has not been updated as of yet for this new class. So we did some digging into the source code to find out how this works and what is supported.
I wrote a sample script that illustrates how you can leverage this provider to move an existing user profile to another user’s profile. I know that I could have made the script smaller by not listing out all the different properties available in the provider, but the different things exposed are just way too many and if you are planning on using this provider they are just way too cool.
Please keep in mind that this is a sample script-you will need to alter it and test it in your environment and for your needs. To use:
1. Copy the below script into Notepad then save as moveuser.vbs
2. You will need to modify the following variables within the script.
3. Run the script by typing cscript moveuser.vbs
Sample Script
' This script is provided "AS IS" with no warranties, and confers no rights. ' For more information please visit ' http://www.microsoft.com/info/cpyright.mspx to find terms of use. ' Option Explicit DIM strComputer, strSourceAcct, strSourceAcctDomain, strTargetAcct DIM strTargetAcctDomain, strTargetAcctSID DIM objProfile, objCommand, objRecordSet, objConnection, objWMIService, objSID DIM dtStart, colProfiles, oSID, oUsr DIM Revision, IssueAuthorities(11), strSDDL, subAuthoritiesDIM strDomainDN
CONST ADS_SCOPE_SUBTREE=2
' This script has hard coded variables in it that must be filled out. ' strComputer = The computer name that this script needs to run against. ' With WMI the "." means this computer. ' ' strSourceAcct = user account that has the source profile on the system. ' ' strSourceAcctDomain = The domain of the source user account that the profile belongs to. ' If the source account that you want to move the profile from ' is a local computer user you put in the computers name for the domain. ' If this is another domain then you type in the domain name. ' ' strTargetAcct = The user account that the source profile should be moved to. ' ' strTargetDomain = The domain of the target user account that the profile should be moved to ' If the target account that you want to move the profile to. ' is a local computer user you put in the computers name. ' If this is another domain then you type in the domain name. ' ' strDomainDN = The Target Account Domains Distinguished Name. ' This is done for the LDAP query to be built to find the target accounts SID '
strComputer ="." strSourceAcct="User1" strSourceAcctDomain="Contoso-Vista" strTargetAcct="User1" strTargetAcctDomain="CONTOSO" strDomainDN="dc=contoso,dc=com"strTargetAcctSID="" dtStart = TimeValue(Now()) Set objConnection = CreateObject("ADODB.Connection") objConnection.Open "Provider=ADsDSOObject;" Set objCommand = CreateObject("ADODB.Command") objCommand.ActiveConnection = objConnection
' We need the proper Active Directory domain name where the user exists in a DN format. You can ' modify the strDomainDN variable to you Active Directory domain name is in DN format.
objCommand.CommandText = _ "SELECT AdsPath, cn FROM 'LDAP:// "+strDomainDN+"' WHERE objectCategory = 'user'" & _ "And sAMAccountName= '"+strTargetAcct+"'" objcommand.Properties("searchscope") = ADS_SCOPE_SUBTREE Set objRecordSet = objCommand.Execute If objRecordset.RecordCount = 0 Then WScript.Echo "sAMAccountName: " & strTargetAcct & " does not exist." ElseIf objRecordset.RecordCount > 1 Then WScript.Echo "There is more than one account with the same sAMAccountName" Else WScript.Echo "Found account: "+strTargetAcctDomain+"\"+strTargetAcct + " in the domain." objRecordSet.MoveFirst Do Until objRecordSet.EOF Set Ousr = GetObject(objRecordSet.Fields("AdsPath").Value) strTargetAcctSID = SDDL_SID(oUsr.Get("objectSID")) WScript.echo "SID for "+ strTargetAcctDomain+"\"+strTargetAcct + _ " is: "+strTargetAcctSID WScript.Echo VBNewLine WScript.Echo VBNewLine
objRecordSet.MoveNext Loop
objConnection.Close
Set objWMIService = GetObject("winmgmts:\\" & strComputer &"\root\cimv2") Set colProfiles = objWMIService.ExecQuery("Select * from Win32_UserProfile") For Each objProfile in colProfiles Set objSID = objWMIService.Get("Win32_SID.SID='" & objProfile.SID &"'") Wscript.Echo"======================================================"& VBNewLine _ &"Sid:" & objProfile.Sid & VBNewLine _ &"User Name:" & objSID.AccountName & VBNewLine _ &"User Domain:" & objSID.ReferencedDomainName & VBNewLine _ &"LocalPath:" & objProfile.LocalPath & VBNewLine _ &"Loaded:" & objProfile.Loaded & VBNewLine _ &"RefCount:" & objProfile.RefCount & VBNewLine _ &"RoamingConfigured:" & objProfile.RoamingConfigured & VBNewLine _ &"RoamingPath:" & objProfile.RoamingPath & VBNewLine _ &"RoamingPreference:" & objProfile.RoamingPreference & VBNewLine _ &"Status:" & objProfile.Status & VBNewLine _ &"LastUseTime:" & objProfile.LastUseTime & VBNewLine _ &"LastDownloadTime:" & objProfile.LastDownloadTime & VBNewLine _ &"LastUploadTime:" & objProfile.LastUploadTime & VBNewLine
' Testing to verify that the current profile handle is for the Source Account that we want to ' Move to the domain user. if UCase(objsid.referencedDomainName+"\"+objsid.AccountName)= _ UCase(strSourceAcctDomain+"\"+strSourceAcct) Then ' Making sure that the source profile is currently not in use. If it is we will bail out. If objProfile.RefCount < 1 Then WScript.echo "Change Profile for: "+ strSourceAcctDomain+"\"+ _ strSourceAcct+" to: "+ strTargetAcctDomain+"\"+strTargetAcct ' ChangeOwner method requires to String SID of Target Account and a Flag setting
' Flag 1 = Change ownership of the source profile to target account ' even if the target account already has a profile on the system.
' Flag 2 = Delete the target account Profile and change ownership ' of the source user account profile to the target account.
' To use the ChangeOwner method, both the source and ' target account profiles (If it exists) must not be loaded.
ObjProfile.ChangeOwner strTargetAcctSID,1 Else Wscript.echo "Could not move the users profile, because " + _ strSourceAcctDomain+"\"+strSourceAcct+" profile is currently loaded" End If End If Next End If Sub Init_IssueAuthorities( ) 'DIM IssueAuthorities(11) IssueAuthorities(0) = "-0-0" IssueAuthorities(1) = "-1-0" IssueAuthorities(2) = "-2-0" IssueAuthorities(3) = "-3-0" IssueAuthorities(4) = "-4" IssueAuthorities(5) = "-5" IssueAuthorities(6) = "-?" IssueAuthorities(7) = "-?" IssueAuthorities(8) = "-?" IssueAuthorities(9) = "-?"
end sub
function SDDL_SID ( oSID ) DIM Revision, SubAuthorities, strSDDL, IssueIndex, index, i, k, p2, subtotal DIM j, dblSubAuth ' ' First byte is the revision value ' Revision = "1-5"' ' Second byte is the number of sub authorities in the ' SID ' SubAuthorities = CInt(ascb(midb(oSID,2,1))) strSDDL = "S-" & Revision IssueIndex = CInt(ascb(midb(oSID,8,1))) ' ' BYtes 2 - 8 are the issuing authority structure ' Currently these values are in the form: ' { 0, 0, 0, 0, 0, X} ' ' We use this fact to retrieve byte number 8 as the index ' then look up the authorities for an array of values ' strSDDL = strSDDL & IssueAuthorities(IssueIndex) ' ' The sub authorities start at byte number 9. The are 4 bytes long and ' the number of them is stored in the Sub Authorities variable. ' index = 9 i = index for k = 1 to SubAuthorities ' ' Very simple formula, the sub authorities are stored in the ' following order: ' Byte Index Starting Bit ' Byte 0 - Index 0 ' Byte 1 - Index + 1 7 ' Byte 2 - Index + 2 15 ' Byte 3 - Index + 3 23 ' Bytes0 - 4 make a DWORD value in whole. We need to shift the bits ' bits in each byte and sum them all together by multiplying by powers of 2 ' So the sub authority would be built by the following formula: ' ' SUbAuthority = byte0*2^0 + Byte1*2^8 + byte2*2^16 + byte3*2^24 ' ' this be done using a simple short loop, initializing the power of two ' variable ( p2 ) to 0 before the start an incrementing by 8 on each byte ' and summing them all together. ' p2 = 0 subtotal = 0 for j = 1 to 4 dblSubAuth = CDbl(ascb(midb(osid,i,1))) * (2^p2) subTotal = subTotal + dblSubAuth p2 = p2 + 8 i = i + 1 next ' ' Convert the value to a string, add it to the SDDL Sid and continue ' strSDDL = strSDDL & "-" & cstr(subTotal) next SDDL_SID = strSDDL end function
Please keep in mind if you have not installed Service Pack 1 for Vista, you will need to download the MSI installer to get the new WMI Profile provider since it was released after Vista shipped.
Well, I hope that you find this functionality helpful. Happy scripting.
- Rob Greene