Microsoft forms Error – Sorry something went wrong

Azure March 20, 2019 Leave a comment

Recently while accessing Microsoft forms users were getting the error. Sorry, something went wrong.

The issue was reported by all the users even they have required licenses assigned to them.

The forms were enabled for the affected user



Solution:

We’ve to enable the collab DB service from the azure portal which is required for this Microsoft forms.

Navigate to Azure Portal – Access Azure Active Directory – Select Enterprise Applications – Search for CollabDb Service




Navigate to properties – ensure Enabled for users to sign-in is turned on.

Once after enabling the sign-in option on the azure portal this has fixed the issue.

Teams Upgrade- Important points to consider before teams only toggle mode

Microsoft Teams, Office 365 March 5, 2019 Leave a comment

Microsoft is investing and focusing on Teams for the Collaboration platform, Skype for Business have become volatile. We can see every day new features and enhancements are coming on the way for Microsoft Teams. Moreover, Microsoft have provided all the requirements and materials available for transition from Skype for Business to Microsoft Teams. This makes much simpler for any customers to completely move to teams only mode.

On a comparison of the road map improvements in Microsoft Teams the features have been enhanced and loads of new functionalities are being added very often. Currently the default configuration of all the tenants will be on Island mode which will make the users to communicate on both Microsoft Teams and Skype for Business. This might create more confusion for the end users to choose which platform to communicate for their daily activities since they are provided with couple of options.

This article focusses readiness on environment before we completely migrate to teams only mode.

Skype for Business Interop Mode Removed:

Earlier 6 months ago we had the Skype for Business Interop mode which helped the team’s users to communicate with Skype for business users. This will show teams chats in skype for business for users who don’t have teams. But this option has been removed and we have teams only mode added in the coexistence mode.

As of now there are 3 options available for all office 365 tenants:

When we run the command Get-CsTeamsUpgradePolicy we will get additional options.

While coming to talk about transition mode only below 3 options are feasible for most of the organizations.

Islands Mode:

As the name indicates this is a big sign of warning. Island mode is an indication of a temporary place where we can stay only for some time and not denoted to settle down for a long period. With this mode the User experience are completely different. There is no interconnection between Skype for Business and Microsoft Teams and they both work as an independent system.

Only below workflow in Island Mode:

Teams Communication – Teams Communication

Skype Communication – Skype Communication

Teams Only Mode:

In this mode we are enforcing all the users to use only Microsoft Teams. Meaning no users will be able to login to Skype for business even if they have the client system installed on their PC from their office 365 pro plus package. However, users present in Skype for Business only mode will be still able to reach teams only mode users and teams only mode users can reply to Skype users. However, we need to note that a new conversation chat cannot be initiated from a Teams only mode user to an Island or Skype for Business only user’s mode.

Only below workflow in Teams only Mode:

SFB Users Sends to Teams User – Message will be received in teams.

Teams Users responds to SFB User – Message will be received in teams only for the SFB user.

Teams User Tries to establish a new Chat with SFB user – Will not be successful

Also, we need to note that only limited functionalities will be working between team’s user and SFB user communication in this mode. For instance, a remote desktop cannot be shared by an SFB user who is on Teams and in Teams only mode.

Skype only Mode:

Only Skype Client no matter from where the IM is initiated.

Note: In any modes as of now the Meetings will be accessible in the cross platforms.

Be ready for this change target pilot users first:

Before we make this transition it’s very important to understand the current usage model of collaboration platform by end users. For instance, a Marketing head might be more comfortable with Skype for Business and never had a chance to explore Microsoft Teams. There might be a heavy dependency on Enterprise Voice Integration with Skype for Business which needs to be considered before making this change. It’s always better to choose few pilot users  

If we are planning for Teams Transition its better to slowly move users to teams only mode based on current user dependency on Skype for Business. Its better to identify few pilot users in each department and slowly transition them to Microsoft Teams only Mode.

After identifying the capable team leaders in every department better to switch them to teams only mode.

Below action needs to be verified:

1.Verify if you have Skype online connector module installed.

Get-Module -ListAvailable | Where-Object {$_.Name -eq "SkypeOnlineConnector"}

If you do not have them then Download and install the Skype online connector.

2. Connect to Skype online connector

Import Skype Online Connector

Import-Module SkypeOnlineConnector

$session = New-CsOnlineSession

Import-PSSession $session

3. Collect the current list of users in Island mode.

