The things that are better left unspoken : Delegation of Control

New features in Active Directory Domain Services in Windows Server 2012, Part 19: Offline Domain Join Improvements

Sander Berkouwer — Mon, 17 Sep 2012 20:45:47 GMT

With Windows 7 and Windows Server 2008 R2 Microsoft introduced a new Active Directory feature called Offline Domain Join (ODJ). This feature allows for clients to be joined to an Active Directory domain, without the need of having a direct connection to any of the Domain Controllers for the Active Directory domain.

Scenarios

Offline Domain Joins use useful when you want to join a computer to an Active Directory infrastructure without the need for direct communication between the client and a Domain Controller. These include:

Deploying vast amounts of computers, without straining Domain Controllers in terms of bandwidth and processing, which might affect existing domain-joined computers. Also, in this scenario Offline Domain Join saves time.
Deploying domain-joined computers to a branch office site where only Read-only Domain Controllers reside. (Read-only Domain Controllers are not suitable for clients joining the domain)
Deploying domain-joined computers to users in remote locations (like homes) that from time to time require access to resources in an Active Directory environment and may not have a high enough quality connection to the Domain Controllers.

Although Offline Domain Join can be used to join computers to a domain without a direct connection to an Active Directory infrastructure, at one point a domain-joined computer needs to connect to a Domain Controller on a regular basis to stay a part of the Active Directory infrastructure. (unless you want to spend the rest of the lifetime of the domain-joined computer feeding it offline domain join information…)

What’s New

Offline Domain Join has been extended by allowing the blob to accommodate Direct Access prerequisites:

Root Certificates
Certificates
Group Policies

This means the number of scenarios increase. One of the main scenarios that now gets included is deploying domain-joined computers to DirectAccess users. The clients now have everything they need to successfully connect to the DirectAccess server(s).

Note:
A Graphical User Interface to perform Offline Domain Joins is not part of the improvements to Offline Domain Join in Windows 8 or Windows Server 2012.

Performing Offline Domain Joins

Let’s look at the individual steps of the process:

Step 1

To kick off the Offline Domain Join an administrator would logon to the Windows Server 2012-based Domain Controller. When logged on with an account with sufficient permission and quota to create Computer Accounts, the administrator would provision the client on the Domain Controller itself with the following command:

djoin.exe /PROVISION /DOMAIN DomainName /MACHINE MachineName /SAVEFILE FileLocation

Here’s an example:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-2
/SAVEFILE C:\ODJBlobs\Win8-2.b64

Now, In situations where you’d want to include Root Certificates, Certificates or Group Policies in the blob, extend the command above with the following extra switches:

Include root certificates /RootCACerts

Include certificate templates (includes their root certificates) /CertTemplate

Include Group Policies /PolicyNames

An example of such a command would be:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-3
/POLICYNAMES CompanyLookAndFeel
/SAVEFILE C:\ODJBlobs\Win8-3.b64

Step 2

This command, when successful, creates the in the location specified. This file, which can be given any file extension is a Base64-encoded file, containing all the necessary information for a Windows 7 client to join the Active Directory domain.

When you open the file and pull it through a base64-decoder (like this one) the contents of the file become clear.

Inside the blob

Let’s take a look at the Offline Domain Join blob we created in step 1 for Win803 in the domain.local domain:

This file doesn’t really provide any insight into how Offline Domain Join works its magic, but as mentioned earlier, the Offline Domain Join (ODJ) blob is a base64 encoded file. This means we can put it through a Base64 decoder like this one, or convert it using one of the many online base64 decoders. This will result in outcome similar to the text file below:

As you can clearly see, the decoded file contains the information you’d suspect a client needs to join the domain. The decoded file contains the DNS domain name (domain.local), the workstation NetBIOS name (Win8-02), the computer password, the NetBIOS domain name (DOMAIN), the name of the Domain Controller (DC01.domain.local), it’s IPv4 address (10.8.255.1) and the Active Directory site. (Default-First-Site-Name). Also, it includes the policy settings in the CompanyLookAndFeel Group Policy.

The nature of the decoded file, also warrants the security note placed in the Offline Domain Join (Djoin.exe) Step-by-Step Guide:

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

Step 3

After the Offline Domain Join blob gets transferred to the would-be client, a local administrator can join the computer to the domain in an offline fashion by typing the following command in an (elevated) command prompt:

