FTP Server setup in Azure VM

Tags


FTP Server setup in Azure File server for copying files from on premise to Azure VM.

 

Below are the setup file.

 

Reference links

http://www.iis.net/learn/publish/using-the-ftp-service/configuring-ftp-firewall-settings-in-iis-7

http://fabriccontroller.net/blog/posts/passive-ftp-and-dynamic-ports-in-iis8-and-windows-azure-virtual-machines/

http://itq.nl/walkthrough-hosting-ftp-on-iis-7-5-a-windows-azure-vm-2/

http://blogs.msdn.com/b/mast/archive/2013/12/13/setting-up-a-passive-ftp-server-in-windows-azure-vm.aspx

Other method of copying files

http://www.online-tech-tips.com/software-reviews/tools-for-copying-many-files/

 

Installing FTP service on a Windows Azure VM

  1. Open Server Manger and click Add roles and features.

1

  1. From Installation Type tab select Role based or feature-based installation and click Next.        3. From Server Selection tab select the server on which you want to enable FTP and click Next.        4. From Server Roles tab select Web Server (IIS), you will be presented with the Add Roles and Features Wizard.Click Web Server (IIS) and then click Add Features.

2

 

  1. Click Next on the Features and Web Server Role (IIS) tabs.
  2. From Role Services tab select FTP Server and FTP Service and click Next.  

 3

  1. From Confirmation tab click Install and wait for the installation to complete.

Adding the FTP site to IIS Manager

  1. From the Control Panel> Administrative Tools open the IIS Manager.
  2. From IIS Manager, in the Connections pane, expand the Sites node in the tree, then right click the Default Web Site.
  3. Now click Add FTP Publishing.
  4. Fill the Add FTP Site dialog box as shown in the below figures and click Finish.

 

When you’re in, you need to configure IIS. A summary of the required steps:

4

Specify the name and the local path for the site:

5

Specify binding and SSL information:

If you do not want SSL you can select NO SSL.

6

 

And finally specify who should have access to the FTP site. Note that I selected Basic Authentication and the all users..When you do not use SSL to secure access to the FTP site, your FTP credentials are sent in cleartext when logging in to the FTP site.

If you do not want Anonymous authentication you can uncheck the anonymous authentication.

7

 

Configure the Passive Port Range for the FTP Service

In this section, you configure the server-level port range for passive connections to the FTP service. Use the following steps:

  1. Go to IIS 7 Manager. In the Connections pane, click the server-level node in the tree.

8

2.    Double-click the FTP Firewall Support icon in the list of features.

9

 

  1. Enter a range of values for the Data Channel Port Range.

10

  1. Once you have entered the port range for your FTP service, click Apply in the Actions pane to save your configuration settings.

Notes:

  1. The valid range for ports is 1024 through 65535. (Ports from 1 through 1023 are reserved for use by system services.)
  2. You can enter a special port range of “0-0” to configure the FTP server to use the Windows TCP/IP dynamic port range.
  3. This port range will need to be added to the allowed settings for your firewall server.

Step 2: Configure the external IPv4 Address for a Specific FTP Site

In this section, you configure the external IPv4 address for the specific FTP site that you created earlier. Use the following steps:

  1. Go to IIS 7 Manager. In the Connections pane, click the FTP site that you created earlier in the tree,

11

  1. Enter the IPv4 address of the external-facing address of your firewall server for the External IP Address of Firewall setting.

12.

 

  1. Once you have entered the external IPv4 address for your firewall server, click Apply in the Actions pane to save your configuration settings.

Summary

To recap the items that you completed in this step:

  1. You configured the passive port range for your FTP service.
  2. You configured the external IPv4 address for a specific FTP site.

 

 

 

  1. Click Apply. You will be prompted to configure the firewall to allow FTP access.

13

 

  1. To make sure that FTP server has taken all the setting we added, let’s stop and start the FTP service.

    Note: iisreset does not restart the FTP service as it is outside the IIS.  

14

 

Configure Windows Firewall Settings

Windows Server 2008 contains a built-in firewall service to help secure your server from network threats. If you choose to use the built-in Windows Firewall, you will need to configure your settings so that FTP traffic can pass through the firewall.

There are a few different configurations to consider when using the FTP service with the Windows Firewall – whether you will use active or passive FTP connections, and whether you will use unencrypted FTP or use FTP over SSL (FTPS). Each of these configurations are described below.

Note: You will need to make sure that you follow the steps in this section walkthrough while logged in as an administrator. This can be accomplished by one of the following methods:

  • Logging in to your server using the actual account named “Administrator”.
  • Logging on using an account with administrator privileges and opening a command-prompt by right-clicking the Command Prompt menu item that is located in the Accessories menu for Windows programs and selecting “Run as administrator”.

Note: While Windows Firewall can be configured using the Windows Firewall applet in the Windows Control Panel, that utility does not have the required features to enable all of the features for FTP. The Windows Firewall with Advanced Security utility that is located under Administrative Tools in the Windows Control Panel has all of the required features to enable the FTP features, but in the interests of simplicity this walkthrough will describe how to use the command-line Netsh.exe utility to configure the Windows Firewall.