By Default, We will have all the user in Island mode. However, it is better to collect the list and prepare the users for teams only mode in phases.

Get-CsonlineUser | Select-Object Displayname,  UserPrincipalname,Department,Company,Office,TeamsUpgradeEffectiveMode,TeamsUpgradeNotificationsEnabled,TeamsUpgradePolicyIsReadOnly,TeamsUpgradePolicy | Export-Csv C:\Temp\IslandMode

4. Collect the pilot users and enable them on Teams only mode . Have a CSV file with  only userprincipalname.

$Teams= Import-csv C:\temp\Teamsonlypilot.csv |%{$_.userprincipalname}

 $Teams | % {Get-CsonlineUser -Identity $("$_")} | fl Displayname,TeamsUpgradeEffectiveMode,TeamsUpgradeNotificationsEnabled,TeamsUpgradePolicyIsReadOnly,TeamsUpgradePolicy

$Teams | % {Grant-CsTeamsUpgradePolicy -PolicyName UpgradeToTeams -Identity $("$_")}

Once after updating the users we will get the below confirmation stating that they will be only on Teams and can no longer be able to use Skype for Business.

We can also switch to one user by following option from the GUI

Or by the one line command 

Grant-CsTeamsUpgradePolicy -PolicyName UpgradeToTeams -Identity username@domain.com

5. Notify Users about Teams Upgrade is available to them

We can enable this option to end users couple of days before upgrading

6. Restrict Teams Event live Policies

By default Teams has a Global policy for live events, which affects to all users in the organization and this needs to be restricted.

Create a new policy that doesn’t allow to create Live Events and assign the policy to all users.

New-CSTeamsMeetingBroadcastPolicy -Identity DisabledBroadcastSchedulingPolicy



Set-CsTeamsMeetingBroadcastPolicy -Identity DisabledBroadcastSchedulingPolicy -AllowBroadcastScheduling $false

Grant-CsTeamsMeetingBroadcastPolicy -Identity {user} -PolicyName DisabledBroadcastSchedulingPolicy -Verbose


7. Push and install the Teams desktop Client for the targeted users.

By default the teams is not included in the Pro plus package as of now. Microsoft have recently announced that Teams will be added in ProPlus package in future roadmap as per this Article.

Until we get this as a bundle we have

Download the Teams app in the Background.

This option will only download the teams app in the background for users in Teams only mode.

However it does not install the app and we need to perform some action of installing them to all users PC via group policy or SCCM. There is one amazing article written by Paul Cunningham for pushing them via GPO.

Imp Notes:

  1. Before making these changes educate the L1 support team to address end user queries.
  2. We can make use of the Microsoft Teams Customer adoption success kit
  3. If there is any PSTN integration with Skype for Business Online, then these factors needs to be planned before phasing out Skype for Business Online until they are transferred completely to Microsoft Teams.

Thanks & Regards

Sathish Veerapandian

Delegate resetting azure MFA for helpdesk through azure automation run book and Microsoft Flow

Automation, Azure, Microsoft Flow, Office 365 February 1, 2019 Leave a comment

When a user with MFA enabled loses his mobile phone then he wouldn’t be able to login to new devices or in the old devices where the token life time have expired. 

Currently in this scenario the user have to report to help desk team. Unfortunately only the global admins can perform  the force reset of MFA account for the user to reset his Strongauthenticationmethods value to null to clear the  old lost device.  

There is a work around which can be used until we get a delegated RBAC role for performing this action. With Azure Automation account, creating a flow, integrating with flow and delegating this action to helpdesk admins will reduce the load on global admins performing this action. 

Prerequisites:

  1. Create New Automation Accounts from azure portal. Azure subscription required.They provide 500 minutes free every month.
  2. Create new Work Flow from global admin account.This action needs to be performed from global admin account.
  3. Enter the Global admin Credentials in the created automation account. Very Important that this account used to execute must not have MFA enabled.
  4. Import the MSOnline module from the gallery.

Create Azure Automation Account –

Proceed to https://portal.azure.com – Create automation account.

Now add the msonline module-

Add Exchange Online Module – Access Azure Automation account and click Assets > Modules- Add MSOnline Module.

We can see the MSOnline modules are imported successfully.

Enter Global Admin Credentials in the Created Automation account –

Click on Automation accounts – Credentials – Enter Global Admin Credentials. Add scripts(below scripts)

This is the global admin credentials required which will execute the automation when we trigger the work flow from a delegated helpdesk admin account.