djoin.exe /REQUESTODJ /LOADFILE FileLocation /WINDOWSPATH WindowsPath /LOCALOS

As an example, here’s the command for Win8-03:

djoin.exe /REQUESTODJ /LOADFILE C:\Win8-03.b64
/WINDOWSPATH C:\Windows /LOCALOS

Note:
Alternatively, you can include the Offline Domain Join blob in an unattend.xml file.

After the client successfully works through the command, the would-be client reboots as a member of the Active Directory domain. On first contact between the client and the Active Directory domain, the client would reset its Computer Account password.

Requirements

Operating system requirements

Offline Domain Join requires Djoin.exe. This command is available on domain-joinable editions of Windows 7 (Professional, Ultimate, Enterprise), domain-joinable editions of Windows 8 (Professional, Enterprise), Windows Server 2008 R2 and Windows Server 2012.

Note:
When you want to include root certificates, certificate templates and group policies, you will need to run djoin.exe on Windows 8 or Windows Server 2012.

If you want to use djoin.exe with Windows Server 2008-based Domain Controllers, use the /downlevel switch when you provisioning.

credential requirements

The djoin.exe command needs to be run by a user account with sufficient permissions to create computer accounts. By default, members of the Domain Admins group can create computer accounts. The user right to Add workstations to the domain can be set using Group Policy, or can be granularly delegated using Active Directory Delegation of Control.

Concluding

Offline Domain Join (ODJ) already was a nice feature in Windows 7 and Windows Server 2008 R2, but in Windows 8 and Windows Server 2012 this feature really proves its worth with the ability to offline provision DirectAccess clients with certificates and group policies.

Tip: Zohno’s Z-Hire & Z-Term (freeware)

Sander Berkouwer — Mon, 13 Feb 2012 22:18:43 GMT

Many software vendors and organizations have adopted workflow tools to accommodate their needs towards faster delivery of the same quality. At least, getting an OK from a senior executive, is something that can be automated to save time, right? Another angle a lot of organization explore is Delegation of Control. Why wait for a centralized admin over in India to perform a (small) action, when you can have a super user, HRM executive or concierge to perform it too?

Most organization, however, don’t get very far in their efforts. The reason, mainly, is the lack of understanding of the business by the IT-department, causing a missing policy. Another reason might be, that solutions that offer full workflow capabilities, like System Center Orchestrator, are deemed too expensive. Another big reason is executives might believe they’ll have to be charged more once charge-back is introduced or at least when IT usage becomes more transparent. These organization don’t have much to gain with workflows. Or so it seems.

For these kinds of organizations, Denny from Zohno has created two applications, that can be used to delegate two particularly simple (but often fought over) tasks:

Hiring new personnel and entering their basic information in the core applications
Terminating a persons contract and removing the person from the core applications, without information getting lost.

Best of all: these two applications are complete freeware!

Z-Hire

Z-Hire automate IT account creation process including Active Directory account, Exchange mailbox and Lync account. With a click of a button, an Active directory account, Exchange mailbox and Lync account will be created. Traditionally, this process might take over 3 minutes, but with Z-Hire, this can be done in matter of seconds. Features include:

Active Directory account creation with major attributes
Active Directory group selection
Exchange 2007 / 2010 Mailbox creation, support for ActiveSync, Managed folder policy and more…
Lync 2010 account creation supporting External Policy and Conferencing policies

Download Z-Hire from the TechNet Gallery here.

Z-Term

This application allows IT administrators to automate common tasks when an employee leaves the company. Usually, IT administrators use multiple consoles and perform a variety of tasks to terminate user accounts. Z-Term allows IT administrator to automate:

Disable the Active Directory account
Reset the user’s password in Active Directory
Move the user account to an Organizational Unit (OU) of your choice
Remove AD Group membership

Note: This action removes the user from all Active Directory groups.

Change Distribution list ownership (the managedby property)
Hide the user from Outlook Global address list in Exchange
Set an Out of Office autoreply of your choice
Forward the user’s emails to someone else
And more to come in next version…

Download Z-Term from the TechNet Gallery here.

Both these tools, with proper Delegation of Control (DoC) and Role-based Access Control (RBAC) under the hood, can be used to allow a super user, HRM executive or concierge to hire and/or terminate accounts in a way, even they can remember.

The case of… display issues (garbled or missing text) in Active Directory Administrative Center