Using Windows Firewall with non-secure FTP traffic

To configure Windows Firewall to allow non-secure FTP traffic, use the following steps:

  1. Open a command prompt: click Start, then All Programs, then Accessories, then Command Prompt.
  2. To open port 21 on the firewall, type the following syntax then hit enter:

netsh advfirewall firewall add rule name=”FTP (non-SSL)” action=allow protocol=TCP dir=in localport=21

  1. To enable stateful FTP filtering that will dynamically open ports for data connections, type the following syntax then hit enter:

netsh advfirewall set global StatefulFtp enable

Adding ports specified in the previous step as endpoint to the VM

Ports 1035 to 1040 should also be added as endpoint to the Azure VM. You can add multiple ports as endpoint to the VM using Windows Azure PowerShell. Detailed procedure here.

 

You can also add endpoints using the management portal. Detailed procedure here.

 

To confirm that the said ports are added to the VM, please check the endpoint list on portal for the said VM.

Note: You also would need add port 21 to the endpoint list which is command port for FTP connection.

15

 

Adding Firewall rules to allow traffic on the added endpoint

For ports added as endpoints in the above procedure, no configuration is done automatically to the firewall in the guest operating system. When you create an endpoint, you’ll need to configure the appropriate ports in the firewall to allow the traffic you intend to route through the endpoint.

 

In this case I have disabled the Windows firewall for simplicity. You can refer here to modify the firewall rules to allow traffic on the ports added as end points.

 

We are now done setting up the passive FTP Server on a Windows Azure VM.

 

Verifying that FTP server is using the port previously specified under data channel port  

 

 

  1. Client connects on the command port, which is usually TCP port 21.
  2. When the connection on command port is successful, the server sends a port to the client to connect to. If you are using FileZilla, you will see something like this: Command:        PASV Response:        227 Entering Passive Mode (168,63,240,169,4,14). Where 168,63,240,169 is the IP address of the VM and 4,14 is the port on which the data traffic is routed (256*4+14=1038). This is how you determine that a port added in previous steps are actually being used to establish a passive FTP connection.

 

Points to consider from Azure SLB perspective

 

When FTP is transferring large files, the elapsed time for transfer may exceed 4 minutes, especially if the VM size is A0. Any time the file transfer exceeds 4 minutes, the Azure SLB will time out the idle TCP/21 connection, which causes issues with cleanly finishing up the FTP transfer once all the data has been transferred.

 

Basically, FTP uses TCP/21 to set everything up and begin the transfer of data. The transfer of data happens on another port. The TCP/21 connection goes idle for the duration of the transfer on the other port. When the transfer is complete, FTP tries to send data on the TCP/21 connection to finish up the transfer, but the SLB sends a TCP reset instead.

 

The way around this is to make the client to keep the TCP/21 connection from going idle. If using a 3rd party FTP client, there may be configuration knobs the user can turn in order to cause the FTP client to send a keepAlive. As an example of how you can set this in FTP client software, in FileZilla, you go to Edit, Settings, Connection, FTP, and check Send FTP keep-alive commands.

16

If the FTP client is being written in .NET, customers will need to account for this client-side keepAlive in their code. Here is a sample (the keepAlive is highlighted):

 

 

Sharing Folders in Azure VM

Tags

, ,


Courtsey: MSDN Blogs  Blogs MSDN-2

Download robocopy for windows 2003 server for file server migration to azure with same permission

 

Configure the Virtual Machine File Server

Utilize the following procedure to configure a Windows Azure Virtual Machine (VM) instance for use as a File Server.

  1. Create the File Server VM instance (e.g. “MyFileServer.cloudapp.net”) using the Windows Azure portal.   See reference instructions here.
  2. Attach and format a blob-storage hosted data-disk to the VM.
  3. Once the File Server instance is running, configure a limited privilege user-account (e.g. “MyUser”).   Note that this service account is a primary security mechanism for the server instance.  Any other VM within the data-center could access your server or cause denial of service.   More advanced server security configuration is beyond the scope of this article.
  4. Using the Server Manager Console, enable the File Server Role.
  5. Create a File Share folder (e.g. “MyShare”) on the attached data-disk and enable read/write access for the MyUser account.
  6. Add two endpoints to the VM for both TCP port 445 and UDP port 445.   This enables the server (at the service deployment level) to communicate SMB protocol with worker-roles hosted in the same Windows Azure data-center.   The SMB protocol is not currently routed externally from the data-center.

Your File Server configuration should appear as follows from the management portal.

MyFileServer1

With corresponding service end-points configured as illustrated.

MyFileServer2

And the file share configuration similar to the following image.

MyFileServer3

There are two options to migrate files between two server

 

  • Use Robocopy

 

