Azure Files storage service

Tags

Azure Files service

Courtsey:gregpakes  Microsoft Blogs Technetblogs Azureblogs

http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx

http://www.gregpakes.co.uk/post/create-a-shared-drive-using-azure-files

http://blogs.technet.com/b/uspartner_ts2team/archive/2014/06/09/setting-up-a-file-share-for-the-new-azure-file-service.aspx

https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-files/

Create a shared drive using Azure Files

brief look at Azure Files.  Here is the summary provided by Microsoft.

Windows Azure Files allows VMs in a Windows Azure Data Center to mount a shared file system using the SMB protocol. These VMs will then be able to access the file system using standard Windows file APIs (CreateFile, ReadFile, WriteFile, etc). Many VMs (or PaaS roles) can attach to these file systems concurrently, allowing you to share persistent data easily between various roles and instances. In addition to accessing your files through the Windows file APIs, you can access your data using the file REST API, which is similar to the familiar blob interface.

Signing up

At the time of writing, the Azure Files service is in preview and therefore must be activated for your account.  You can do this by going to the the preview page and clicking “Try it”.

During the activation, you are asked which subscription you wish to apply it to.  Then it is a waiting game.

The activation took 21 days! This process is obviously subject to change when the service moves out of beta.

The Scenario

In my case, I want to create a shared disk that is accessible from two VMs.

Creating a storage account

Once Azure Files is activated on your account any new Storage account you create will have it enabled automatically.  At the time of writing, I am not aware of a way to retroactively enable Azure Files on an existing storage account.