Now add the script which is required to execute this operation.

Param
     (
         [Parameter (Mandatory= $false)]

         [String] $UserEmail = ""
     )

     $creds = Get-AutomationPSCredential -Name 'TestDemo’
     Connect-MsolService -Credential $creds
#This command resets the MFA
Set-MSOLUser -UserPrincipalName $UserEmail -StrongAuthenticationMethods @()
#This Command Resets the password  with force login
#Set-MsolUserPassword -UserPrincipalName $UserEmail -NewPassword "S@c@r!ooii" -ForceChangePassword $true

After adding above Publish the scripts.

Now we need to create the flow from the global admin account to execute this action.

Head over to Flow (https://flow.microsoft.com ) and provision a new personal Flow. Click new flow – Click Create from Blank.

Choose – Flow Button for Mobile , Flow Button for Mobile – manually trigger a Flow , Select AA- Type useremail as input flow.

Navigate to triggers – Select Manually trigger a flow.

Type UserEmail as input flow-Click on New Step – Add an Action

Click on Choose an action – Select Azure Automation – Create a Job – Provide the required credentials and subscription details.

Provide the required credentials and subscription details.

This part is very important we need to select the input as UserEmail as below. This parameter is required for the run book to execute the operation.After that we can see that the RunBook Parameter is UserEmail.

Now we will see the flow is connected to Azure automation account

Now Navigate to My Flows- Select the new flow – Click on – Run Now

We can see the flow will be successfully started and execute the requested operation of resetting the MFA value to null for the user.

We can run them on automation accounts and see them for verification and they will be successful.

From the global admin Flow login – Delegate this flow to helpdesk admins as manage run only user permission.

The actual operation is executed by the global admin account however the helpdesk team will be triggering this action through the delegated run only permissions assigned to them in created Microsoft flow.

Thanks & Regards

Sathish Veerapandian

Configure access panel in Azure Active directory

Azure, Office 365 January 22, 2019 Comments: 2

We can enable and provide self service application access to end users.If an organization is using Office 365 applications and the user is licensed for them, then the Office 365 applications will appear on the user’s Access Panel.Microsoft and third-party applications configured with Federation-based SSO can be added into this access panel.

We can create multiple groups example like HR,Marketing and required apps both internal corporate apps and social media apps can be published.

In order to logon access panel we must be authenticated using organizational account in Azure AD.We can be authenticated to azure AD directly or federated authentication and consume this service.

For organizations that have deployed Office 365, applications assigned to users through Azure AD will also appear in the Office 365 portal 

The azure access panel is a web based portal which provides user with below features:

1)View and launch cloud apps.
2)Configure self service password reset.
3)Self manage groups.
4)See account details.
5)Modify MFA settings.

IT admin can be benefited and reduce first level calls by enabling below features:
1)Provide easy portal for users.
2)Launch cloud based, federated onprem apps.
3)Links to URLs.
4)Control access to corporate application.
5)Restrict access to Users by Groups ,device and location.

The portal can be accessed from https://myapps.microsoft.com Azure Admin Can configure the Access panel settings from the below url-

Login to Azure AD – https://portal.azure.com/

Navigate to URL – Azure AD – Enterprise Applications – All applications.

Select the application which we need to add – In below case LinkedIn – Click on Self-Service.

Below are the options we have at this moment:

Select the option allow users to request access to this application. – By enabling this option end users can view and request access to this application.


To which group the users must be added:

Require approval before granting access to this application:

Who is allowed to approve access to this application:

To which role users should be assigned to this application:

We have these option to add an app:

  1. App that your developing- Register an app you’re working on to integrate it with Azure AD.
  2. On prem app (app proxy)- Configure Azure AD Application Proxy to enable secure remote access.
  3. Non gallery app- Integrate any other application that you don’t find in the gallery
  4. Add from the Gallery – There are close to 3000 apps in gallery which can be added.

Example below of when adding an application we have the following options:

In below case we are adding twitter from the gallery- Custom name can be provided for the application.

Single sign on mode-we have 2 options:

  1. Federated SSO – Allow users to access apps with their organizational accounts applicable mostly for on premise apps published here, application you are developing and any application which is integrated with on premise IDP. Only one time login is required.
    After signing in, the user can launch applications from the Office 365 portal or the Azure AD MyApps access panel. 
  2. Password based Sign-on- Users must remember application-specific passwords and sign in to each application. 

