AD Connect



EMS TTT Online AD ConnectAD ConnectThe AD Connect tool allows your on-premises AD to synchronize users, groups and contacts with your Azure Tenant directory. We will also configure AD Connect with Password Sync and Password write-back to allow users to reset their password from the Azure Tenant.Note: To complete this lab, you must have completed all the steps in the Setup/Pre-Requisite guide, including the "On-Premises" hydration and copying the Allfiles folder to the root of the C: drive on the DC1 VMTask Detailed StepsComplete these steps from an internet-connected Windows computer. Modify the domain password policyNote: We will be changing password at various times later in the course, and we need to relax the default policy somewhat. In any case this is the right moment to consider that when we sync our passwords, we may need to reconsider password polices.Open Internet Explorer and navigate to , signing in as admin@<YourDomain>Select VIRTUAL MACHINES from the navigation bar on the left and connect to DC1 as Corp\LabAdmin with the password pass@word1On DC1 VM navigate to and open Group Policy ManagementExpand Forest: corp.<YourDomain>.<xxx>, expand Domains, expand corp.<YourDomain>.<xxx>, right-click Default Domain Policy and select Edit…Under Computer, expand Policies, Windows Settings, Security Settings, Account Policies and select Password PolicyDouble-click the Mininum password age setting and deselect Define this policy settingClick Apply (so it is deselected) then click OK twiceClose the Group Policy toolInstall AD Connect On DC1Navigate to C:\AllFiles and run AzureADConnect.msiNote: This is a version that has been tested in our environment. You can get the latest version at , but note that options may have been added or removed, and so you may find the lab steps don’t work exactly.Click I agree to the license terms and privacy notice and ContinueClick Use express settings (the custom settings allow you to specify a location, an existing SQL Server, and existing service account and customer sync groups)Enter your Azure AD Credentials: admin@<YourDomain>.<xxx>Enter your AD DS credentials: CORP\LabAdminClick InstallWhen it finishes, click ExitVerify the sync is workingOn DC1Launch Internet Explorer (from within DC1 or wherever) and navigate to Provide your global admin credentialsSelect Active Directory in the left navigation barClick Contoso... and click USERS you will see in addition to the users you already had, there are now lots more that have been synchronized from your on-premises AD (sourced from Local Active Directory), along with your existing cloud-based users – these have user name like @<YourDomain>.<xxx>Note: The OU hierarchy has not come across. Azure AD does not have an OU hierarchy like AD DS – this is flat directory. Click GROUPS and notice that groups have also been synchronized (again source from Local Active Directory)Enable password write-back and user write-backOn DC1Run Azure AD Connect (shortcut on the desktop)Select View current configuration and click NextReview the settings:We have a single forest FILTER OBJECTS TO SYNCHRONIZE BY GROUP is disabled which is why so many user accounts have been synchronizedPASSWORD WRITEBACK is disabled meaning that while ADDS password changes are propagated to AAD, the reverse is not trueUSER WRITEBACK is disabled meaning that while ADDS users will be created in Azure AD and their attribute synchronized, the reverse is not trueClick PreviousNote: The Configure staging mode option allows you to configure an additional “warm stand-by” AD Connect alongside a production instance. It runs the import steps but never the export steps of synchronization and so is ready to take over on failure of the live AD Connect server.Select Customize synchronization options and click NextEnter your AAD Global Admin credentials and click NextEnter your ADDS credentials noting that you could add further directories here – but click NextSelect Password writeback (so that self-service password reset in Azure AD will writeback to AD) and User writeback and click NextNote: We are choosing user writeback more out of curiosity than anything – we don’t need it for our scenario. Some versions of AD Connect do not have this option.You must select corp (your only domain in your only forest) and click NextNote: In a moment we will finish this wizard and AD Connect will resynchronize having enabled user writeback but this can only work if the account being used by AD Connect has the permissions to manage users in AD. That account was created by the AD Connect install and is called MSOL_something.Run Active directory Users and Computers right click your domain (corp.<YourDomain>.<xxx>) and select Delegate Control… Click Next click Add… type MSOL and click Check Names Click OK and NextSelect Create, delete, and manage user accounts and click Next and FinishBack in the Azure AD Connect wizard click InstallOnce synchronization is complete click ExitOpen Active Directory Users and Computers you should find that all the cloud only users created in Azure AD now exist in AD (at the top level of the OU structure)Note: We will see the effect of password write-back later.Note: Changes made to the cloud users in AD will not be reflected in Azure AD because Azure AD is authoritative for them – in fact changes to synchronized attributes will actually be reversed with the Azure AD values overwriting the locally edited AD values for such users. The converse is true in that AD takes precedence for locally created users, but with the difference that the newer Azure AD interface knows this and presents synchronized attributes as read-only.Switch off USER WRITEBACK (if you were able to switch it on)Note: We don’t need this, and it may not have been available anyway. So having seen what it does we will turn it off so as not to complicate any other labs.Run Azure AD Connect (shortcut on the desktop)Select Customize synchronization options and click NextEnter your credentials and click NextEnter your ADDS credentials and click NextDeselect User writeback, click Next and click InstallClick ExitModify the AD Connect settings to filter by OUWe will assume that we only need the objects in the Corporate OU to be synchronized.Log off DC1, which will close the RDP connection and again connect up to DC1 as Corp\LabAdmin and password pass@word1 – we need to do this so that the LabAdmin account picks up the ADSyncAdmins security group SID – this was created as part of the Azure AD Connector installStill on DC1, click Start, click Search in the top-right of the screen, type Sync and then click Synchronization Service to open the Synchronization Service ManagerNote: Those of you familiar with FIM 2010 (or indeed ILM 2007) will recognise this interface, which is a modified version of the FIM Synchronization Service Manager. Later versions of AD Connect may allow you to make this OU selection in its wizard.In the Synchronization Service Manager, click ConnectorsNote: You only have two connectors and rather than referring to them by name (which is unique to your configuration) we will refer to them as the Azure AD connector and the ADDS connector.Double-click the ADDS connectorClick Configure Directory Partitions, click Containers…When prompted, enter your admin credentials for the on-premises Active Directory forest and click OKIn the Select Containers dialog box, deselect the top-level container (DC=corp etc) and select Corporate (if you expand Corporate you will see that its sub-OUs are also selected) - these are the Organizational Units (OUs) you will synchronize with the cloud directory from now onClick OK twiceNote: Synchronization only takes place every 3 hours. Since we don’t want to wait for this we will do it manually.With the ADDS connector still selected click Run from the Actions menuWith Full Import selected, click OK and wait for the run profile to completeNote: You will see a lot of deletes being reported as we have asked it to ignore most of the OUs. Don’t worry nothing is actually going to be deleted in Active Directory, just in the Synchronization Service database and soon in Azure AD too.Again click Run from the Actions menu, this time select Full Synchronization, click OK and wait for the run profile to completeNote: A delta synchronization would have worked here too – but when changing the configuration it is arguably wise to synchronize everything. You will see a number of provisioning disconnects, which will shortly lead to actual deletion in the Azure AD. The export attributes flows are not flowing anything new, they are simply a by-product of doing a full synchronization.Select the Azure AD connector, select Run from the Actions menu, select Export, click OK and then wait for the run profile to completeNote: This is the point at which the deletions in Azure AD actually take place – and they are duly reported.Again click Run from the Actions menu, this time select Delta Import, click OK and wait for the run profile to completeNote: This is simply to confirm that the exports (Deletes) took place – eventually this would have happened anyway when the next 3 hourly synchronization takes place. The next step is similarly and arguably an unnecessary nicety – but it does confirm that there are no further changes.Once again click Run from the Actions menu, this time select Delta Synchronization, click OK and wait for the run profile to completeIn Internet Explorer, navigate to the Azure portal if necessary and confirm that you have a more limited set of users (note the exception of the on-premises synchronization service account)Update a user to prepare for Attribute filteringOn DC1 in Active Directory Users and Computers, navigate to the Corporate OU and then the IT sub-OUIn the IT OU, right-click PeterH, click Properties, and type NoSync in the Description fieldClick OKConfigure the AD Connect rules to exclude users who match a defined criteriaClick Start, type Sync and (when the search completes) click Synchronization Rules EditorNote: There are two rule types: those that apply inbound to the synchronization service either from AD or AAD, and those that apply outbound from the synchronization service either to AD or AAD. It is beyond the scope of this course to explain what all these rules do. Microsoft in any case advise us not to modify these as a future update might overwrite our modifications – so we will aim not to modify these but rather to create a new rule which is in harmony with them.Select Outbound and find the rule called Out to AAD – User JoinNote: The LinkType is Provision – this is the rule that creates (provisions) users in AAD.Click Edit and then click Scoping filterNote: There is a clause that says cloudFiltered NOT EQUAL True – this rule will not apply to anyone for whom our new rule has set cloudFiltered to True. So if we create a new rule which sets CloudFiltered to True for some users, we can exclude them from provision (and de-provision them if they have previously been provisioned).Click CancelSelect Inbound and click Add new ruleGive the rule the following name: In from AD – Set cloud filtered attribute In the Description field you can enter Will result in users with the description NoSync being filteredSet the following:Connected System - your AD connector (corp etc.) Connected System Object Type - User Metaverse Object Type - Person Link Type – JoinPrecedence – 60Click NextIn the Scoping filter section, click Add group, click Add clause and set the following:Attribute -DescriptionOperator - EQUALValue - NoSync Click NextClick NextClick Add transformation, and set the following:FlowType - ConstantTarget Attribute - cloudFilteredSource text - TrueClick Add to save the ruleApply the rule and verify that it workedIf necessary open the Synchronization Service Manager (click Start, type Sync)In Connectors, select the ADDS connector, and click Run from the Action menuClick Delta Import, and then click OK (we only need it to read the one change we have made to PeterH, so a Full Import is not required)Again click Run from the Actions menu, this time select Full Synchronization, click OK and wait for the run profile to complete (this results in a provisioning disconnect which will lead to a deletion in Azure AD)Select the Azure AD connector, and click Run from the Action menuSelect Export and then click OK – you see:One delete being exported (PeterH)A group being updated – click the Updates link, double-click the DN in the Object Details dialog and note that the membership of ALL IT has been modifiedNote: You will remember that the PeterH is in the IT department and hence is in the All IT ADDS group, but since he is being deleted from Azure AD, he must also be removed from the Azure group’s membership (without affecting the original ADDS group).Close any dialogsClick Run from the Action menu, select Delta Import and click OK (to confirm the export)Click Run from the Action menu, select Delta Synchronization and click OK (to ensure that any further changes are properly managed)In the Windows Azure Management Portal (in Internet Explorer) navigate to My Directory, click USERS and verify that Peter Houston has disappeared (you may need to refresh if you were already on that page)Click GROUPS, click All IT and verify that he is not in the All IT groupIn Active Directory Users and Computers, double-click PeterH, select the Member Of tab and verify that he is still a member of All ITClick CancelReversing the rule, apply and verify (but leaving it in place in case you need it again!)In the Synchronization Rules Editor select Inbound (if necessary), select your new rule In from AD – Set cloud filtered attribute and click EditClick Transformations, change True to False for your cloudFiltered transformation and click SaveIn Synchronization Service, in Connectors, select the ADDS connector, and run a Full Synchronization (to run the new rule against the existing data)Select the Azure AD connector, run an Export, followed by a Delta Import and Delta Synchronization Verify that PeterH has been reinstated in Azure AAD, and also in the All IT group ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download