The Imperfect Lab: Syncing AD to Azure AD

Today I decided to ease myself into my next steps and build out a member server to sync AD to.  I reused some previous PowerShell to deploy a member server and join it to my domain.  It is possible to run the sync services on an existing domain controller, but as a best practice I don’t like to install one-off applications on my domain controllers.  I like to keep them identical, thus the need for different member server to perform the sync role.

I had previously uploaded the Microsoft Azure AD Sync Services (aka AADSync) application to my Azure file share, but you can find it at http://aka.ms/azureadsync.  You will want to install and run the Microsoft Azure AD Connection Tool.  Please note that Microsoft Azure AD Sync Services is DIFFERENT from Windows Azure Active Directory Sync (aka DirSync)

Once the Sync Server is built, you will want to kick off the installation of the application, but not before you’d made some adjustments to your Azure Directory.  In the Portal, I went to my directory and created a new user account to be my Azure AD Administrator (newuser@imperfectlab.com) and made it a Global Administrator.  You will also need to go through the sign-in process to set a non-temporary password.

Once you have this account, you simply need to throw the switch under “Directory Integration -> Directory Sync” from Inactive to Active.  Once the setting is saved, the “Last Sync” field will say “never synced”.  Now go over to your sync server and run that connection tool.

You’ll need the account and credentials you created for the new Azure AD Admin and some information about your domain.  For the addition of the forest, you’ll need your domain name and the username and password of a enterprise domain admin from your local domain.  This will be different than the account your created directly in Azure AD.

Leave the User Matching page at the defaults but select “Password Synchronization” from the Optional Features. Finally, review your configuration screen and verify that “Synchronize Now” is checked and click finish.  At this point, your users should sync into Azure AD and after a few minutes you’ll see a list of them in the portal.

If you want to make any changes to the settings of your AD Sync, like adding in a feature, simply rerun the tool after disabling the Azure AD Sync Task in Task Scheduler.  The task will be re-enabled automatically when you finish the wizard again.

If you want to force a sync for Azure AD Sync Services for any reason, the default location of the command line tool is:

c:\program files\microsoft azure ad sync\bin\directorysyncclientcmd [initial|delta]

Happy Syncing!

Advertisements

The Imperfect Lab: Adding A Custom Domain