Hide application from end user:

This option can be used if we would like to hide application from end user.

We have below option to hide office 365 apps from the access panel. Doing this will allow end users to see office 365 apps only from office 365 portal.

Further more end user settings features for access panel can be managed:

For on premise applications we need to configure federated single sign on and add them on the access panel.

Navigate to Azure AD – Click Enterprise Applications – Click all Applications – Select the application that needs Single sign on configuration

We have the below options:
SAML – Use SAML whenever possible. SAML works when apps are configured to use one of the SAML protocols.For SAML we need to provide the signon url, user attributes , claims , signing certificate

And then we need to provide the azure url in the application to link with azure AD. Here we are creating an relying party trust between the application and Azure AD for the SAML configuration to work.


Linked – Can be used for cloud and on premise apps.we can use this when the application have single sign-on implemented using another service such as Active Directory Federation Services or any other IDP solution.

Disabled – Use this option If your application is not ready and integrated for SSO. Users will need to enter the user name and password every time the application is launched.

End User review from browser –

User can navigate to http://myapps.microsoft.com/

The defaults office 365 apps will be shown if its not hidden.

After Clicking on Add app users can explore the apps added by admin from the admin portal. In our case it shows only LinkedIn since we added only LinkedIn.

If there is any approval process required as per admin config it goes for approval and post approval the application will be available for requested user.

As per the recent update Microsoft recommends to use In-tune Managed Browser My-apps integration for mobile scenarios.
This integration supports lots of additional cool stuff like home screen bookmark integration, azure ad app proxy integration.

The access panel will definitely help end users to access all office and their corporate applications all in one place without any confusion and will reduce the burden on the front line first level end user access requests.

Thanks & Regards

Sathish Veerapandian

Product Review: Stellar Repair for MS SQL Database

SQL, Tools January 14, 2019 Leave a comment

According to Embarcadero Technologies’ Database Survey Report, 83% of respondents say that they have Microsoft SQL database environment. The widespread adoption of SQL database is attributed to its growing application scope and relevance in the modern enterprise IT setup. However, like other database applications, SQL Server also faces tuning and performance issues despite the Database Administrators’ (DBAs) efforts to maintain optimal performance.

Hardware and software issues turn SQL database inaccessible, which is due to the following reasons:

  • Network failure issue when database is accessed by a user
  • Storage media corruption leading to corrupt MDF files
  • Changes on SQL server account
  • Corruption in File Header and more

Such cases of database corruption can be resolved with the help of Microsoft suggested utilities like DBCC CHECKDB. But these utilities are time taking, need more technical proficiency, and may lead to data loss situations if not used properly.

Instead, using a database repair software like Stellar Repair for MS SQL ensures a timely and secure recovery from almost all types of Microsoft SQL corruption issues. The software repairs the corrupt MDF and NDF files, and recovers the entire database as new or an existing DB.

Worldwide, Microsoft SQL server has the largest share – 23.8% in relational database management category, as per a survey conducted by iDatalabs, and the reason is Microsoft’s understanding of the Database Administrator’s needs – the flexibility to manage the database, effectively. Still the issues crop-up either due to an error in SQL database file or SQL server for example SQL Server Error 5172, where the file header for a MDF file is rendered incorrect;

SQL server page level corruption in which corruption in a particular page leads to corruption all over the database. Numerous such errors in SQL database leads to corruption and Administrators perform DBCC check to check and resolve the error. However, the limitations of the Microsoft inbuilt utility compel the DBAs to search for an effective, more comprehensive solution to fix the MSSQL issues. And amongst a few good SQL recovery tools is a reliable software – Stellar Repair for MS SQL.

Let’s review the software features, its advantages and the disadvantages.

About the software: A Proven SQL Repair Solution:

Based on real used cases DBA admins  find it easy to recover corrupt SQL server database with the help of this enterprise-grade database repair software – Stellar Repair for MS SQL. The software’s user-friendly interface and unique features are designed to repair the primary and secondary (MDF and NDF) database files, thus addressing almost all SQL database repair and recovery needs.

The Versions of Stellar Repair for MSSQL:

Stellar Repair for MS SQL is available in three editions:

Demo Edition: The Demo edition is available for download from Stellar’s SQL Recovery Software details page and is the best to evaluate the core functionality of the software. The Demo edition provides a free preview of all the recoverable components of MSSQL database. Users can view and verify database content. The Demo edition also offers a free Log Report.