Sander Berkouwer — Thu, 14 Oct 2010 09:02:44 GMT

I’ve been working with Active Directory Administrative Center (ADAC) for a while now, but didn’t have time to look at Delegation of Control lately. Yesterday I finally came round to configuring it and was baffled by a serious issue:

After delegating Account creation to a user, installing the Remote Server Administration Tools (RSAT) on the Windows 7 Enterprise workstation of the user and adding the Active Directory Administrative Center remote management feature on it, the tool wouldn’t work. Actually, the tool would start (slow as always, but would nonetheless start), would show its window, would show the icons for the containers, users, etc, but refused to show the corresponding texts in the Active Directory Administrative Center window. (or, at times, garbling text, rendering it unreadable)

I began troubleshooting the issue.

Messed up delegation?

I previously added the user to the Account Operators group in the domain. Perhaps this issue occurred because I messed up Delegation? Perhaps the user needed more rights? Perhaps a similar bug exists in Windows Server 2008 R2 where the Account Operators for some reason don’t have read rights on the Built-In OU? I checked the security permissions of the user and Account Operators group to the Users, Computers and Built-in containers in Active Directory, using SysInternals’ ADExplorer. I found nothing out of the ordinary and decided to supply the user access to the Active Directory Users and Computers MMC Snap-in (dsa.msc) to check things. After resetting passwords on a couple of test accounts, no Access Denied errors were thrown. I ruled out Delegation of Control as the cause of this issue.

Local administrator privileges needed?

The account I used did not have administrator privileges on the workstation. When starting up the Active Directory Administrative Center (dsac.exe) with the built-in Administrator account I’ve seen User Account Privilege (UAC) prompts, so perhaps the Active Directory Administrative Center needs local administrator privileges?

Adding the user account to the local administrators group and logging off and logging on the user on the workstation, did not resolve the issue, so I reversed the local administrator group membership…

PowerShell or the .Net Framework to blame?

I then started troubleshooting PowerShell. For some reason I found the same issue in the PowerShell ISE (text not showing after typing). I redeployed Windows 7 on the machine and the issue in the PowerShell ISE would reappear. I knew then, the RSAT were not to blame. This was not an Active Directory Administrative Center error!

Since PowerShell can’t be uninstalled and reinstalled in Windows 7, I ruled out blaming PowerShell or the underlying .Net Framework for this error. (else Microsoft would have made an option available to at least reset PowerShell on Windows 7, right?)

I reckoned this might be a display issue, not a PowerShell issue.

Windows Aero doesn’t play nice?

Next thing I checked was whether there was an issue between the Active Directory Administrative Center and Windows Aero. I switched to the Windows 7 Basic theme and restart the box. This is getting dull, since this also did not resolve the issue.

Display driver to blame?

I was on a hunch though, since, next, I decided to check for a newer driver for my display adapter. Sure enough, a new driver was available. I installed the newer display driver and again restarted the box.

After the reboot, I made the user log in and let him fire up the Active Directory Administrative Center (dsac.exe).

Yes!

This time it showed the text as it should be:

Concluding

When working with Active Directory Administrative Center (dsac.exe) and Delegation of Control:

The Active Directory Administrative Center does not require administrative privileges on a workstation to work remotely through the Remote Server Administration Tools (RSAT).
The Active Directory Administrative Center works on top of Windows PowerShell. Windows PowerShell cannot be uninstalled in Windows 7.
Display drivers may cause issues with text display in Windows 7. These issues may affect the Active Directory Administrative Center.

The things that are better left unspoken : Delegation of Control

New features in Active Directory Domain Services in Windows Server 2012, Part 19: Offline Domain Join Improvements

Scenarios

What’s New

Performing Offline Domain Joins

Step 1

Step 2

Inside the blob

Step 3

Requirements

Operating system requirements

credential requirements

Concluding

Further reading

Tip: Zohno’s Z-Hire & Z-Term (freeware)

Z-Hire

Z-Term

The case of… display issues (garbled or missing text) in Active Directory Administrative Center

Messed up delegation?

Local administrator privileges needed?

PowerShell or the .Net Framework to blame?

Windows Aero doesn’t play nice?

Display driver to blame?

Yes!

Concluding

Further reading

Include root certificates	/RootCACerts
Include certificate templates (includes their root certificates)	/CertTemplate
Include Group Policies	/PolicyNames