This will be a super short post, because this task is super easy!
My lab in Azure wouldn’t be complete without its own custom domain. Honestly, this is one of those “just pop over to the Portal” tasks because it only takes a few clicks, particularly if you are only doing it once.  But you won’t be able to complete in a hurry, because your registrar will update the public DNS entries on their own sweet time and that update is needed to complete the process.
By the way, if you really want to do this without the Portal, you can find information on installing the right PowerShell modules and the commands here. (http://msdn.microsoft.com/en-us/library/azure/jj151815.aspx)  If you are going to managing multiple tenants over time, PowerShell will likely be the best way to go.
Anyway, when you are in the Portal, click “Active Directory” in the navigation.  Select the domain directory you want to add a custom domain to.  In this case, I wanted to create a new Azure Directory for the Imperfect Lab, so I clicked “New” and then went to APP SERVICES -> ACTIVE DIRECTORY -> DIRECTORY -> CUSTOM CREATE.
I named my directory “ImperfectLab” and picked my region.  The domain name for the directory is now “Imperfectlab.onmicrosoft.com”.  Since I don’t want to be using the “onmicrosoft.com” moniker for very long, I need to add my recently purchased domain.  You actually have to a own (or at least control) the domain you want to add because it’s requirement to add a TXT or MX record to your public DNS.
Click into the directory you want to use and go to the “Domains” section. On the bottom action bar, click “Add”. Then type in the FQDN for your “real” domain, in my case “imperfectlab.com”.  You be given the information to create either at TXT or MX record that needs to be added to your DNS records managed by your registrar.
My registrar doesn’t accept the @ symbol for the parent zone, but leaving that field blank worked fine.  You have to add the record, wait for the external DNS to update and then return to the portal to verify it.

Once verified, you can create (or sync) users into your Azure Active Directory using either your “user@domain.onmicrosoft.com” UPN or your “user@domain.com” UPN.

The Imperfect Lab: Fleshing Out Active Directory

Having a domain with no users isn’t any fun.  So my next task for the Imperfect Lab was to create a few accounts to act as my users for provisioning access and eventually syncing with Azure Active Directory.
You can do a lot with some basic PowerShell to create OUs and User Accounts.  Here are a few basic lines that would create something in my lab domain:
New-ADOrganizationalUnit –Name “DOGS” –Path “DC=imperfectlab, DC=Com”
New-ADUser -Name “Lizbeth Tiburon” -Path “OU=DOGS,dc=imperfectlab,dc=com” -AccountPassword $newPassword -Department “Career Changed” -SamAccountName “LTibu” -Surname “Tiburon” -GivenName “Lizbeth” -DisplayName “Lizbeth Tiburon”
Those lines would create a OU and then a user account in the new OU.  But what if you wanted to create more users at once?  I could simply duplicate the 2nd line, but figured there had to a relatively easy way to get data straight from a CSV file.
I did some looking around online and since no good Internet search goes unpunished, I found this: https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Create-Active-7e6a3978#contentby @mwashamtx.  Honestly, this a great script that I couldn’t have written by myself at this point, but I was able to tweak it enough to do my bidding. 

I changed the paths (to reflect the drive letter and file location I set up using Azure Files), removed a lot of the fields the script used to populate account attributes and edited the CSV file to match.  I uploaded my CSV file to my Azure file share. I left the script writer’s five character SAM account name creation as is and ran it remotely via PS-Session on my domain controller.  The DC tapped the CSV file in my Azure File share and wrote the log to that same location.  The script does some great error handling, which was really helpful for troubleshooting.  Mission accomplished!
And for those of you who are curious about the user created in that line above, Lizbeth is a dog who didn’t complete the training to become a guide dog

The Imperfect Lab: More DCs and Static IPs

When I was last working in my Imperfect Lab, I added another server to the existing cloud service and decided to make it a domain controller.  When you set up domain controllers (cloud or on-premises) a few things become really important – IP Addresses and DNS.
By default, Azure will provide DNS services from the fabric if you don’t specify your own DNS.  You would think there is some PowerShell to do that directly, but surprisingly there isn’t.  You can set the DNS for each network using the Management Portal or by exporting the network configuration file and updating it.  I just used the portal and made sure that my ImperfectNet listed the IP address for both servers that would act as domain controllers.
If you don’t set a domain controller as the DNS server, all the VMs that come up inside your virtual network will look to an Azure fabric DNS server and won’t be able to authenticate to your domain.  Since this is a crucial to AD function, I also wanted to make sure that the VMs that were acting as domain controllers had static internal IP addresses. 
Now, these addresses aren’t really “static” on the OS. They are more like DHCP reservations handed out from the fabric manager.  But the end result is the same – VMs that have the correct IP address, regardless of the order they are started.
To do this with PowerShell, you first need to have the VMs in the Stopped (Deallocated) state. This way the addresses are free to assign.  If the VM is already running, the address is allocated already, thus can’t be assigned.  You can double check that an address is free with:
Test-AzureStaticVNetIP –VNetName ImperfectNet –IPAddress 192.168.1.5
To set the static address, I used:
Get-AzureVM -ServiceName ImperfectCore -Name DC-Cloud1 | Set-AzureStaticVNetIP -IPAddress “192.168.1.4” | Update-AzureVM
Take note of the use of quotes around the IP address in that last line. It matters. I don’t know why.  Just trust that I wasted a lot of time on your behalf for that knowledge.
Then to finally kick off the addition of my second domain controller in this domain, I used:
Install-ADDSDomainController -Credential (Get-Credential) -DatabasePath ‘C:\Windows\NTDS’ -DomainName ‘imperfectlab.com’ -InstallDns:$true -LogPath ‘C:\Windows\NTDS’ -NoGlobalCatalog:$false -SiteName ‘ImperfectNet’ -SysvolPath ‘C:\Windows\SYSVOL’ -NoRebootOnCompletion:$true -Force:$true -Verbose
One note about the paths used for the logs and SYSVOL… I’ve left them on C:\ for convenience, but for production, you will want to set up your DCs in Azure with an additional disk where you direct those files to go.  Read more about the reason behind that best practice here.
Also, if this Domain Controller happens to connect back to an on-premises domain. Be sure to make the proper changes to you AD Sites and Services to ensure proper site topology.

Update (12/26/14): For easy access to code snippets, you can find them here.

Throwback Thursday: Sessions from TechEd Houston

Today is my final installment of highlights from TechEd Houston! Below are some of my session picks from the last day of the conference.

  • TWC: Hacker’s Perspective on Your Windows Infrastructure: Mandatory Check List (DCIM-B366)
  • Windows 8 Security Internals (WIN-B350)
  • Real-World Windows 8.1 Deployment Note from the Field (WIN-B358)
  • Providing SaaS Single Sign-on with Microsoft Azure Active Directory (PCIT-B326)
  • Delivering Disaster Recovery Solutions Using Windows Server 2012 R2, Microsoft System Center 2012 R2 and Microsoft Azure (DCIM-B421)
  • How IPv6 Impacts Private Cloud Deployments (DCIM-B373)
  • Windows Server 2003 End of Life Migration Planning for Your Workloads (DCIM-B376)
  • Upgrading Active Directory the Safe Way: Using Virtualization Technologies (PCIT-B341)
For my lists of sessions from the other days, you can find them here: Monday, Tuesday and Wednesday.

Replication Warnings? – It could be just one Attribute.

Active Directory can be a funny beast.  This week, I noticed a reoccuring replication error that didn’t seem to be sorting itself within a reasonable time frame.  I was seeing NTDS Replication Warning 1083, referencing a specific user account: 

Event Type: Warning
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1083
Date:  10/3/2011
Time:  11:45:00 AM
User:  NT AUTHORITY\ANONYMOUS LOGON
Computer: DC1
Description:
Active Directory could not update the following object with changes received from the domain controller at the following network address because Active Directory was busy processing information.

Object:
CN=Joe Smith,OU=Accounts,DC=mydomain,DC=org
Network address:
a5b5b72d-c74b-486a-9dfa-f6516f37b38b._msdcs.caclo.org

Following it was the informational event 1955 about a write conflict:

Event Type: Information
Event Source: NTDS Replication
Event Category: Replication
Event ID: 1955
Date:  10/3/2011
Time:  11:45:00 AM
User:  NT AUTHORITY\ANONYMOUS LOGON
Computer: DC1
Description:
Active Directory encountered a write conflict when applying replicated changes to the following object.

Object:
CN=Joe Smith,OU=Accounts,DC=mydomain,DC=org
Time in seconds: 0 

After some research I tried the following troubleshooting steps:

1) Moved the offending user to a different OU temporarily to see if the problem resolved.  This essentially “tickles” AD into replicating that particular user. I recieved the same messages, but the user’s CN had been updated to the new OU.
2) Used the LDP tool to see if there was duplicate entries for this user somehow, but only one instance was found.
3) Used repadmin to look at the time stamps of various attributes on the account, particular one with a time stamp close to the time that the replication warnings started appearing in the event log.