Licensed Edition: The licensed software edition allows to recover and save the entire MS SQL database in the available database (beneath the original database) or as a new database at the specified location. The paid version of the software repairs the corrupt or damaged database and also helps to resolve the database errors.

Software Requirements:

The software should be installed on the same system on which the corrupt database resides. The minimum system requirements include Pentium class processor, 1 GB Memory, and 50 MB of Hard disk space.

As the software supports all Windows versions including Windows 10 (32bit/64bit)/Windows 8.1 (32bit/64bit) / 8 (32bit/64bit)/Windows 7 (32bit/64bit)/Windows Vista (32bit/64bit)/Windows Server 2012 and Windows Server 2008, it can be installed to repair SQL database of any size and version.

Compatibility:

MS SQL Server:  2016, 2014, 2012, 2008 and older versions

The Key Features of MSSQL Recovery Software:

A comprehensive solution to repair the corrupt and inaccessible MDF and NDF files and recover all database components including tables, triggers, keys, rules, stored procedures in recent as well as older versions. Besides, the software also recovers XML indexes and data types, column set property, sparse columns, and file stream data types.

Resolves SQL Database Corruption Issues and Database Errors:

The software helps resolve database corruption issues at the time when Microsoft’s built-in utility DBCC CHECKDB fails. The software fixes SQL server database corruption errors like 5171, 8942, 3414, and also fixes SQL database issues like header file corruption, schema corruption, consistency error, and recovers the SQL database when it is stuck due to the following issues:

  • The database is in Suspect mode or Offline mode
  • Clustered or non-clustered index corruption
  • Recovery pending and database attachment issues
  • Damaged Transaction Log file in SQL server
  • Recovery of Deleted Records of SQL database

The repaired LDF file is available at the MDF-file saving location.

Provides Free Preview of Repaired and Recoverable Objects:

Stellar Repair for MS SQL scans the entire corrupt database, repairs it, and displays the preview of recoverable items in a tree-like structure. DBAs can search for specific entries, as the database is sorted before display. The preview feature helps verify the original database with the recovered components.

Recovers Selective components:

The software allows Administrators to select specific objects from the recovered database and save them at a specified location. This is particularly helpful in cases where the user doesn’t need to preserve all components of the database.

Recovers ROW and PAGE compressed data:

The software review shows that it recovers SQL Tables with PAGE and ROW compression. Also, the software supports Standard Compression Scheme for Unicode (SCSU) for SQL Server 2008 R2, and ensures recovery of the entire database without disrupting the original format.

Establishes connection automatically when disrupted:

The SQL Recovery Software establishes the connection automatically, in case the connection is interrupted. This feature saves time and effort to start the process all over again if the connection is disrupted and the process is halted without complete recovery.

Saves Scanned Results:

Stellar Repair for MS SQL scans, repairs and saves the scanned results of repaired SQL database during the repair process. DBAs save these repaired files at a later stage in case there is time or space crunch.

Saves Log Report:

The product review also shows that the software saves a Log Report of all the repair activities. Software users can verify the software performance with the help of the Log Report.

The advantages and disadvantages of using Stellar Repair for MS SQL software:

Advantages:

  • Resolves All MSSQL server and database related errors and maintains database integrity
  • Repairs corrupt and damaged SQL database files – MDF and NDF and also saves LDF files
  • Saves repaired database as new Database to reduce further chances of corruption
  • Recovers all deleted records from SQL database
  • Saves the repaired data in multiple formats – MS SQL, HTML, XLS, and CSV

Disadvantages:

  • Needs to be installed on the same system on which the corrupt MSSQL database resides.

Conclusion:

An analysis of the software’s key features, advantages, and disadvantages confirms that the software effectively repairs corrupt MS SQL database files and recovers all components of the database. The capacity with which the software resolves the database corruption errors where even the Microsoft utility fails, makes it distinct. Its easy-to-use interface serves both technical as well as non-technical users well. This SQL database recovery software review shows that the product Stellar Repair for MS SQL provides all the database repair and recovery solutions and never compromises on database integrity. Considering how much a downtime can cost such tools are great lifesavers. You can use this especially if you do not have expert knowledge about database and recovery.

Configure Azure AD Terms of Use functionality within conditional access in Microsoft Intune

Intune, MDM, Office 365 January 12, 2019 Leave a comment