You can create the new Storage Account through the portal or through the APIs (http://msdn.microsoft.com/library/azure/ee460790.aspx).

When you create the account, you can check that Azure Files is enabled by logging into the portal and looking at the dashboard of the storage account.   Here you should see the Files endpoint enabled.

Creating the Share

Currently, you can only create the share through the PowerShell Cmdlets or through the API.  I decided to use PowerShell.

http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx

• Start by downloading the CmdLets from here.

Important: Make sure you right click the downloaded archive and unblock it from the properties before you extract it.

• Extract the Zip archive to a known location.  I chose c:PSAzureStorage
• Load PowerShell and run the following:

?

1 2 3 4 5 6

# import module and create a context for account and key import-module c:psAzureStorageazurestoragefileAzureStorageFile.psd1 $ctx=New-AzureStorageContext <account name> <account key>   # create a new share $s = New-AzureStorageShare <share name> -Context $ctx

• Replace the placeholder text with the following:
  • <account name> – This is the name of the storage account.  <account name>.file.core.windows.net.  In my case: azurefilesteststorage
  • <account key> – This can be found in the portal under Manage Access Keys.
  • <share name> – Replace this with the name of the share you wish to use.

That’s it – you now have a cloud accessible file share.

 

From Microsoft Blogs

PowerShell CmdLets

Download the latest version of Azure PowerShell (version 0.8.5 and later) and install it following the instructions here. Once completed, start the PowerShell prompt and execute the following.

# create a context for account and key

$ctx=New-AzureStorageContext <account name> <account key>

# create a new share

$s = New-AzureStorageShare <share name> -Context $ctx

# create a directory in the test share just created

New-AzureStorageDirectory -Share $s -Path testdir

# upload a local file to the testdir directory just created

Set-AzureStorageFileContent -Share $s -Source D:uploadtestfile.txt -Path testdir

# list out the files and subdirectories in a directory

Get-AzureStorageFile -Share $s -Path testdir

# download files from azure storage file service

Get-AzureStorageFileContent -Share $s -Path testdir/testfile.txt -Destination D:download

# remove files from azure storage file service

Remove-AzureStorageFile -Share $s -Path testdir/testfile.txt

Accessing from Windows

The next step is to access that share from remote locations.  To do this, I created an Azure Virtual Machine, but I could have easily used my own computer.

Load a command prompt and run the following:

 net use z: \<account name>.file.core.windows.net<share name> /u:<account name> <account key> 

Again, make sure you replace the placeholders with the appropriate values from above.  This command is the standard command for mapping a network drive.  Only this time, the drive is in Azure.

Do this on all the machines you wish to have access.

You can now access this drive just like any other network drive from This PC in Windows.

Performance

Obviously, the next step is to test performance.  The test is obviously restricted by the bandwidth on the machine, so I decided to use the Azure VM I created earlier.  As we all know, Azure datacenters have more bandwidth than god, but I must admit, the results below were quite surprising.

The transfer peaked at 60 MB/Sec write and 67 MB/sec read.  That is pretty impressive!  I decided to watch the network traffic whilst this was happening and took a snapshot.

As you can see, at the point in time the screenshot was taken, there was 557Mbps being received via the network adapter.  Seriously fast!

Note: The limiting factor of any speed test you do yourself, will be your internet connection.  The above was so fast because it was performed on an Azure VM.

Conclusion

Azure Files is a fantastic addition to the Azure family and is a feature that I can certainly think of some uses for.

Email Address is not caching in the outlook

Tags

Email Address is not caching in the outlook

The Auto-Complete list doesn’t remember names or email addresses

The Auto-Complete List is a feature which displays suggestions for names and email addresses as you start to type them. These suggestions are possible matches from a list of names and email addresses from the email messages that you have sent.

If names and email addresses that you enter aren’t saved to the Auto-Complete list, do the following:

Microsoft Exchange Server accounts

1. Prepare Outlook to run without Cached Exchange Mode.
   1. Click the File tab, and then click Account Settings.
   2. Click Account Settings.
   3. Click your Microsoft Exchange Server account, and then click Change.
   4. Clear the Use Cached Exchange Mode check box, click Next, and then click Finish.
   5. On the Account Settings dialog box, click Close.
2. Exit Outlook.
3. Open the %LOCALAPPDATA%MicrosoftOutlook folder.
   • Click Start, and then enter %LOCALAPPDATA%MicrosoftOutlook in the Search program and files or Start Search box. You can also copy and paste the location into Windows Explorer address bar.
4. Right-click the RoamCache folder, click Rename, and change the folder name to old_RoamCache.
5. Start Outlook.
6. Turn on Cached Exchange Mode.
   1. Click the File tab, and then click Account Settings.
   2. Click Account Settings.
   3. Click your Microsoft Exchange Server account, and then click Change.
   4. Select the Use Cached Exchange Mode check box, click Next, and then click Finish.
   5. On the Account Settings dialog box, click Close.
7. Exit and then restart Outlook.

Names or email addresses that are entered in the To, Cc, or Bcc boxes should be remembered after each message is sent. Those names and addresses are available as a suggestion the next time that you compose a message.

Top of Page

All other email accounts

1. Exit Outlook.
2. Open the %LOCALAPPDATA%MicrosoftOutlook folder.
   • Click Start, and then enter %LOCALAPPDATA%MicrosoftOutlook in the Search program and files or Start Search box. You can also copy and paste the location into Windows Explorer address bar.
3. Right-click the RoamCache folder, click Rename, and change the folder name to old_RoamCache.
4. Start Outlook.

Names or email addresses that are entered in the To, Cc, or Bcc boxes should be remembered after each message is sent. Those names and addresses are available as a suggestion the next time that you compose a message.

Microsoft Support Website

How to Add & Merge Calls on the iPhone to Create a Conference Call

Tags

How to make conference call in iPhone

Some iPhone users don’t realize the ability to make multi-party phone calls is built right into the iPhone software. To initiate a conference call check out the following steps:

&amp;amp;amp;amp;amp;amp;lt;img class=”aligncenter size-full wp-image-102421″ alt=”conference_call_how_to” src=”http://www.mactrast.com/wp-content/uploads/2013/07/conference_call_how_to.jpg” width=”420″ height=”240″ /&amp;amp;amp;amp;amp;amp;gt;

1. While on a phone call with the initial call participant, tap the ” + Add Call” button, then use your contacts list to find the number for the additional party you wish to include on the call. (Or you can simply dial the number of the new participant.)
2. The original caller will be placed on hold while the second number is called. Once you are connected to the second party, tap the “Merge Calls” button. This will add the new party to the initial phone conversation.
3. Repeat the above steps to add additional parties to the conference call.
4. If you’re already on a call and another party calls you, tap the “Hold and Answer” button that will pop up on the screen and then tap the “Merge Calls” button to add the new caller to the conference call.

Etisalat mobile call Conference link

 

 

Loopback processing in Group Policy- Folder redirection exclusion for certain PC

Tags

Folder redirection exclusion for certain PC, Loopback group policy

Here I am explaining the how loopback process configuration in Group Policy? if you have folder redirection policy enabled for all the users, this policy does not want to sync in certain computers in domain. you can use the below configuration for enable this policy.

 

For doing this we have to login to the Domain controller group policy management system In computer configuration Under Administrative Templates/System/Group Policy/Enable the Configure user Group Policy loopback processing mode.

Then come under the User configuration PoliciesWindows SettingsFolder redirectionDocuments (Properties)target select the basic -Redirect everyone’s folder to the same location. and the target folder location- Redirect to the local user profile location

In settings- grant user exclusive rights to Documents and policy removal- Leave the folder in the new location when policy removed.

Microsoft support link- https://support.microsoft.com/en-us/kb/328008

Disable the Group creation functionality in the Microsoft Office 365 tenancy

Tags

Office 365 private group disabling

Global administration of groups

One of the benefits of groups is that users self-organize and self-manage. But occasionally the global administrator needs to view, create, and delete groups, and add or remove group administrators or members. The group dashboard in the Office 365 admin center is the place to do this, and as the global administrator, you don’t have to be a group member.

Groups global administration
A group administrator can also disable group creation by using Windows PowerShell to update the mailbox policy and remove the ability to create groups. Because OWA policies are per user, you can even limit the ability to create groups for some users and not others.

In a computer with an Internet connection, open PowerShell, copy and paste the following:

$O365Cred = Get-Credential
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Enter your Office 365 credentials when prompted.
Open Command Prompt, type the following command below and press Enter:

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -GroupCreationEnabled $false

Azure ADSync Upgradation / Installation procedure

Tags

AD Premium, AD Premium configuration, ADSync installation with AD Premium

Microsoft TechNet blog, MStechtalk Part 4, MSTECHTALK PART3, MSTECHTALK PART5,MSTECHTALK PART 1,MSTECHTALK PART 2

If you want to install it on existing Dir Sync server. first you uninstall this application and install it.

 

Uninstallation Procedure

Uninstall DirSync in Control Panel. 

Click Start > Control Panel > Uninstall a program.

Find DirSync and then right click on it > click Uninstall to uninstall the program.

Close DirSync and its associated program.

Delete files and folders created by DirSync

Reboot the server

Download the latest AADSync from http://www.microsoft.com/en-us/download/details.aspx?id=44225

Installation Requirements

---

The objective of this section is to list the requirements that need to be fulfilled to install Azure AD Sync in your environment.
Azure AD Sync enables you to integrate your on-premises Active Directory Domain Service with your Azure AD directory.
As a consequence of this, you need access to your on-premises Active Directory Domain Service as well as access to a valid Azure subscription that has an Azure AD directory installed.

To install Azure AD Sync, you need a computer running the Windows Server operating system.
The following versions are supported:

• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012
• Windows Server 2012 R2

Your computer can be stand-alone, a member server or a domain controller.
The following components need to be installed:

• .Net 4.5.1
• PowerShell (PS3 or better is required)

You need an account with local administrator privileges on your computer to install Azure AD Sync.

Azure AD Sync requires a SQL Server database to store identity data. By default a SQL Express LocalDB (a light version of SQL Server Express) is installed and the service account for the service is created on the local machine.
SQL Server Express has a 10GB size limit that enables you to manage approximately 100.000 objects.

If you need to manager a higher volume of directory objects, you need to point the installation process to a different version of SQL Server.
AAD Sync supports all flavors of Microsoft SQL Server from SQL Server 2008 to SQL Server 2014.

Before You Begin

---

You must have the following steps completed before you can install Azure AD Sync:

1. Create an AD account to connect to AD DS
2. Create an account to connect to Azure AD

The following sections provide the related steps.

 

Create an AD account to connect to AD DS

---

When you configure Azure AD Sync, you need to provide the credentials of an account that is used by Azure AD Sync to connect to your AD DS.
You can use a regular user account because the account only needs the default read permissions.

The following sections provide more details about the permissions required by the AD DS account and the attributes it needs access to.

Permissions for password synchronization

---

If you want to enable password synchronization between your on-premises AD DS and your Azure Active Directory for your users, you need to grant the following permissions to the account that is used by Azure AD Sync to connect to your AD DS:

• Replicating Directory Changes
• Replicating Directory Changes All

Both permissions are required to enable the account to read password hashes from your on-premises AD DS.

Office 365 Exchange Hybrid AAD Sync write-back attributes and permissions.

---

If you want to enable rich co-existence between your on-premises Exchange infrastructure and Office 365 (Exchange Hybrid), you can do this by selecting the Exchange hybrid deployment optional feature. When selecting this feature, you enable AAD Sync to write-back attributes to your on-premises environment.

The following table lists the attributes per object type that require write-back:

Object Type	Data source Attribute
Contact	proxyAddresses
Group	proxyAddresses
User/InetOrgPerson	msExchArchiveStatus
	msExchBlockedSendersHash
	msExchSafeRecipientsHash
	msExchSafeSendersHash
	msExchUCVoiceMailSettings
	msExchUserHoldPolicies
	proxyAddresses

The account you configure in the Connect to Active Directory Domain Services dialog page needs to have specific permissions to the attributes above.

The following table lists the minimum set of permissions that are required for this account using DSACLS nomenclature.

Object Type	Data source Attribute	Permission / Access Right	Inheritance
Contact	proxyAddresses	Write	The child objects only
Group	proxyAddresses	Write	The child objects only
User/InetOrgPerson	msExchArchiveStatus	Write	The child objects only
	msExchBlockedSendersHash	Write	The child objects only
	msExchSafeRecipientsHash	Write	The child objects only
	msExchSafeSendersHash	Write	The child objects only
	msExchUCVoiceMailSettings	Write	The child objects only
	msExchUserHoldPolicies	Write	The child objects only
	proxyAddresses	Write	The child objects only

Password write-back and change password permissions.

---

The password write-back feature provides your users with a convenient method to reset their on-premises passwords in the cloud. During the configuration of Azure AD Sync, you can activate password write-back as optional feature.

For each forest you have configured in Azure AD Sync, the account you have specified for a forest in the wizard must be given the “Reset-Password” and “Change Password” extended rights on the root object of each domain in the forest. The right should be marked as inherited by all user objects.

Use the following procedure to setup permissions on each of the accounts you have configured.

How configure “Reset Password” and “Change Password” extended rights

---

1. Open Active Directory Users and Computers
2. At the top, under View make sure that Advanced Features are turned on.
3. On the left, right-click the root domain and select Properties.
4. Select the Security tab and click Advanced.
5. On the Permissions tab, click Add.
6. Click Select a Principal and select the account that was specified during setup.
7. In the drop-down, select Descendant User objects.
8. In the Permissions section select Reset Password and Change Password.
9. Click Ok. Click Apply. Click Ok.

 

Create an account to connect to Azure AD

---

When you configure Azure AD Sync, you need to provide the credentials of an account that is used by Azure AD Sync to connect to your Azure AD.

You should apply the following best practices to this account:

• You should create a separate account that is only used by Azure AD Sync.
• You should configure the account with a strong password that is 16 characters long.
• You should set the “Password never expires” flag on the account.
  To accomplish this task, you can use the following PowerShell script code:
  Copy

  set-msoluser -UserPrincipalName syncaccount@contoso.com -PasswordNeverExpires $True
  

• Your account must have Global Administrator as Organizational Role selected.

Installing and configuring Azure AD Sync

---

You can download the most recent version of Azure AD Sync using the following link: http://go.microsoft.com/fwlink/?LinkId=511690

To start the installation process, launch the executable called MicrosoftAzureADConnectionTool.exe.
This self-extracting executable puts all required files on the local drive and starts the installation process.
If you cancel the installation procedure, a shortcut is being created in the start menu and on the desktop.

If you need to use SQL Server or a domain account for the service account you need to cancel the wizard now. Up to this point, the installation process has already created a local folder that includes Azure AD Sync related files. You need the content of this folder to rerun the installation process with parameters.

To rerun the installation process, perform the following steps:

---

1. Open a command prompt, and then go to C:Program FilesMicrosoft Azure AD Connection Tool.
2. Start the wizard again with the following parameters:
   Copy

   DirectorySyncTool.exe /sqlserver localhost
                         /sqlserverinstance InstanceName
                         /serviceAccountDomain Azure AD Sync
                         /serviceAccountName Azure AD SyncSvc
                         /serviceAccountPassword VerySecretP@ssw0rd
   

   Note
   If you want to use the default SQL partition, then don’t specify this parameter.

At this point, you are ready to complete the dialog pages that are associated with the installation process.

To install the Azure AD Sync tool, you need to complete the following dialog pages:

1. Install
2. Connect to Azure Active Directory
3. Connect to Active Directory Domain Services
4. Configure User Matching
5. Optional features
6. Azure AD Apps
7. Azure AD attributes
8. Ready to configure
9. Finished

 

Install

---

As a first step of the installation process, you need to agree to the license terms and conditions and you need to specify the location of the Azure AD Sync.

 

Connect to Azure Active Directory

---

To connect to your Azure AD directory, the Azure AD Sync tool needs the credentials of an account with sufficient permissions.

For more details, see Create an account to connect to Azure AD.

 

Connect to Active Directory Domain Services

---

To connect to your Active Directory Domain Service, the Azure AD Sync tool needs the credentials of an account with sufficient permissions.For more details, see Create an AD account to connect to AD DS.

 

Configure User Matching

---

On this page, you need to configure the following:

1. Matching across forests
2. Matching with Azure AD

 

Matching across forests

---

The Matching across forests feature allows you to define how users from your ADDS forests are represented in Azure AD.
A user might either be represented only once across all forests or have a combination of enabled and disabled accounts.

Setting	Description
My users are only represented once across all forests	All users are created as individual objects in Azure AD. The objects are not joined in the metaverse.
Mail attribute	This option joins users and contacts if the mail attribute has the same value in different forests. It is recommended to use this option when your contacts have been created using GALSync.
ObjectSID and msExchangeMasterAccountSID	This option joins an enabled user in an account forest with a disabled user in an Exchange resource forest. This is also known as linked mailbox in Exchange.
sAMAccountName and MailNickName	This option joins on attributes where it is expected the login ID for the user can be found.
My own attribute	This option allows you to select your own attribute. Limitation in CTP: Make sure to pick an attribute which will already exist in the metaverse. If you pick a custom attribute the wizard will not be able to complete.

 

Matching with Azure AD

---

You can use this option to specify the attribute you want to use for identity federation. The sourceAnchor attribute is an attribute which is not changing during the lifetime of a user object. In single-forest and environments and where the account is never moved between forests, then objectGUID is a good candidate. If the user is moved between forests or domains, then an alternative attribute must be selected.

The userPrincipalName attribute is the user’s login ID in Azure AD. By default the userPrincipalName attribute in ADDS is used. If this attribute is not routable or not suitable as the login ID a different attribute, such as mail, can be selected in the installation guide.

 

Optional features

---

If you have an Exchange hybrid deployment, then select this checkbox. This will write-back some attributes from Exchange online to the on-premises Active Directory.Password write-back is an Azure Active Directory Premium feature. For more information on how to configure this, please see http://blogs.technet.com/b/ad/archive/2014/04/29/deep-dive-password-reset-with-on-premise-sync-in-azure-ad-premium.aspx.

If you want to review or limit the attributes which are synchronized with Azure AD, then select Azure AD app and attribute filtering. You will then get two additional pages in the wizard.

For more information about password synchronization, see Implement password synchronization with Azure Active Directory Sync

 

Azure AD Apps

---

If you want to limit which attributes to synchronize to Azure AD, then start by selecting which services you are using, If you configure this page, any new service has to be selected explicitly by re-running the installation guide.

 

Azure AD attributes

---

Based on the services selected in the previous step, this page will show all attributes which will be synchronized. This list is a combination of all object types being synchronized. If there are some particular attributes you need to not synchronize, you can unselect those. In the picture above the extensionAttributes and homePhone has been unselected and will not synchronize to Azure AD.

 

Ready to configure

---

This page provides you with summary of your configuration. You should carefully review this summary before you proceed with the next page.If this step fails with an “Unable to communicate with the Windows Azure Active Directory service” error and you have a proxy server configured, you should add proxy settings to the “machine.config” file of your Azure AD Sync computer.
For more details, see <proxy> Element (Network Settings).

 

Finished

---

A default configuration has now been created and if you are ready to start synchronizing, then click Finish.
If you need to make some additional configuration before you start synchronization, then unselect the Synchronize now checkbox before you click Finish. This will create a disabled task in task scheduler. When you are done with your configuration, start the periodic synchronization by enabling this task.

 

 

After completing uncheck the synchronize now option.

Run a full Sync using C:Program FilesMicrosoft Azure AD SyncBin>DirectorySyncClientCmd.exe initial

Sync Successful

Azure AD Full Synchronization

We’ve a utility called DirectorySyncClientCmd.exe which executes the sequence of actions to synchronize on prem identities with office 365.

To run a full synchronization browse to “C:Program FilesMicrosoft Azure AD SyncBinDirectorySyncClientCmd.exe initial

It’s recommended that you perform a full synchronization after making a major change in your Azure AD Sync configuration like enabling password synchronization for user.

Azure AD Delta Synchronization

To perform the delta synchronization with Office 365, we need the same executable to perform delta synchronization of users from on prem to office 365. By default Azure AD Sync tool performs delta sync after every 3 hours. Later in this article we’ll learn on how we can change the default sync time of the tool.

C:Program FilesMicrosoft Azure AD SyncBinDirectorySyncClientCmd.exe delta

Important Monitoring  Event viewer ID  from Azure ADSync server

Here Event ID 31005 onboarding completed means success

Another event ID -656 which is for the user password change request

Another event ID – 31007, this is for the Change password Success

Another event ID- 31002, this is for the password reset success.

After the Success configuration we need to  configure in Azure AD Portal

Login to Azure AD Portal you should have Enterprise mobility suite for enabling the Password reset option.

Azure Active Directory editions

Microsft tech net Blog

Azure Active Directory is a service that provides comprehensive identity and access management capabilities in the cloud. It combines directory services, advanced identity governance, application access management and a rich standards-based platform for developers. For more information, see this video.

Built on top of a large set of free capabilities in Microsoft Azure Active Directory, Azure Active Directory Premium and Basic editions provide a set of more advanced features to empower enterprises with more demanding identity and access management needs. For the pricing options for these editions, see Azure Active Directory Pricing. When you subscribe to Azure, you get your choice of the following free and paid editions of Azure Active Directory:

• Free – With the Free edition of Azure Active Directory, you can manage user accounts, synchronize with on-premises directories, get single sign on across Azure, Office 365, and thousands of popular SaaS applications like Salesforce, Workday, Concur, DocuSign, Google Apps, Box, ServiceNow, Dropbox, and more.
• Basic – Azure Active Directory Basic edition provides application access and self-service identity management requirements for task workers with cloud-first needs. With the Basic edition of Azure Active Directory, you get all the capabilities that Azure Active Directory Free has to offer, plus group-based access management, self-service password reset for cloud applications, Azure Active Directory application proxy (to publish on-premises web applications using Azure Active Directory), customizable environment for launching enterprise and consumer cloud applications, and an enterprise-level SLA of 99.9 percent uptime.An administrator with Azure Active Directory Basic edition can also activate an Azure Active Directory Premium trial.
• Premium – With the Premium edition of Azure Active Directory, you get all of the capabilities that he Azure Active Directory Free and Basic editions have to offer, plus additional feature-rich enterprise-level identity management capabilities explained below.

Azure Active Directory Premium and Azure Active Directory Basic are not currently supported in China. Please contact us at the Azure Active Directory Forum for more

Azure Active Directory editions

Published: November 21, 2013

Updated: May 5, 2015

Applies To: Azure, Azure Active Directory, Office 365

Azure Active Directory is a service that provides comprehensive identity and access management capabilities in the cloud. It combines directory services, advanced identity governance, application access management and a rich standards-based platform for developers. For more information, see this video.

Built on top of a large set of free capabilities in Microsoft Azure Active Directory, Azure Active Directory Premium and Basic editions provide a set of more advanced features to empower enterprises with more demanding identity and access management needs. For the pricing options for these editions, see Azure Active Directory Pricing. When you subscribe to Azure, you get your choice of the following free and paid editions of Azure Active Directory:

• Free – With the Free edition of Azure Active Directory, you can manage user accounts, synchronize with on-premises directories, get single sign on across Azure, Office 365, and thousands of popular SaaS applications like Salesforce, Workday, Concur, DocuSign, Google Apps, Box, ServiceNow, Dropbox, and more.
• Basic – Azure Active Directory Basic edition provides application access and self-service identity management requirements for task workers with cloud-first needs. With the Basic edition of Azure Active Directory, you get all the capabilities that Azure Active Directory Free has to offer, plus group-based access management, self-service password reset for cloud applications, Azure Active Directory application proxy (to publish on-premises web applications using Azure Active Directory), customizable environment for launching enterprise and consumer cloud applications, and an enterprise-level SLA of 99.9 percent uptime.An administrator with Azure Active Directory Basic edition can also activate an Azure Active Directory Premium trial.
• Premium – With the Premium edition of Azure Active Directory, you get all of the capabilities that he Azure Active Directory Free and Basic editions have to offer, plus additional feature-rich enterprise-level identity management capabilities explained below.

To sign up and start using Active Directory Premium today, see Getting started with Azure Active Directory Premium.

Note
Azure Active Directory Premium and Azure Active Directory Basic are not currently supported in China. Please contact us at the Azure Active Directory Forum for more information.

Features in Azure Active Directory Basic

---

Active Directory Basic edition is a paid offering of Azure Active Directory and includes all of the features of the Free edition plus the following features:

• Company branding – To make the end user experience even better, you can add your company logo and color schemes to your organization’s Sign In and Access Panel pages. Once you’ve added your logo, you also have the option to add localized versions of the logo for different languages and locales.For more information, see Add company branding to your Sign In and Access Panel pages.
• Group-based application access – Use groups to provision users and assign user access in bulk to thousands of SaaS applications. These groups can either be created solely in the cloud or you can leverage existing groups that have been synced in from your on-premises Active Directory.For more information, see Assign access for a group to a SaaS application in Azure AD.
• Self-service password reset – Azure has always allowed directory administrators to reset passwords. With Azure Active Directory Basic, you can now reduce helpdesk calls when your users forget a password by giving all users in your directory the capability to reset their password, using the same sign in experience they have for Office 365.For more information, see Password Management in Azure AD.
• Enterprise SLA of 99.9% – We guarantee at least 99.9% availability of the Azure Active Directory Basic service.
• Azure Active Directory Application Proxy – Give your employees secure access to on-premises applications like SharePoint and Exchange/OWA from the cloud using Azure Active Directory.

Features in Azure Active Directory Premium

---

Active Directory Premium edition is a paid offering of Azure Active Directory and includes all of the features of the Free and Basic editions plus the following features:

• Self-service group management – Azure Active Directory Premium simplifies day-to-day administration of groups by enabling users to create groups, request access to other groups, delegate group ownership so others can approve requests and maintain their group’s memberships.For more information, see Self-service group management for users in Azure AD.
• Advanced security reports and alerts – Monitor and protect access to your cloud applications by viewing detailed logs showing more advanced anomalies and inconsistent access pattern reports. Advanced reports are machine learning-based and can help you gain new insights to improve access security and respond to potential threats.For more information, see View your access and usage reports.
• Multi-Factor Authentication – Multi-Factor Authentication is now included with Premium and can help you to secure access to on-premises applications (VPN, RADIUS, etc.), Azure, Microsoft Online Services like Office 365 and Dynamics CRM Online, and thousands of Non-MS Cloud services preintegrated with Azure Active Directory. Simply enable Multi-Factor Authentication for Azure Active Directory identities, and users will be prompted to set up additional verification the next time they sign in.For more information, see Adding Multi-Factor Authentication to Azure Active Directory.
• Microsoft Identity Manager (MIM) – Premium comes with the option to grant rights to use a MIM server (and CALs) in your on-premises network to support any combination of Hybrid Identity solutions. This is a great option if you have a variation of on-premises directories and databases that you want to sync directly to Azure Active Directory. There is no limit on the number of FIM servers you can use, however, MIM CALs are granted based on the allocation of an Azure Active Directory premium user license.For more information, see Deploy MIM 2010 R2.
• Enterprise SLA of 99.9% – We guarantee at least 99.9% availability of the Azure Active Directory Premium service.For more information, see Active Directory Premium SLA.
• Password reset with write-back – self-service password reset can be written back to on-premises directories.

Comparing Free, Basic, and Premium editions

---

Azure Active Directory Basic and Azure Active Directory Premium have more advanced capabilities to help streamline enterprise-level administrative tasks and make an administrator’s life easier. The following table describes common admin benefits and how signing up for Azure Active Directory Basic or Azure Active Directory Premium help simplify them.

	Features	Free edition	Basic edition	Premium edition
Common features	Directory as a service	Up to 500K objects1	No object limit	No object limit
	User and group management using UI or Windows PowerShell cmdlets
	Device registration
	Access Panel portal for SSO-based user access to SaaS and custom applications	Up to 10 apps per user2	Up to 10 apps per user2	No app limit
	User-based application access management and provisioning
	Self-service password change for cloud users
	Directory synchronization tool – For syncing between on-premises Active Directory and Azure Active Directory
Standard security reports
Premium and Basic features	High availability SLA uptime (99.9%)
	Group-based application access management and provisioning
	Customization of company logo and colors to the Sign In and Access Panel pages
	Self-service password reset for cloud users
	Application Proxy: Secure Remote Access and SSO to on-premises web applications
Premium-only feature	Self-service group management for cloud users
	Self-service password reset with on-premises write-back
	Microsoft Identity Manager (MIM) server licenses – For syncing between on-premises databases and/or directories and Azure Active Directory
	Advanced anomaly security reports (machine learning-based)
	Cloud app discovery
	Advanced application usage reporting
	Multi-Factor Authentication service for cloud users
Multi-Factor Authentication server for on-premises users

1 The 500k object limit does not apply for Office 365, Windows Intune or any other Microsoft online service that relies on Azure Active Directory for directory services.

2 With Azure Active Directory Free and Azure Active Directory Basic, end users who have been assigned access to each SaaS app, can see up to 10 apps in their Access Panel and get SSO access to them (assuming they have first been configured with SSO by the admin). Admins can configure SSO and assign user access to as many SaaS apps as they want with Free, however end users will only see 10 apps in their Access Panel at a time.

Features currently in public preview

---

The following features are currently in public preview and will be added soon:

• Administrative units: a new Azure Active Directory container of resources that can be used for delegating administrative permissions over subsets of users and applying policies to a subset of users.
• Add your own SaaS applications to Azure Active Directory.
• Azure Active Directory Connect Health: monitor the health of your on premises Active Directory infrastructure and get usage analytics.
• Password rollover for Facebook, Twitter, and LinkedIn. For more information, read this article.
• Dynamic group membership. For more information, see this article.
• Conditional Access: Multifactor Authentication per application.
• HR application integration: Workday
• Privileged Identity Management: Privileged identity management provides improved oversight to help meet service level agreements and regulatory compliance requirements.
• Self-service application requests: Administrators can provide a list of SaaS apps to users from which so that users can choose the ones they want to use, and the apps either will be available immediately or after approval.
• Azure reporting API: data for every security report of Azure Active Directory will be available to other monitoring or SIEM tools.

Step 1: Configure the password reset policy in Azure Active directory

Microsoft TechNet Blog

---

To configure user password reset policy, complete the following steps:

1. Open a browser of your choice and go to the Azure Management Portal.
2. In the Azure Management Portal, find the Active Directory extension on the navigation bar on the left hand side.
3. Under the Directory tab, click the directory in which you want to configure the user password reset policy, for example, Wingtip Toys.
4. Click the Configure tab.
5. Under the Configure tab, scroll down to the user password reset policy section. This is where you configure every aspect of user password reset policy for a given directory. This policy applies only to end users in your organization, not administrators. For security reasons, Microsoft controls the password reset policy for administrators. If you do not see this section, make sure that you have signed up for the Azure Active Directory Premium and Basic and assigned a license to the administrator account that is configuring this feature.
6. To configure the user password reset policy, slide the users enabled for password reset toggle to the yes setting. This reveals several more controls which enable you to configure how this feature works in your directory. Feel free to customize password reset as you see fit. If you’d like to learn more about what each of the password reset policy controls does, please see Self-service password reset in Azure AD: how to customize password reset to meet your needs.
7. After configuring user password reset policy as desired for your tenant, click the Save button at the bottom of the screen.

   Note
   A two challenge user password reset policy is recommended so that you can see how the functionality works in the most complex case.

   

Step 2: Add the contact data for your test user

---

You have several options on how to specify data for users in your organization to be used for password reset.

• Edit users in the Azure Management Portal or the Office 365 Management Portal
• Use AADSync to synchronize user properties into Azure AD from an on-premises Active Directory domain
• Use Windows PowerShell to edit user properties
• Allow users to register their own data by guiding them to the registration portal at http://aka.ms/ssprsetup
• Require users to register for password reset when they sign in to the Access Panel at http://myapps.microsoft.com by setting the Require users to register SSPR configuration option to Yes.

The following table outlines where and how this data is used during password reset and is designed to help you decide which of the above methods you want to use. This table also shows any formatting requirements for cases where you are providing data on behalf of users from input paths that do not validate this data.

To add user contact data via the User Registration Portal

---

1. In order to use the password reset registration portal, you must provide the users in your organization with a link to this page (http://aka.ms/ssprsetup) or turn on the option to require users to register automatically. Once they click this link, they are asked to sign in with their organizational account. After doing so, they see the following page:
2. Here, users can provide and verify their mobile phone or alternate email address. This is what verifying a mobile phone looks like.
3. After a user specifies this information, the page will update to indicate that the information is valid (it has been obfuscated below). By clicking the finish or cancel buttons, the user will be brought to the Access Panel.
4. Once a user verifies both of these pieces of information, his or her profile will be updated with the data he or she provided. In this example, the Office Phone number has been specified manually, so the user can also use that as a contact method for resetting his or her password.

Step 3: Reset your password as a user

---

Now that you’ve configured a user reset policy and specified contact details for your user, this user can perform a self-service password reset.

To perform a self-service password reset

---

1. If you go to a site like portal.microsoftonline.com, you’ll see a login screen like the below. Click the “can’t access your account” link to test the password reset UI.
2. After clicking “can’t access your account”, you are brought to a new page which will ask for a user ID for which you wish to reset a password. Enter your test user ID here, pass the captcha, and click “next”.
3. Since the user has specified an office phone, mobile phone, and alternate email in this case, you see that he has been given all of those as options to pass the first challenge.
4. In this case, choose to call the office phone first. Note that when selecting a phone-based method, users will be asked to verify their phone number before they can reset their passwords. This is to prevent malicious individuals from spamming phone numbers of users in your organization.
5. Once the user confirms their phone number, clicking call wall cause a spinner to appear and his or her phone to ring. A message will play once he or she picks up your phone indicating that the user should press “#” to verify his or her account. Pressing this key will automatically verify that the user possesses the first challenge and advance the UI to the second verification step.
6. Once you’ve passed the first challenge, the UI is automatically updated to remove it from the list of choices the user has. In this case, because you used your Office Phone first, only Mobile Phone and Alternate Email remain as valid options to use as the challenge for the second verification step. Click on the Email my alternate email option. After you have done that, pressing email will email the alternate email on file.
7. Here is a sample of an email that users will see – notice the tenant branding:
8. Once the email arrives, the page will update, and you’ll be able to enter the verification found in the email in the input box shown below. After a proper code is entered, the next button lights up, and you are able to pass through the second verification step.
9. Once you’ve met the requirements of the organizational policy, you are allowed to choose a new password. The password is validated based it meets AAD “strong” password requirements (Password policy in Azure AD), and a strength validator appears to indicate to the user whether the password entered meets that policy.
10. Once you provide matching passwords that meet the organizational policy, your password is reset and you can log in with your new password immediately.

To reset the password use direct link

https://passwordreset.microsoftonline.com

Blogs followed

Self-service password reset in Azure AD: how to customize password reset to meet your needs

Directory Integration Tools

FAQ/Troubleshooting for Azure AD password management

Self-service password reset in Azure AD: how to enable, configure, and test self-service password reset

Password writeback: how to configure Azure AD to manage on-premises passwords

FAQ/Troubleshooting for Azure AD password management

Self-service password reset in Azure AD: deployment and management best practices

 

 

 

 

 

 

 

 

 

How Single SIgn on (SSO) change back to Azure AD Password Sync

Tags

Azure ADSync, Federated Server Change back to password sync

Microsoft TechNet Blog

Azure Active Directory now supports Password Synchronization as both an alternative to Single Sign-On, as well as a temporary backup for your Single Sign-On experience.

Whereas you could previously only enable a user for Single Sign-On OR you could sync their password, we have now completed updates to the service so that you can be synchronizing passwords for your Federated Users, and if your on-premises Single Sign-On infrastructure becomes unavailable, you can switch to let users sign in with their synchronized passwords while you’re resolving those infrastructure problems!

Best of all, there is no need to update your DirSync if you’re already running Password Sync!

Important
Microsoft always strongly recommends you deploy your Single Sign-On infrastructure in a highly-available manner. This wiki does not change that recommendation. Guidance for planning your ADFS infrastructure may be found here . If you are using a 3rd party STS, please refer to that product’s respective documentation for guidance of appropriate scaled and redundant deployment topologies.

This article has been updated and will address two scenarios:

1. You’ve decided that you want to deploy Password Sync as a backup for your Single Sign-On infrastructure
2. You’ve decided that Password Sync is sufficient to meet your business scenario requirements and want to switch to use Password Sync exclusively.

Please see Implement Password Synchronization for how to deploy the Password Sync feature of the Azure Active Directory Sync tool.

This document only addresses the scenario of using Password Sync as a backup for SSO or migrating users from Federated Authentication to Managed Authentication with Password Sync.

Note
For feedback, click here

 

---

Timing Considerations

Changing a user’s authentication details can be a disruptive activity. As such, you should plan carefully and schedule the migration at a time that is least disruptive to the end-user(s) that are being affected. Additionally it can take up to 2 hours for the domain conversation from federated to standard authentication to be updated in the various systems.

 

Important
Password Synchronization is a one-way push of password hashes from your on-premises Active Directory to Azure Active Directory. You must ensure that your user’s password is sync’d before they attempt to login. Both Approaches provide guidance on how to do this.

 

↑ Back to top

---

Background

At General Availability, the Password Synchronization feature did not support the synchronization of passwords for users in a Federated namespace.

We have recently updated the service code to allow this.

This enables the added possibility of running Password Sync while using Single Sign-On, and temporarily switching over to use synchronized passwords for login if you experience availability issues with your SSO infrastructure!

Mixing Password Sync and Federated Authentication in the same tenant

Customers can have a mix of managed and federated namespaces within the same tenant.  For example, a customer with 3 domains (domain1.com, domain2.com, domain3.com) may elect to configure domain1.com and domain3.com for Password Sync, but continue to have domain2.com configured for federated authentication.  It is not supported to configure users within the same namespace for both federated authentication and password sync.  Similarly, a customer may enable

Deploying Password Sync as a backup for Single Sign-On

With this latest update, you may elect to deploy Password Sync to provide a backup solution for your Single Sign-On infrastructure.  To accomplish this task, simply deploy the Directory Sync tool and enable the Password Sync option  when prompted in the Configuration Wizard (if you haven’t already).  More information on the Implementing Password Sync can be found here .

If you are already running Password Sync, you don’t need to upgrade your DirSync tool to light up this feature!  Just make sure you run a full password sync now so that all of your users’ passwords are synchronized to the cloud.  You can trigger a full Password Sync to re-synchronize all DirSync’ing user passwords via the Set-FullPasswordSync cmdlet.  Documentation on how to use this password may be found here.

Temporarily Switching from Single Sign-On to Synchronizated Passwords for Sign-In

If your Single Sign-On infrastructure becomes unavailable, you can now “switch” to using the synchronized password hashes for user sign-in while you resolve your infrastructure incident on a per-domain basis.  Please refer to the “Entire Namespace Conversion” section below on how to do this.  Be sure to set -SkipUserConversion $true when calling the Convert-MsolDomainToStandard commandlet.

It is recommended that you do not change UserPrincipalNames or ImmutableIds after converting your domain to managed state (via the Convert-MsolDomainToStandard commandlet) for users that have been switched to use sync’d passwords.

In the case where such changes have been made, administrators will notice that these changes do not show up in the cloud – this is by design.

When you convert the domain back to a federated state, the changes will be processed per usual.

 

Important
Switching from Single Sign-On to use Synchronized Passwords for Sign-In is not instantaneous. Please see the Timing Considerations section below for guidance on when you should consider switching or waiting out the Single Sign-On outage window.

 

↑ Back to top

---

Switch to use Password Sync exclusively

If you have decided that you no longer wish to use Single Sign-On and that Password Synchronization will meet your business needs, you can switch to use Password Synchronization.  There are two approaches to accomplishing this task:

1. Incremental migration – consider this approach if you wish to test out password sync for some users in your company before switching a larger set of users.
2. Entire namespace conversion – consider this approach if you are ready to switch large sets of users from federated authentication to managed authentication with password sync.

 

Important
In both cases, you need to ensure that the user’s password is sync’d before the user logs in. You can accomplish this by running a full password sync prior to domain conversion, after domain conversion, or having the user will change their password on-premises to get their passwords consistent. See Stage 2 of either Approach outlined below for guidance on this.

 

Approach 1 – Incremental Migration

If you want to incrementally transition your users from Federated Authentication to Managed Authentication, you can do so by switching your users from a Federated Namespace to a Managed Namespace, then synchronizing the passwords for the converted users.

 

Important
Following this approach will change the namespace of the migrated user’s UserPrincipalName (the domain following the ‘@’ sign). This will potentially impact your users’ login experience. Be sure to notify your users that their login name has changed.

The procedure, at a high level, is as follows:

Stage 1 – Update the users to migrate

1. Update the user’s UserPrincipalName from a Federated to a Managed Namespace for the users you wish to migrate from federated to managed authentication.

   Do this in your on-premises Active Directory, then trigger a Directory Sync cycle to sync those changes to the cloud. 

   Note
   To trigger a Directory Sync manually, perform the following steps: Open PowerShell, and then type Import-Module DirSync Type Start-OnlineCoexistenceSync, and then press Enter

    

2. Verify the user’s UserPrincipalName has changed in the cloud.

   This can be done using the Get-MsolUser commandlet.

The Azure Active Directory Powershell Module and documentation on the commandlet set can be found here .

Stage 2 – Synchronize user passwords

After you have confirmed that your users’ UserPrincipalNames have been updated in the on-premises AD, have those users update their password in your on-premises Active Directory. This will trigger the password to synchronize to the cloud.

Once their password has been synchronized to the cloud, the user will be able to log into their cloud services using the same password as their on-premises password.

 

Approach 2 – Entire namespace conversion

Once a customer is ready to transition an entire namespace from Federated to Managed Authentication, they may follow this procedure to migrate all of their users from Federated Authentication to Managed Authentication.  This is the same procedure that should be used if converting a to Managed state while troubleshooting your on-premises Single Sign-On infrastructure.

Important

Users will not be able to log into the cloud with their on-premises password until Password Sync has successfully synchronized their passwords. This means that users will not be able to use the service during the period of time between Stage 1 completion and Stage 2 completion. It is important to schedule the conversion over a weekend (if this is a planned activity) or another time during which the user will not be disrupted while their credentials are being converted and password synchronized.

 

Stage 1 – Convert the namespace

Convert the desired namespace from Federated to Managed with the Convert-MsolDomainToStandard cmdlet.

Documentation on this commandlet can be found here: http://technet.microsoft.com/en-us/library/dn194122.aspx

Detailed steps are as follows:

1. Click Windows Azure Active Directory, right-click Windows Azure Active Directory Module for Windows PowerShell, and then click Run as administrator.
2. Run the following commands in the order in which they are presented. Press Enter after you type each command.
   1. $cred = Get-Credential

      When you are prompted, enter Office 365 administrator credentials that are not SSO-enabled.

   2. Connect-MsolService –credential $cred
   3. Set-MsolADFSContext –Computer <AD FS 2.0 server name> 
      

      Note
      In this command, the placeholder <AD FS 2.0 server name> represents the name of the primary AD FS 2.0 server. If the AD FS server is on a remote server you must set the AD FS server context, if the AD FS server is local you can skip this step.

       

   4. Convert-MSOLDomainToStandard –DomainName <federated domain name> -SkipUserConversion $false -PasswordFile c:userpasswords.txt
      

      Note

      Replace <federated domain name> represents the name of the domain you are converting. This command removes the Relying Party Trust information from the Office 365 authentication system federation service and the on-premises AD FS 2.0 federation service.  The -PasswordFile parameter indicates the path of the text file that contains the newly created temporary password of each formerly federated user’s account and must not exist before calling the cmdlet.

       

      Important

      If you are temporariliy switching to use synchronized passwords while you are repairing your SSO infrastructure, set –SkipUserConversion to be $true. If you are permanently decommissioning your SSO Infrastructure, set -SkipUserConversion to $false to ensure users are converted correctly Additionally if the AD FS server is not available because of a failure you can convert the domain to Standard using the Set-MsolDomainAuthentication cmdlet to set the authentication to managed.

You can confirm if all users are converted by running the cmdlet Convert-MSOLDomainToStandard a second time.  When run the second time, you must specify a different password file.  For users that have already be converted they will not be issued a new password. Similarly if you have problems with converting some users you can call the cmdlet Convert-MsolFederatedUser to convert a single user.

If required/desired you can manually convert all users in a domain by following the sample script below.

Stage 2 – Synchronize user passwords

At this point, if you have not previously run a full Password Sync, (or you first deployed Password Sync before May 1, 2014), you should trigger a full Password Sync to re-synchronize all DirSync’ing user passwords via the Set-FullPasswordSync cmdlet.  Documentation on how to use this password may be found here.

↑ Back to top

 

---

Verifying synchronized passwords

The simplest way to ensure that user passwords have successfully synchronized after being migrated to a Managed Namespace is to have the users try to log into the service.

If users are not able to sign into the cloud service, see Password synchronization troubleshooting guide for Office 365 for details on troubleshooting this issue.

↑ Back to top

 

---

Sample script to manually convert all users in a domain

The script below will enable you to convert all users in a domain to standard users.

Note that you must first convert the domain to standard before calling this procedure.

It is also recommend to start a transcript of the session to record the passwords for the users if needed.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019

Get-MsolUser?-All?-DomainName?[Domain?Name?to?Convert]?|?%?{? try?{ $Upn?=?$_.UserPrincipalName $pw?=?Convert-MsolFederatedUser?-UserPrincipalName?$Upn??ErrorAction??Stop?? $Upn?+?”`r`nt”?+?$pw $pw?=?”” } Catch?{ if?($_.FullyQualifiedErrorId?-like?’Microsoft.Online.Administration.Automation.UserAuthenticationUnchangedException*’){ $Upn?+?”`r`nt?User?already?converted” }?Else? { $Upn?+?”`r`nt?Exception?”?+?$_.FullyQualifiedErrorId? } $_.Clear } }

 

 

↑ Back to top

Azure AdSync password Sync FAQ

Tags

ADSync password FAQ, Azure ADSync

TechNet Blog , Azure AD Sync FAQ

By deploying password sync in your environment, you enable your users to use the same password they are using to logon to your on-premises Active Directory to logon to Azure Active Directory.

The objective of this topic is to provide you with the information you need to understand the password sync feature and how to enable it in your environment.

What is Password Sync

---

Password Sync is a feature of the Azure Active Directory Sync tool that synchronizes user passwords from your on-premises Active Directory to Azure Active Directory (“Azure AD”). This feature enables your users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into your on-premises network. It is important to note that this feature does not provide a Single Sign-On (SSO) solution because there is no token sharing / exchange in the Password Sync based process.

Note
Active Directory Domain Services that are configured for FIPS are not compatible with the Password Sync feature.

Availability of Password Sync

---

Any customer of Azure Active Directory is eligible to run Password Sync. See below for information on the compatibility of Password Sync and other features such as Federated Authentication.

You must be running version 6382.0000 or greater of the Directory Sync tool in order to enable the Password Sync feature (version is available on the .exe installer download). The latest version of the Directory Sync tool can be downloaded from the Admin Portal.

How Password Sync Works

---

Password Sync is an extension to the directory synchronization feature implemented by the Directory Sync tool. As a consequence of this, this feature requires directory synchronization between your on-premises and your Azure Active Directory to be configured.

The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to your on-premises network. It is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. The Password Sync feature checks every two minutes whether passwords need to be synchronized. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When you first enable the Password Sync feature in your DirSync tool, it will perform an initial synchronization of the passwords of all in-scope users from your on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in your event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. However, as soon as the cloud service attempts requires the user to re-authenticate, the new password needs to be provided. At this point, the user is required to provide the new password – the password that has been recently synchronized from the on-premise Active Directory to the cloud.

Security Considerations

---

When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services.

Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer’s on-premises environment.

Password Policy Considerations

---

There are 2 types of password policies that are affected by enabling password sync:

1. Password Complexity Policy
2. Password Expiration Policy

Password Complexity Policy

---

When you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users. This means any password that is valid in the customer’s on-premises Active Directory environment can be used for accessing Azure AD services.

Note
Passwords for users that are created directly in the cloud are still subject to password policies as defined in the cloud.

Password Expiration Policy

---

If a user is in the scope of the password sync feature, the cloud account password is set to “Never Expire”. This means that it is possible for a user’s password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password.

The cloud password will be updated the next time the user changes the password in the on-premises environment.

Password Sync and Federated Identities

---

The password sync feature will not synchronize passwords for users with Federated Identities. This has several implications:

• If an initially managed user with a password that has been synchronized to the cloud is converted to a federated user and then converted back to a managed user, the password that was initially synchronized is lost.
• If an initially federated user that has updated a password on-premises is converted to a managed user, the password will not be synchronized to the cloud. As a consequence of this, the user will not be able to use the password that has been set in the on-premises environment to log into cloud services.

Overriding Synchronized Passwords

---

An administrator can manually reset a user’s password using the Azure Active Directory PowerShell.

In this case, the new password will override the user’s synchronized password and all password policies defined in the cloud will apply to the new password.

If the user changes the on-premises password again, the new password will be synchronized to the cloud, and will override the manually updated password.

Preparing for Password Sync

---

Your Azure Active Directory tenant must be enabled for Directory Synchronization before the tenant can be enabled for Password Synchronization.

Enabling Password Sync

---

You enable Password Sync when running the Directory Sync tool Configuration Wizard.

When prompted by the Wizard, select the “Enable Password Synchronization” checkbox.

Note
This process will trigger a full synchronization. Full synchronization cycles generally take longer than other sync cycles to complete.

Managing Password Sync

---

You can monitor the progress of Password Sync through the event log of the machine that is running the Directory Sync tool.

Determining the Password Sync status

---

You can determine which users have successfully had their passwords synchronized by reviewing the events that match the following criteria:

Source	Event ID
Directory Synchronization	656
Directory Synchronization	657

The events with the Event ID 656 provide a report of processed password change requests:

The corresponding events with the ID 657 provide the result for these requests:

In the events, the affected objects are identified by their anchor and the DN value. The anchor value corresponds to the ImmutableId value that is returned for a user by the Get-MsoUser cmdlet.

In addition to the object identifiers, Event ID 656 provides the date the user’s password was changed in the on-premises Active Directory::

Event ID 657 has a Result field in addition to the source object identifiers to indicate the status of synchronization for that user object.

A successfully synchronized password is in an event with the Event ID 657 indicated by a value of Success for the Result attribute. When a password synchronization attempt failed, the value of the Result attribute is Failure:

Disabling Password Sync

---

You disable Password Sync by re-running the Directory Sync tool Configuration Wizard.

When prompted by the Wizard, de-select the “Enable Password Synchronization” checkbox.

Note
This process will trigger a full synchronization. Full synchronization cycles generally take longer than other sync cycles to complete.

After running the Configuration Wizard, your tenant will no longer be synchronizing passwords. New password changes will not synchronize to the cloud. Users that previously had their passwords synchronized will be able to continue logging in with those passwords until they manually change their passwords in the cloud.

How Azure AD Sync Password write back works

Tags

Azure AD sync Password write back configuratiion, Azure AD Sync password writeback

Password writeback: how to configure Azure AD to manage on-premises passwords

Updated: February 10, 2015

Use the links below to jump to the information about password writeback that interests you most.

• Password writeback overview
• How password writeback works
• How to enable/disable password writeback
• Troubleshooting password writeback

Password writeback overview

---

Password writeback is an Azure Active Directory Sync component that can be enabled and used by the current subscribers of Azure Active Directory Premium. For more information, see Azure Active Directory Editions. It allows you to configure your cloud tenant to write passwords back to you on-premises Active Directory. It obviates you from having to set up and manage a complicated on-premises self-service password reset solution, and it provides a convenient cloud-based way for your users to reset their on-premises passwords wherever they are. Read on for some of the key features of password writeback:

• Zero delay feedback. Password writeback is a synchronous operation. Your users will be notified immediately if their password did not meet policy or was not able to be reset or changed for any reason.
• Supports resetting passwords for users using AD FS or other federation technologies. With password writeback, as long as the federated user accounts are synchronized into your Azure AD tenant, they will be able to manage their on-premises AD passwords from the cloud.
• Supports resetting passwords for users using password hash sync. When the password reset service detects that a synchronized user account is enabled for password hash sync, we reset both this account’s on-premises and cloud password simultaneously.
• Supports changing passwords from the access panel and O365. When federated or password sync’d users come to change their expired or non-expired passwords, we’ll write those passwords back to your local AD environment.
• Supports writing back passwords when an admin reset them from the Azure Management Portal. Whenever an admin resets a user’s password in the Azure Management portal, if that user is federated or password sync’d, we’ll set the password the admin selects on your local AD, as well. This is currently not supported in the Office Admin Portal.
• Enforces your on-premises AD password policies. When a user resets his/her password, we make sure that it meets your on-premises AD policy before committing it to that directory. This includes history, complexity, age, password filters, and any other password restrictions you have defined in your local AD.
• Doesn’t require any inbound firewall rules. Password writeback uses an Azure Service Bus relay as an underlying communication channel, meaning that you do not have to open any inbound ports on your firewall for this feature to work, only 443 outbound.
• Is not supported for user accounts that exist within protected groups in your on-premises Active Directory. For more information about protected groups, see Appendix C: Protected Accounts and Groups in Active Directory.

How password writeback works

---

Password writeback has three main components:

• Password Reset cloud service (this is also integrated into Azure AD’s password change pages)
• Tenant-specific Azure Service Bus relay
• On-prem password reset endpoint

  

When a federated or password hash sync’d user comes to reset or change his or her password in the cloud, the following occurs:

1. We check to see what type of password the user has. If we see the password is managed on premises, then we ensure the writeback service is up and running. If it is, we let the user proceed, if it is not, we tell the user that their password cannot be reset here.
2. Next, the user passes the appropriate authentication gates and reaches the reset password screen.
3. The user selects a new password and confirms it.
4. Upon clicking submit, we encrypt the plaintext password with a public key that was created during the writeback setup process.
5. After encrypting the password, we include it in a payload that gets sent over an HTTPS channel to your tenant specific service bus relay (that we also set up for you during the writeback setup process). This relay is protected by a randomly generated password that only your on-premises installation knows.
6. Once the message reaches service bus, the password reset endpoint automatically wakes up and sees that it has a reset request pending.
7. The service then looks for the user in question by using the cloud anchor attribute. For this lookup to succeed, the user object must exist in the AD connector space, it must be linked to the corresponding MV object, and it must be linked to the corresponding AAD connector object. Finally, in order for sync to find this user account, the link from AD connector object to MV must have the sync rule “Microsoft.InfromADUserAccountEnabled.xxx” on the link. This is needed because when the call comes in from the cloud, the sync engine uses the cloudAnchor attribute to look up the AAD connector space object, then follows the link back to the MV object, and then follows the link back to the AD object. Because there could be multiple AD objects (multi-forest) for the same user, the sync engine relies on the “Microsoft.InfromADUserAccountEnabled.xxx” link to pick the correct one.
8. Once the user account is found, we attempt to reset the password directly in the appropriate AD forest.
9. If the password set operation is successful, we tell the user their password has been modified and that they can go on their merry way.
10. If the password set operation fails, we return the error to the user and let them try again. The operation might fail because the service was down, because the password they selected did not meet organization policies, because we could not find the user in the local AD, or any number of reasons. We have a specific message for many of these cases and tell the user what they can do to resolve the issue.

What scenarios are supported for password writeback?

---

The table below describes which scenarios are supported for which versions of our sync capabilities. In general, it is highly recommended that you install the latest version of AADSync if you want to use password writeback. You can find the latest version of AAD Sync at http://www.microsoft.com/en-us/download/details.aspx?id=44225.

Password writeback security model

---

Password writeback is a highly secure and robust service. In order to ensure your information is protected, we enable a 4-tiered security model that is described below.

• Tenant specific service-bus relay – When you set up the service, we set up a tenant-specific service bus relay that is protected by a randomly generated strong password that Microsoft never has access to.
• Locked down, cryptographically strong, password encryption key – After the service bus relay is created, we create a strong asymmetric key pair which we use to encrypt the password as it comes over the wire. The private key of this key pair lives only in your on-premises environment and Microsoft never has access to it. The public key gets placed into your tenant’s secret store in the cloud, which is a heavily locked down.
• Industry standard TLS – When a password reset or change operation occurs in the cloud, we take the plaintext password and encrypt it with your public key. We then plop that into an HTTPS message which is sent over an encrypted channel using Microsoft’s SSL certs to your service bus relay. After that message arrives into Service Bus, your on-prem agent wakes up, authenticates to Service Bus using the strong password that had been previously generated, picks up the encrypted message, decrypts it using the private key we generated, and then attempts to set the password through the AD DS SetPassword API. This step is what allows us to enforce your AD on-prem password policy (complexity, age, history, filters, etc) in the cloud.
• Message expiration policies – Finally, if for some reason the message sits in Service Bus because your on-prem service is down, it will be timed out and removed after several minutes in order to increase security even further.

How to enable/disable password writeback

---

This section walks you through configuring password reset to write passwords back to an on-premises Active Directory.

• Password writeback prerequisites
• Step 1: Install or upgrade Azure Sync Tool to version 1.0.0419.0911 or later
• Step 2: Enable password writeback on your Directory Sync computer & configure firewall rules
• Step 3: Ensure you have the proper permissions defined on your ADMA account for password writeback to occur
• Step 4: Reset your password as a user and verify it is written back to on-premises AD

Password writeback prerequisites

---

Before you can enable and use the password writeback, you must make sure you complete the following prerequisites:

• You have an Azure AD tenant with Azure AD Premium enabled. For more information, see Azure Active Directory Editions.
• Password reset has been configured and enabled in your tenant. For more information, see Self-service password reset in Azure AD: how to enable, configure, and test self-service password reset.
• You have at least one administrator account and one test user account with an Azure AD Premium license that you can use to test this feature. For more information, see Azure Active Directory Editions

  Important
  Make sure that the administrator account that you use to enable password writeback is a cloud administrator account (created in Azure AD), not a federated account (created in on-premises AD and synchronized into Azure AD.

• You have a single or multi-forest AD on-premises deployment running Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2 with the latest service packs installed.

  Note
  If you are running an older version of Windows Server 2008 or 2008 R2, you can still use this feature, but will need to install KB 2386717 before being able to enforce your local AD password policy in the cloud.

• You have the Azure AD Sync tool installed and you have prepared your AD environment for synchronization to the cloud. For more information, see Directory Integration Tools.
• If you are using DirSync, you must make sure your organization’s firewall is configured to block outbound connections. You must unblock TCP port 828 or 818 in order to enable and use the password writeback. If you are using AADSync, this step is not necessary, as only 443 TCP outbound needs to be open.

Step 1: Install or upgrade Azure Sync Tool to version 1.0.0419.0911 or later

---

Password writeback is available in releases of the Azure AD Sync Tool with version number 1.0.0419.0911 or higher.  Password writeback with automatic account unlock is available in releases of the Azure AD Sync Tool with version number 1.0.0485.0222 or higher. If you are running an older version, please upgrade to at least this version before proceeding. Download the latest version of Azure AD Sync.

To check your Directory Sync Tool version number

---

1. Navigate to %ProgramFiles%Azure Active Directory Sync.
2. Find the ConfigWizard.exe executable.
3. Right-click the executable and select the Properties option from the context menu.
4. Click on the Details tab.
5. Find the File version field.

   

If this version number is greater than or equal to 1.0.0419.0911, you can skip to Step 2: Enable password writeback on your Directory Sync computer & configure firewall rules. If you have never installed AADSync before, then here are some resources you can use to learn about pre-requirements for setting up sync:

1. If this is your first time installing the Azure AD Sync Tool, it is recommended that you follow a few best practices to prepare your environment for directory synchronization. Before you install the Azure AD Sync Tool, you must activate directory synchronization in either the Office 365 or the Azure management portals. For more information, see Azure Active Directory Sync.

Step 2: Enable password writeback on your Directory Sync computer & configure firewall rules

---

Now that you have the Azure AD Sync tool downloaded, you are ready to enable password writeback. You can do this in one of two ways. You can either enable password writeback in the optional features screen of the Azure AD Sync setup wizard, or you can enable it via Windows PowerShell.

To enable password writeback using the Azure AD Sync setup wizard

---

1. On your Directory Sync computer, open the Azure AD Sync configuration wizard.
2. Click through the steps until you reach the optional features configuration screen.
3. Check the Password write-back option.

   

4. Complete the wizard, the final page will summarize the changes and will include the password writeback configuration change.
5. Once installation is complete, if you are blocking unknown outbound connections in your environment, you will also need to add the following rules to your firewall. Make sure you reboot your AADSync machine after making these changes:
   1. Allow outbound connects over port 443 TCP
   2. Allow outbound connections to https://ssprsbprodncu-sb.accesscontrol.windows.net/

      Note
      You can disable password writeback at any time by either re-running this wizard and deselecting the feature, or by setting the Write Passwords Back to On-Premises Directory setting to No in the User Password Reset Policy section of your directory’s Configure tab in the Azure Management Portal.

To enable password writeback using Windows PowerShell

---

1. On your Directory Sync computer, open a new elevated Windows PowerShell window.
2. If the module is not already loaded, type in the Import-Module ADSync command to load the AAD Sync cmdlets into your current session.
3. Get the list of AAD Connectors in your system by running the Get-ADSyncConnector cmdlet and storing the results in $aadConnectorName
4. To get the current status of writeback for the current connector by running the following cmdlet: Get-ADSyncAADPasswordResetConfiguration –Connector $aadConnectorName.
5. Enable password writeback by running the cmdlet: Set-ADSyncAADPasswordResetConfiguration –Connector $aadConnectorName –Enable $true
6. Once installation is complete, if you are blocking unknown outbound connections in your environment, you will also need to add the following rules to your firewall. Make sure you reboot your AAD Sync machine after making these changes:
   1. Allow outbound connections over port 443 TCP
   2. Allow outbound connections to https://ssprsbprodncu-sb.accesscontrol.windows.net/

      Note
      If prompted for a credential, make sure that the administrator account that you specify for AzureADCredential is a cloud administrator account (created in Azure AD), not a federated account (created in on-premises AD and synchronized into Azure AD.

      Note
      You can disable password writeback through PowerShell by repeating the same instructions above but passing $false in step or by setting the Write Passwords Back to On-Premises Directory setting to No in the User Password Reset Policy section of your directory’s Configure tab in the Azure Management Portal.

Verify that the configuration was successful

Once the configuration succeeds, you will see the message Password reset write-back is enabled in the Windows PowerShell window. You can verify the service was installed correctly by opening Event Viewer, navigating to the application event log, and looking for event 31005 – OnboardingEventSuccess from the source PasswordResetService.

For troubleshooting information and FAQ information, see “Troubleshoot Password Writeback” and “Password Writeback On-premises Event Log Error Codes” sections in FAQ/Troubleshooting for Azure AD password management.

Step 3: Ensure you have the proper permissions defined on your ADMA account for password writeback to occur

---

For every forest that contains users whose passwords will be reset, if X is the account that was specified for that forest in the configuration wizard (during initial configuration), then X must be given the Reset Password, Change Password, Write Permissions on “lockoutTime”, and Write Permissions on “pwdLastSet”, extended rights on the root object of each domain in that forest. The right should be marked as inherited by all user objects.

Setting these permissions will allow the MA service account for each forest to manage passwords on behalf of user accounts within that forest. If you neglect to assign these permissions, then, even though writeback will appear to be configured correctly, users will encounter errors when attempting to manage their on-premises passwords from the cloud. Here are the detailed steps on how you can do this using the Active Directory Users and Computers management snap-in:

Note
it could take up to an hour for these permissions to replicate to all objects in your directory.

1. Open Active Directory Users and Computers with an account that has the appropriate domain administration permissions.
2. In the View Menu option, make sure Advanced Features is turned on.
3. In the left panel, right click the object that represents the root of the domain.
4. Click on the Security tab.
5. Then click Advanced.

   

6. On the Permissions tab, click Add.

   

7. Select the account you want to give permissions to (this is the same account that was specified while setting up sync for that forest).
8. In the drop down on the top, select Descendent User objects.
9. In the Permission Entry dialog box that shows up, check the box for Reset Password, Change Password, Write Permissions on “lockoutTime”, and Write Permissions on “pwdLastSet”.

   

10. Then click Apply/Ok through all the open dialog boxes.

Step 4: Reset your password as a user and verify it is written back to on-premises AD

---

Now that password writeback has been enabled, you can test that it works by resetting the password of a user whose account has been synchronized into your cloud tenant.

1. Navigate to http://passwordreset.microsoftonline.com or go to any organizational ID login screen and click the Can’t access your account? link.

   

2. You should now see a new page which asks for a user ID for which you want to reset a password. Enter your test user ID and proceed through the password reset flow.
3. After you reset your password, you will see a screen that looks similar to this. It means you have successfully reset your password in your on-premises and/or cloud directories.

   

4. To verify the operation was successful, go to your Directory Sync computer, open Event Viewer, navigate to the application event log, and look for event 31002 – PasswordResetSuccess from the source PasswordResetService for your test user.

   

Troubleshooting password writeback

---

For troubleshooting information and FAQ, see “Troubleshoot Password Writeback” and “Password Writeback On-premises Event Log Error Codes” sections in FAQ/Troubleshooting for Azure AD password management.

Three types of sign-in model for Office 365

Tags

Office 365, Office 365 Sign in types, Three types of sign-in model for Office 365

Courtsey – office 365 Blog

Scenario 4. You have multiple forests in your on-premises Active Directory under Technical requirements has been updated.

We get a lot of questions about which of the three identity models to choose with Office 365. Which of these models you choose will impact where you manage your user accounts for Office 365 and how those user sign-in passwords are verified. In this post I’ll describe each of the models, explain how to move between them, and provide guidance on how to choose the right one for your needs.

Three identity models for Office 365

In the diagram above the three identity models are shown in order of increasing amount of effort to implement from left to right. Our recommendation for successful Office 365 onboarding is to start with the simplest identity model that meets your needs so that you can start using Office 365 right away. Then, as you determine additional necessary business requirements, you can move to a more capable identity model over time. The way to think about these is that the Cloud Identity model is the simplest to implement, the Federated Identity model is the most capable, and the Synchronized Identity model is the one we expect most customers to end up with. Let’s look at each one in a little more detail.

Cloud Identity. In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.

Synchronized Identity. In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).

Federated Identity. This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.

You can switch between the models

We recommend that you use the simplest identity model that meets your needs. If your needs change, you can switch between these models easily. Here’s a description of the transitions that you can make between the models.

Cloud Identity to Synchronized Identity. This transition is simply part of deploying the DirSync tool. You may have already created users in the cloud before doing this. If you switch from the Cloud Identity model to the Synchronized Identity model, DirSync and Azure Active Directory will try to match up any existing users. There are two ways that this user matching can happen. The first one occurs when the users in the cloud have previously been synchronized from an Active Directory source. In this case they will have a unique ImmutableId attribute and that will be the same when synchronization is turned on again. Users with the same ImmutableId will be matched and we refer to this as a “hard match.”

The second way occurs when the users in the cloud do not have the ImmutableId attribute set. In this case we attempt a “soft match,” which looks at the email attributes of the user to find ones that are the same. If we find multiple users that match by email address, then you will get a sync error. If you want to be sure that users will match using soft-match capabilities, make sure their PrimarySMTP addresses are the same both in Office 365 and in the on-premises Active Directory. If all of your users are entered in the cloud but not in your Active Directory, you can use PowerShell to extract them and then you can import them into Active Directory so that soft match will work.

Synchronized Identity to Federated Identity. This transition is required if you deploy a federated identity provider, because synchronized identity is a prerequisite for federated identity. The user identities are the same in both synchronized identity and federated identity. Because of this, changing from the Synchronized Identity model to the Federated Identity model requires only the implementation of the federation services on-premises and enabling of federation in the Office 365 admin center. Switching from Synchronized Identity to Federated Identity is done on a per-domain basis. The operation both defines the identity provider that will be in charge of the user credential validation (often a password) and builds the federation trust between Azure Active Directory and the on-premises identity provider. When you switch to federated identity you may also disable password hash sync, although if you keep this enabled, it can provide a useful backup, as described in the next paragraph.

Federated Identity to Synchronized Identity. You can convert a domain from the Federated Identity model to the Synchronized Identity model with the PowerShell command Convert-MsolDomainToStandard. Since the password sync option in DirSync is a recent addition, some customers will make this transition to take advantage of that and simplify their infrastructure. This transition can also be a useful backup in case there is a failure with the federated identity provider, because any failure with the federated identity provider—including the physical server, the power supply, or your Internet connectivity—will block users from being able to sign in.

The switch back from federated identity to synchronized identity takes two hours plus an additional hour for each 2,000 users in the domain. Once you have switched back to synchronized identity, the user’s cloud password will be used. We recently announced that password hash sync could run for a domain even if that domain is configured for federated sign-in. Previously Azure Active Directory would ignore any password hashes synchronized for a federated domain. This recent change means that password hash sync can continue for federated domains, so that if you switch from Federated Identity to Synchronized Identity the password validation will be available immediately. If you do not have password sync configured as a backup and you switch from Federated Identity to Synchronized Identity, then you need to configure that, assign passwords with the set-MsolUserPassword PowerShell command, or accept random passwords.

Synchronized Identity to Cloud Identity. You can turn off directory synchronization entirely and move to cloud-managed identities from within the Office 365 admin center or with the PowerShell command Set-MsolDirSyncEnabled. This update to your Office 365 tenant may take 72 hours, and you can check on progress using the Get-MsolCompanyInformation PowerShell command and by looking at the DirectorySynchronizationEnabled attribute value. There is a KB article about this.

When to choose the Cloud Identity model

Choosing cloud-managed identities enables you to implement the simplest identity model, because there is no on-premises identity configuration to do. All you have to do is enter and maintain your users in the Office 365 admin center. This is likely to work for you if you have no other on-premises user directory, and I have seen organizations of up to 200 users work using this model.

You may also choose the Cloud Identity model if you have a very complex on-premises directory and simply want to avoid the work to integrate with it. These complexities may include a long-term directory restructuring project or complex governance in the directory. If you have an existing on-premises directory, but you want to run a trial or pilot of Office 365, then the Cloud Identity model is a good choice, because we can match users when you want to connect to your on-premises directory.

It is most common for organizations with an existing on-premises directory to want to sync that directory to the cloud rather than maintaining the user directory both on-premises and in Office 365. In that case, either password synchronization or federated sign-in are likely to be better options, because you perform user management only on-premises.

To sum up, you would choose the Cloud Identity model if you have no on-premises directory, if you have a very small number of users, if your on-premises directory is undergoing significant restructuring, or if you are trialing or piloting Office 365.

When to use the Synchronized Identity model

The Synchronized Identity model is also very simple to configure. It requires you to have an on-premises directory to synchronize from, and it requires you to install the DirSync tool and run a few other consistency checks on your on-premises directory. This is described in my recent blog post Synchronizing your directory with Office 365 is easy. Before June 2013 this model did not include password synchronization and users provisioned using synchronized identity had to create new cloud passwords for Office 365. This was a strong reason for many customers to implement the Federated Identity model. Now that password synchronization is available, the Synchronized Identity model is suitable for many customers who have an on-premises directory to synchronize with and their users will have the same password on-premises and in the cloud.

In addition to leading with the simplest solution, we recommend that the choice of whether to use password synchronization or identity federation should be based on whether you need any of the advanced scenarios that require federation. I’ll talk about those advanced scenarios next. However if you don’t need advanced scenarios, you should just go with password synchronization. You can also use the Synchronized Identity model when you ultimately want federated identity, but you are running a pilot of Office 365 or for some other reason you aren’t ready to dedicate time to deploying the AD FS servers yet.

To sum up, you would choose the Synchronized Identity model if you have an on-premises directory and you don’t need any of the specific scenarios that are provided for by the Federated Identity model.

When to use the Federated Identity model

As mentioned earlier, many organizations deploy the Federated Identity model just so that their users can have the same password on-premises and in the cloud. With the addition of password hash synchronization to the Synchronized Identity model in July 2013, fewer customers are choosing to deploy the Federated Identity model, because it’s more complex and requires more network and server infrastructure to be deployed.

All of the configuration for the Synchronized Identity model is required for the Federated Identity model. Because of this, we recommend configuring synchronized identity first so that you can get started with Office 365 quickly and then adding federated identity later.

The following scenarios are good candidates for implementing the Federated Identity model. If none of these apply to your organization, consider the simpler Synchronized Identity model with password synchronization.

Existing infrastructure

Scenario 1. You already have an AD FS deployment. If you already have AD FS deployed for some other reason, then it’s likely that you will want to use it for Office 365 as well. This also likely means that you now have multiple SaaS applications that are using AD FS federated sign-in and Azure Active Directory is connecting to the existing infrastructure that you maintain for AD FS with little additional overhead. Of course, having an AD FS deployment does not mandate that you use it for Office 365. You can still use password hash sync for Office 365 and your AD FS deployment for other workloads.

Scenario 2. You already use a third-party federated identity provider. If your company uses a third- party, non-Microsoft, identity provider for authentication, then federated identity is the right way to do that. Third-party identity providers do not support password hash synchronization. Microsoft has a program for testing and qualifying third-party identity providers called Works with Office 365 – Identity.

Scenario 3. You use Forefront Identity Manager 2010 R2. Forefront Identity Manager 2010 R2 can be used to customize the identity provisioning to Azure Active Directory with the Forefront Identity Manager Connector for Microsoft Azure Active Directory. It offers a number of customization options, but it does not support password hash synchronization.

Technical Requirements

Scenario 4. You have multiple forests in your on-premises Active Directory

Azure AD Sync Services can support all of the multi-forest synchronization scenarios, which previously required Forefront Identity Manager 2010 R2. This means that AD FS is no longer required if you have multiple on-premises forests and this requirement can be removed. Read more about Azure AD Sync Services here.

Scenario 5. You have an on-premises integrated smart card or multi-factor authentication (MFA) solution. Azure Active Directory does not have an extensible method for adding smart card or other authentication providers other than by sign-in federation. Often these authentication providers are extensions to AD FS, where Office 365 sign-in can take advantage of them through federation with the AD FS provider. Azure Active Directory does natively support multi-factor authentication for use with Office 365, so you may be able to use this instead.

Scenario 6. Custom hybrid applications or hybrid search is required. Custom hybrid application development, such as hybrid search on SharePoint or Exchange or a custom application on SharePoint, often requires a single authentication token to be used both in the cloud and on-premises. This is more than a common password; it is a single sign-on token that can be passed between applications for user authentication. This is only for hybrid configurations where you are undertaking custom development work and require both the on-premises services and the cloud services to be authenticated at the same time.

Scenario 7. Web-accessible forgotten password reset. For a federated user you can control the sign-in page that is shown by AD FS. It is possible to modify the sign-in page to add forgotten password reset and password change capabilities. This feature is not provided with AD FS but can be manually added during deployment of your AD FS implementation, as described on TechNet. You cannot edit the sign-in page for the password synchronized model scenario. Alternatively, Azure Active Directory Premium is an additional subscription that can be added to an Office 365 tenant and includes forgotten password reset for users in any of the three Identity models.

Policy requirements

Scenario 8. You require sign-in audit and/or immediate disable. With federated identity using AD FS, each sign-in attempt is logged in the standard Windows event log in the same way that on-premises sign-in attempts are logged. You can also disable an account quickly, because disabling the account in Active Directory will mean all future federated sign-in attempts that use the same Active Directory will fail (subject to internal Active Directory replication policies across multiple domain controller servers and cached client sign-in tokens). Sign-in auditing and immediate account disable are not available for password synchronized users, because this kind of reporting is not available in the cloud and password synchronized users are disabled only when the account synchronization occurs each three hours. An alternative for immediate disable is to have a process for disabling accounts that includes resetting the account password prior to disabling it. The password change will be synchronized within two minutes to Azure Active Directory and the user’s previous password will no longer work. Alternatively, you can manually trigger a directory synchronization to send out the account disable.

Scenario 9. Single sign-on is required. Password synchronization provides same password sign-on when the same password is used on-premises and in Office 365. With single sign-on, you can sign in to your Windows PC that is connected to your Active Directory domain and you do not need to re-enter your password when you connect to Office 365. This requires federated identity and works because your PC can confirm to the AD FS server that you are already signed in. An alternative to single sign-in is to use the Save My Password checkbox. This stores the user’s password in Windows Credential Manager (CredMan), where it is secured by the login credentials for the PC, and the user can sign in to their PC to unlock the passwords that CredMan uses. Note that the Outlook client does not support single sign-on and a user is always required to enter their password or check Save My Password.

Scenario 10. Require client sign-in restrictions by network location or work hours. There are two features in Active Directory that support this. Client Access Policy is a part of AD FS that enables limiting user sign-in access based on whether the user is inside or outside of your company network, or whether they are in a designated Active Directory group and outside of your company network. For users who are to be restricted you can restrict all access, or you can allow only ActiveSync connections or only web browser connections. In addition, Active Directory user policies can set login restrictions and are available to limit user sign-in by work hours. Federation delegates the password validation to the on-premises Active Directory and this means that any policies set there will have effect.

Scenario 11. Policy preventing synchronizing password hashes to Azure Active Directory. A small number of customers will have a security policy that precludes synchronizing password hashes to Azure Active Directory. In that case, you would be able to have the same password on-premises and online only by using federated identity. Microsoft is strongly committed to the security of all customer data. We encourage security professionals to review our Office 365 Trust Center. Also, we have details about how password hashes are synchronized in the TechNet article Implement Password Synchronization, and we have additional security guidance about password hash synchronization published on TechNet.

To sum up, you should consider choosing the Federated Identity model if you require one of the 11 scenarios above.

Recent enhancements change the landscape

Recent enhancements have improved Office 365 sign-in and made the choice about which identity model you choose simpler. The guidance above for choosing an identity model that fits your needs includes consideration of all of these improvements, but bear in mind that not everyone you talk to will have read about them yet.

• In June 2013 password hash sync was added to the DirSync tool so that the same password would be available on-premises and online.
• In October 2013 we released Windows Server 2012 R2 including AD FS.
• In November 2013 we added support for the DirSync tool to run on one of your existing Domain Controllers. This can simplify the deployment for some users with small directories.
• In February 2014 we introduced multi-factor authentication for Office 365, which is available for password hash sync users. Prior to this you would require federated sign-in to support any multi-factor authentication.
• In April 2014 Azure Active Directory Sync Services was released in preview to support multi-forest sync.
• In April 2014 Azure Active Directory Premium including Password Reset was released.
• In April 2014 use of alternate sign-in ID reducing dependency on UPN was added.
• In May 2014 password hash sync added the capability to act as a sign-in backup for federated sign-in.
• By the end of 2014 Office client applications are planned to support passive authentication models.

The three identity models you can use with Office 365 range from the very simple with no installation required to the very capable with support for many usage scenarios. By starting with the simplest identity model that meets your needs, you can quickly and easily get your users onboarded with Office 365. Later you can switch identity models, if your needs change.