Repadmin was where I had the most luck.  You’ll want to run the following command for Windows 2003 SP2 DCs:

repadmin /showobjmeta DC1 “CN=Joe Smith,OU=Accounts,DC=mydomain,DC=org”

This will return a list of attributes with timestamps.  In my case it was the attribute related to the last password change, which was the only one that had a timestamp of the same date when the errors began.  I reset the password on the account to “tickle” that particular attribute and the replication completed without any complaint.

Some anticodotal stories on the Internet indicate that this attribute can cause trouble if replication occurs while an account happens to be locked out.  In this case, the account was for a consultant who didn’t log in very often, so the locked account went unnoticed for some time, causing the replication issue.

Inside MDOP: AGPM 4.0

In case you missed the PacITPros meeting on December 7th, you missed out on some interesting vendor and technical presentations.  In addition to a presentation from BlueCat Networks and Hurricane Electric, I did a short demo of one of the MDOP tools – the Advanced Group Policy Manager 4.0.

This tool hooks right into the existing Group Policy Manager snap-in you know and love in your MMC and with the use of a designated archive server, extends the functionality to include better search features and change management.  No matter the size of your organization or the number of IT staff you share group policy tasks with, you can benefit from this tool.  Even if you are the only person who does anything with group policies, this tool will make your life easier.

First, the change control features take away much of the pain of keeping track of what was changed when and potentially by who.  Policies that are controlled by the system must be checked in and out for adjustments, which automatically creates a history record capturing the state of a policy at any given time.  These records can easily be reviewed for corporate compliance and policies can even be rolled back to previous states.

With new roles created within the tool, non-admininstrators (even regular domain users) can be granted the ability to review or edit policies… leaving the actual deployment and linking of the GPOs to system administrators.

The abililty to search and filter your view of policies is much improved.  You can search by name, state (checked in, checked out), even by variables such being updated “last month” or “last week”. 

Finally, you can easily import and export policies, even across forests.  No more manual recreation of the perfect policy just because you want to use it in your test lab environment or in another forest.

Finally, keep in mind that APGM 4.0 adds support for Windows Server 2008 R2 and Windows 7, as well as runs on Windows Server 2008 and Vista.  If you are supporting an environment with older versions of Windows Server, consider version 2.5 or 3.0 of the tool.  Not of all of the features are included, but if you are looking specifically for the change management aspects, those older versions may work for you until you upgrade your servers.

Out of the six tools in the Microsoft Desktop Optimization Pack, APGM isn’t one I’d overlook.