My AAD Connect service account password needed to be changed recently, which caused some issues.
When changing the password, you need to update the password two places:
- Microsoft Azure AD sync service (ADSync)
- Synchronization Service
I wasn’t aware of #2, which caused incomplete sync to occur. The symptom was new users from onprem not being added to Azure AD, while existing users and groups we’re not being updated. In addition, my service account got locked out on some occasions, specifically when I forced syncs during troubleshooting.
To remedy the Synchronization Service, do the following:
- Open Synchronization Service GUI
- Click “Connectors” (top of window)
- Right click the connector for your on-prem AD
- Select “Connect to Active Directory Forest”
- Type in updated user information (typically just an updated password)
You can test the sync by running the Powershell command:
Start-ADSyncSyncCycle -Policytype Delta
This will run a delta sync of your on-prem AD objects to AAD.
“Why on earth would you do this”, may be the first thing you ask? Well, if your organization has multiple Azure AD (AAD) directories, perhaps due to security requirements, or mergers or acquisitions; it may be a good idea adding guest users from other AAD directories as members.
First of all, the main difference between a Guest and a Member is in the lookup rights to the domain. A guest can typically not look up users and groups like a Member user can. A member would need this for self service reasons, and to look up contact information for other users, while you’d typically not want a guest to do that.
In order to convert the user, you currently have to use Powershell. Ypou need to have the AzureAD module installed on your computer.
- Log into your Azure AD tenant:
- Convert the user
Get-AzureADUser -SearchString UPN@DOMAIN.COM | Set-AzureADUser -UserType member
You may want to search up the user using just the Get-AzureADUser first.
Everybody who’s tried to get Office 365 licenses knows tht it’s not a straight forward as it should be, and getting a list of license holders for a certain SKU may not be simple. The Powershell snippet below let’s you list the license holders for a specific SKU, just modify the last part (currently “*visio*”) to match the product you’re looking for.
Get-MsolUser -all | select displayname,userprincipalname,objectid -ExpandProperty licenses | where accountskuid -Like "*visio*"
To list the SKU’s available in your enterprise agreement, use the command:
My task was to eliminate direct license assignments and start using on Group based licensing in O365. By adding the current license holders to a group, I could remove the direct assignments and ease administration and reporting going forward.
On May 25th, the new EU rules regarding personal information takes affect. General Data Protection Regulation, or GDPR is a set of rules and regulations which standardizes the somewhat confusing national rules which all EU countries have regarding storing, managing and securing personal data.
GDPR is meant to transfer ownership of information back to the user, but it’s also in many ways a simplification of the flux of rules which has been created since the inception of the public internet, and the rise of social media.
As an IT admin today, perhaps the most important thing is to know where your data is stored. It’s easy to start consuming a new cloud service without concerning yourself with where the data is stored, or how it’s secured. GDPR places a responsibility on the employer to ensure that personal data is stored securely and managed responsibly, regardless of where it’s being stored.
GDPR is an extra-territorial regulation. That means that as a non-EU company with employees in any EU membership countries, GDPR governs how personal information is managed, even if it’s stored outside the EU. The fine for breaking GDPR regulations can be as high as €20.000.000,- or 4% of global revenue, whichever is higher. It’s probably cheaper to stay compliant!
When I set up a new application, or subscribe to a cloud service on behalf of my company, I’ve started going through a checklist which is a follows:
- Where is the data stored?
- Is personal data stored?
- Is it encrypted
- Does personal data have a different permission set than content?
- Who in my company has access to personal data?
- User accounts
- Access control lists
- Who outside my company has access to personal informations?
- Is the application/service owner an EU citizen? (if not, brief on GDPR)
- How is data transferred?
- Endpoint to endpoint encryption
My employer is currently working on ramping up personal data compliance for our European employees. It’s as much an HR job as it is technical. HR depends on IT to stay compliant, and IT depends on HR to create the policies.
Is your organization ready for GDPR?
When backing up Active Directory in your local data center, you usually have control of everything from power and cooling, through networking, to physical machines and hypervisors. This also gives you control of the terminal for your virtual machines. In the Azure cloud however, when installing an IaaS VM, this VM is unavailable during reboot. No console, no terminal, no nothing; until the VM starts responding to services defined by the ports you’ve opened through your endpoints, you’re in limbo.
This isn’t usually a problem, but when doing an Active Directory restore, authoritative or otherwise, console access us often used to force the computer into Directory Services restore mode.
Let me take you through an AD restore in Azure. First of all, here’s my status quo:
I’ve got an OU named BackuptestOU, which I’m deleting
Now for the restore:
- Open System Configuration (Windows key, type System Configuration)
- Here’s how it differs from a typical AD restore. Go to the tab Boot and make the following selections
- Press OK and select Restart
- Log on with your Domain Services Restore Mode username and password
- Before starting the Restore, revert boot options. Open system configuration again, and set the options as below to avoid rebooting into Directory Services restore mode after the restore.
- Open Windows Server Backup and press “Recover”
- Choose the correct location for your backup (in my case local)
- Select the point in time you’d like to restore to
- Select “Original Location” and tick of the checkbox “Perform an Authoritative Restore of Active Directory files
- Read this warning and confirm this warning by pressing ok
- Press Recover. I like to have the server reboot automatically, but if you’d like to retain control of the reboot, leave it unticked
- Select Yes to confirm starting the recovery
- Wait for the recovery process to complete
- And last, I demonstrate the AD restore is successful by showing you the OU I deleted. My backup was taken before I moved the last user, which is why there is only one user present.
So I hope this gives you some input on how to manage Active Directory in the Azure cloud. Please feel free to comment any question below.