The Azure AD terms of use functionality have been recently upgraded. In this article we will have a look at configuring the Azure Azure AD terms of use functionality for Microsoft Intune while enrolling the devices.

Navigate to Terms of use at https://aka.ms/catou

Search for Conditional Access – Terms of Use – Click on terms of use – Select New Terms

Create a new terms of use. Here we have an option to upload our own company terms of use PDF. There is an option to choose the language format for the terms of use.

Following features can be enabled :

Require users to expand the terms of use – The end users will be required to view the terms of use prior to accepting.

Require users to consent of every device – The end users will be required to consent to the terms of use on every device.

Expire Consents – The terms of use will be enforced immediately and all users will be forced to re-consent on a schedule.

Duration before re-acceptance required (days) –The terms of use will be enforced immediately and each user will have to re-consent every specified number of days.

Once after completed this terms of use needs to be applied to conditional access as per the requirement.

We have 4 options at this moment:

Access to cloud apps for all guests- A conditional access policy will be created for all guests and all cloud apps. This policy impacts the Azure portal. Once this is created, you might be required to sign-out and sign-in.
Access to cloud apps for all users- A conditional access policy will be created for all users and all cloud apps. This policy impacts the Azure portal. Once this is created, you will be required to sign-out and sign-in.
Custom policy- Select the users, groups, and apps that this Terms of Use will be applied to.
Create conditional access policy later- This terms of use will appear in the grant control list when creating a conditional access policy.

Its strongly recommended to go with custom policy or create conditional access policy later option, since the former 2 options will apply for all users accessing all cloud apps and we might have lot of segregation based on user departments, job roles and terms of use might vary for every department.

After created we can see the terms of use created below in the terms of use section.

Further navigation we can see the number of people accepted and declined the terms of use, details and languages.

In the audit logs we can see the actions initiated and changed to the terms of use policy.

Enabling the Terms of use to conditional access intune:

Once after creating the terms of use and selecting the required conditional access template we can see that the new policy that we created will be visible in our CA policy. We can select this option and this will be enforced to all users to accept the terms of policy.

Now we need to select this option to Microsoft Intune device enrollment.

After this is enabled we can run the what if and see if its working for the targeted user. In our case we can see the policy that we enforced is getting applied below.

Client User Behavior- Android Device Enrollment through conditional access policy.

We can see that the Exchange Query IT policy terms of use is applied during device enrollment from android device in our case.

On expanding we can see that the term detail as per the company policy.

Note:

  1. Its always better to roll out this policy to pilot users at the initial stage, verify the behavior and later plan this roll out in a phased approach for remaining users
  2. The IT policy terms can be added for different languages as well based on the different geographic locations.
  3. We have an option to review the users who have accepted the policy and rejected from the policy tab.
  4. Conditional access policy controls (including Terms of use) do not support enforcement on service accounts. So ensure that all the service accounts are excluded.
  5. End user accounts consuming this service will require Azure AD Premium P1, P2, EMS E3, or EMS E5 subscription inorder to activate this service to them.

Thanks & Regards

Sathish Veerapandian

Enable Azure AD Password Protection for On Premise Windows server Active Directory

Azure, Security December 17, 2018 Leave a comment

In this article we will have a look at enabling Azure AD password protection policy in On Premise Active Directory Server.

By Default this feature is enabled for cloud only users with a basic filter of Azure AD password protection with global banned password list.However if we still require Azure AD password protection with custom banned password list for Cloud only users then we would need to have at-least Azure AD Basic License the default value is below.

We have below options in password protection policies:

Lockout Threshold:
How many failed sign-ins are allowed on an account before its first lockout. If the first sign-in after a lockout also fails, the account locks out again.

Lockout Duration in Seconds:
The minimum length in seconds of each lockout. If an account locks repeatedly, this duration increases.

Enforce custom list:
When enabled, the words in the list below are used in the banned password system to prevent easy-to-guess passwords.

Custom banned password list:
A list of words, one per line, to prevent your users from using in their passwords. You should include words specific to your organization, such as your products, trademarks, industries, local cities and towns, and local sports teams. Your list can contain up to 1000 words. These are case insensitive, and common character substitutions (o for 0, etc) are automatically considered.

Enable Password protection on active directory:
If set to Yes, password protection is turned on for Active Directory domain controllers when the appropriate agent is installed. 

Mode:
If set to Enforce, users will be prevented from setting banned passwords and the attempt will be logged. If set to Audit, the attempt will only be logged.