Robocopy is essentially a tool for copying files from one location to another that has:

 

  • The ability to copy NTFS permissions, if you want to
  • The ability to skip files that have been copied previously, provided that they have not changed

 

For the reasons above it is still ideal for using when you want to quickly migrate the contents of a file share to a new server. To do this first set up the new file share on the new destination server, making sure the share and NTFS permissions match those that are configured on the old share on the old server.

 

Next enter the following command on the admin command prompt, where OLDSERVER is the old file server name, and OLDSHARE is the old share name, and NEWSERVER is the new server name and NEWSHARE is the new share name:

 

robocopy “\OLDSERVEROLDSHARE” “\NEWSERVERNEWSHARE” /S /E /COPY:DATS

 

The command basically tells robocopy to copy the contents from the UNC path of the old share, to the UNC path of the new share. The /S and /E tell robocopy to copy any subdirectories, and empty directories. In this example the /COPY:DATS tells robocopy to copy the Data, Attributes, Timestamps and Security information. There are a couple of other elements that you can also copy if you want. To copy everything use /COPY:DATSOU or alternatively /COPYALL. Here is a list of all the flags you can use with the /COPY: part of the command:

 

D – Data

A – Attributes

T – Timestamps

S – Security i.e. NTFS permissions

O – Owner information

U – Auditing information

 

Reference : Robocopy and a Few Examples : http://social.technet.microsoft.com/wiki/contents/articles/1073.robocopy-and-a-few-examples.aspx

 

  • Use File Server Migration Toolkit v1.2

 

  • To smoothly migrate the DFS root, you may consider using File Server Migration Toolkit v1.1 to migrate the DFS namespace from the old Windows Server 2003 to the new Windows Server 2008. By using File Server Migration Toolkit, we can copy shared folders, files, and their security settings from a source file server to a target file server without losing their share and NTFS security settings. It is very easy to use FSMT, which can save you lots of time and effort.

 

  • For more detailed information about FSMT, you may refer to the following documents.

 

Download: Microsoft File Server Migration Toolkit 1.2 http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en

 

Overview of the Microsoft File Server Migration Toolkit http://www.microsoft.com/downloads/details.aspx?familyid=604BE797-D19E-4BC1-A148-B48FC731135E&displaylang=en

Azure Files storage service

Tags


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”.

ActivatePreview

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

ActivateQueued

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.

endpoints

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.

mappeddrive

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.

Disk Bench

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.

speednetwork

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


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.Auto-Complete list

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


iphone-call-icon

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:

conference_call_how_to&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

,


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.

Azure folder redirection-policy-1

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

Disable the Group creation functionality in the Microsoft Office 365 tenancy

Tags


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.

Global admin

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

, ,


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.

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.

 

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.

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.

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.

Optional featuresThe 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

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.

Optional featuresFor 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.

  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.Password Writeback 2
  5. On the Permissions tab, click Add.Password Writeback 3
  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.Password Writeback 4
  9. Click Ok. Click Apply. Click Ok.

 

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.Role

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.

  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
    
    noteNote
    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

 

Welcome to Azure AD SyncAs 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.

 

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

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

 

Connect to AD DSTo 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.

 

Uniquely identifying your usersOn this page, you need to configure the following:

  1. Matching across forests
  2. Matching with Azure AD

 

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.

 

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 featuresIf 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 appsIf 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 attributesBased 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 configureThis 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).

 

FinishedA 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

ADSYnc

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.

noteNote
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.

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.

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.

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

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.

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.

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.password reset for users
  3. Under the Directory tab, click the directory in which you want to configure the user password reset policy, for example, Wingtip Toys.password reset for users
  4. Click the Configure tab.password reset for users
  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.password reset for users
  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.password reset for users
  7. After configuring user password reset policy as desired for your tenant, click the Save button at the bottom of the screen.
    noteNote
    A two challenge user password reset policy is recommended so that you can see how the functionality works in the most complex case.

    password reset for users

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.

  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:password reset for users
  2. Here, users can provide and verify their mobile phone or alternate email address. This is what verifying a mobile phone looks like.password reset for users
  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.password reset for users
  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.password reset for users

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.

  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.password reset for users
  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”.password reset for users
  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.password reset for users
  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.password reset for users
  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.password reset for users
  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.password reset for users
  7. Here is a sample of an email that users will see – notice the tenant branding:password reset for users
  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.password reset for users
  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.password reset for users
  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.password reset for users

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

,


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:

    1. Open PowerShell, and then type Import-Module DirSync
    2. 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
      1. In this command, the placeholder <AD FS 2.0 server name> represents the name of the primary AD FS 2.0 server.
      2. 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
      1. Replace <federated domain name> represents the name of the domain you are converting.
      2. 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

,


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.

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.

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

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.

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.

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.

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

  1. Password Complexity Policy
  2. Password Expiration 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.

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

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.

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.

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.

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

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

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

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

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

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:

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

Event ID 657In 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::

Password Change RequestEvent 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:

Password Change Result

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.

noteNote
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.