The Visual representation of how this process works is beautifully shown below from Microsoft technet Source 

Below are the prerequisites for enabling the password protection on Active Directory:

  1. For enabling this service on On Premise Active Directory it requires an Azure AD premium license.
  2. A proxy service agent needs to be installed on a member server running windows server 2012 R2 or later.
  3. Domain controllers where the Azure AD password protection DC agent service will be installed must be running Windows Server 2012 or later.  
  4. All servers running the azure AD components must be fully patched in-order to have Universal C runtime installed.
  5. Network connectivity must be present between the Azure AD proxy server and one domain controller running Azure agent Service.
  6. An Azure AD global administrator account is required to register and consume this service for On Premise AD in Azure AD.
  7. A local domain admin privilege account is required to register windows server AD with Azure AD.
  8. Domain running the DC agent service must use the DFSR replication type  for SysVol Replication.
  9. Azure AD password protection proxy service server must have access to the below Microsoft Protection Endpoints.

https://login.microsoftonline.com  –  For Handling the Authentication Requests.

https://enterpriseregistration.windows.net – Azure AD password protection functionality

       

Download the 2 agents from link – https://www.microsoft.com/en-us/download/details.aspx?id=57071

After download we will have 3 installers as below.

Azure AD Password Protection Proxy Service – It acts as a proxy agent which will forward outgoing requests from domain controllers to Azure AD and incoming requests from Azure AD to the on premise domain controller.

DC Agent password filter dll – Will receive all the password validation requests and forward them to the main component running in onpremise Domain Controller which is Azure AD password protection DC agent.

Azure AD password protection DC agent- Receives the password validation request from the filter agent and processes them with the currently present local password policy and returns the validation response Pass/Fail. This core services queries the Azure AD password protection proxy service to check and download the new versions of password policy.

First step we need to install the proxy agent on a member server which in the same domain. 

Once installation is completed Import the Module –

Import-Module AzureADPasswordProtection

Register the Proxy Agent – 

$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds

Enter the Domain Admin Credentials

Later Enter the Azure Global Admin Credentials

Later Register  the  Active Directory Forest –

Register-AzureADPasswordProtectionForest 

On a successful registration we will be getting the below event log on the Azure AD password protection Proxy Server.

$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

Register the Proxy configuration on a static Port-

Below command can be run to make the proxy service communication and DC Agent Service to run on a static specific port. This option is preferred to keep a static single port communication from this proxy service server and the Domain Controller and not to have IP to IP communication between them.

Set-AzureADPasswordProtectionProxyConfiguration –StaticPort 135

Install the DC agent on the Domain Controller. After the installation is complete only a restart is required and no further configuration is required at this stage.

After this login to Azure AD and enabled the password protection on Windows server Active Directory. Always strictly recommended to start only in Audit mode to understand the current password security and user compliance from the logs.

Once enforced in audit mode we get the below confirmation message in Azure Password protection DC Agent Event logs.

We can verify the password protection agent settings by below commands

Get-AzureAdPasswordProtectionDCAgent | FL

Get-AzureADPasswordProtectionSummaryReport -DomainController DCHostName

Its always better to start this operation by only keeping them in Audit mode since it will create a major impact in the environment without proper end user awareness about enforcing this password policy change.

Also we can monitor the logs in event viewer in below location

A user resetting the password with the compliant characters will get a successful log as below 

If there was a non-complaint password reset by a help-desk operator it would be logged in the audit mode and mention it did not meet the compliant standards.

When the same password is provided to end user and when the end user resets them with non-compliant values then those entries also will be logged in the event viewer.

A Successful password policy update from Azure AD can be seen below from the Azure AD password protection proxy server.

We can also see that a separate Container is created in ADSI Edit and can see 2 certificates folder created with thumbprint name.

Important Notes:

  1. As a best practice its not recommended to  go with enforce mode initially since the end users will have tough time adopting the password policy immediately.
  2. Once the audit mode is enabled better to circulate email floaters about the upcoming password policy change which will create better awareness.
  3. The custom banned password policy is capable of having 1000 entries. We can gradually increase the value which will make this roll out  in  a smoother way.
  4. If we are updating the global banned password in the azure portal they are pushed down to the on premise agents in a polling interval of 1 hour time period.
  5. To Register-AzureADPasswordProtectionForest cmdlet to succeed at least one Windows Server 2012 or later domain controller must be available in the proxy server’s domain.
%d bloggers like this: