Azure AD SSO in a non-ADFS environment – Windows 10

In a world without ADFS.. Single Sign On is possible..

Having made the migration from onsite Exchange and SharePoint to Office 365 in early 2015 one of the key issues that users had was the lack of single sign on facilities to applications based in the cloud. You might ask why didn’t you use ADFS for your implementation, well I like many SME systems admins had made a conscious decision to run with DirSync as this lowered the overall foot print of our hybrid set up, I also liked the idea that even in the event of a complete loss of internal resources the Office 365 cloud would still allow employees to authenticate.

In my case the decision was concreted only after speaking with Microsoft Office 365 speakers and product development engineers, as their view was unless you have a specific reason for using ADFS then the DirSync product road map with the migration to Azure AD Connect would be more than sufficient for my needs. I convinced my manager and the migration went ahead..

So to fast forward to today and with the improvements in the ability to sync details to and from Azure Active Directory without an ADFS environment I am going to run through one of the newer authentication features of Windows 10, this being Azure AD SSO on domain joined devices.

Single Sign On without ADFS.. What Is This Black Magic???

The ability to open cloud based resources which integrate with Azure Active Directory without having to sign on again has been the domain of ADFS up until this point. With the latest release of Azure AD Connect and Windows 10 1511 on-wards however we can now achieve a similar experience.

The system works by issuing authentication tokens when registering the physical device of the user. Further in depth technical info is available on TechNet – https://blogs.technet.microsoft.com/enterprisemobility/2016/02/17/azure-ad-domain-join-windows-10/

So How Do I Implement It?

The implementation process is very straight forward;

  1. Enable users to join devices to Azure AD

    Log onto the Azure Admin Portal, open your tenant and click on the Configure tab. Scroll down to the Devices section and apply either a selected or all device configuration depending on your security requirements. Example screenshots below;

  2. Download and install the latest version of Azure AD Connect from https://www.microsoft.com/en-us/download/details.aspx?id=47594.azureaddownloadNote if you are still using DirSync or Azure AD Sync, you should migrate to Azure AD Connect before the 13th of April 2017 as support will be deprecated at that point. The upgrade process from these old legacy tools is very straight forward during the setup wizard.
  3. Ensure your Windows 10 clients are compatible

    Windows 10 build 1511 (November 2015) onwards support Azure AD SSO device join via group poilcy. If you are running the RTM build 10240, you will need to upgrade first.To check this either open a command prompt and read the Windows version on the second line or open PowerShell and type;

    (Get-WmiObject win32_operatingsystem).version

    checkwindowsversion

    For those of you using SCCM, I suggest you create a collection based on the version of Windows 10 for management purposes. The following query will add clients running build 1607 to your collection;

    select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.BuildNumber = “14393”


  4. Update Your Central Store – Group Policy Administrative Templates In order to enable this feature you will need to ensure that your group policy administrative templates are up to date. The latest Windows 10 templates can be downloaded from the following link – https://www.microsoft.com/en-us/download/details.aspx?id=53430azureadtemplates
  5. Enable Device Sync – Azure AD Connect

    Now we have to enable device synchronization with Azure AD. There are two ways to achieve this, you can either run the Azure AD Connect wizard or edit the connectors yourself. In the below example I am going to go with the later;

    • On your Azure AD Connect server, open the Synchronization Service Managersyncscreen1Right-click on the Connectors button and right click on the Active Directory Domain Services and to to Properties
    • Configure Directory Partitions Click on Configure Directory Partitions and then click on the Containers button.syncscreen2
      When prompted enter an account with sufficient rights to Active Directory.
    • Select Computer OU to Sync Browse through your Active Directory and select the OU’s which contain computer accounts you wish to synchronize to Azure AD for the purpose of using Azure SSO.

      syncscreen3

    • Force Full Synchronization

      Right click on your Active Directory Domain Services connector and click on Run.

      syncscreen4

      On this screen click on the Full Import button. Once this job has completed do the same for the Windows Azure Active Directory connector.

  6. Configure GPO Settings

    Open Group Policy Management Editor and either create a new GPO or modify an existing one which applies settings to computers within the OU’s you have set to sync.

    Open the Computer Settings\Policies\Administrative Templates\Windows Components\Device Registration folderClick on the Register Domain Joined Computers As Devices setting and click Enable.

    GPODeviceReg.jpg

  7. Have Patience…There will obviously be delay between devices refreshing their GPO policies, Azure AD Sync times and devices registering.
  8. Verifying Device Sync Status

    Download the Microsoft Azure Active Directory Module for Windows PowerShell from the following link : https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/Open a Azure AD Module PS window and connect to your Azure tenant environment by typing;

    Connect-MsolService
    


    azurepsconnect

    Once connected type the following to display a full list of registered devices and their current state;

    Get-MsolDevice -All | FT DisplayName, DeviceOS*, DeviceTrust*
    


    adpslist

    You can also run the following PS command to get a count of machines registered and compare this to your SCCM collection;

    (Get-MsolDevice -All).Count
    


Its Done..

Once your devices are successfully registered, your users should be automatically signed into their Azure AD cloud services. Now you have another little win for making their lives that bit easier without going to the extent of implementing a full ADFS environment.
Update – 29/9/2016

With the latest 16.0.7341.2035 build of Office 2016, SSO is now fully functional when opening Outlook. The below screen is now presented to the user rather than the usual Add Account wizard which prompts you for your password at the end. Now all the user has to do is click Connect and the settings download & sign in happens in the background in the initial launch;

outlook

 

 

Automating Management of Local Administrator Passwords – Microsoft LAPS

Managing Local Administrator Passwords

So you have a complex password policy on your domain, ensuring that users change their password every 60-90 days, passwords are complex, their passwords can’t be re-used and your users are not local admins but one thing poses a security risk, the local administrator password.

The chances are you have deployed your standard Windows image using a password specified within the image/MDT or SCCM task sequence and in some cases you do not have the IT resources to ensure that this password is changed on a regular basis and even if you are, are you ensuring that the passwords are being documented and stored securely?.

Security Risk – Local Administrator Rights

If you do not have a well maintained local administrator password strategy it opens your network up to security vulnerabilities including elevation of privilege. It isn’t going to go down well when your standard local workstation admin password is shared and users add themselves to the local admin group, potentially in a worst case scenario adding malware, key loggers etc.

The Answer – Microsoft Local Administrator Password Solution (LAPS)

Microsoft LAPS is a free tool released back on May 1st 2015 and allows you to automate the process of updating local administrator passwords on your workstations and servers across your Active Directory domain/forest. LAPS uses a local agent in conjunction with GPO deployed settings to update the local administrator password at set intervals, based on complexity settings that you specify and most importantly it automatically stores backups of this info within Active Directory.

Deploying Microsoft LAPS

First of all you will need to download the installer from the following URL – https://www.microsoft.com/en-us/download/details.aspx?id=46899. In the below section we will run through the entire installation and configuration process;

  1. Management Server Installation

    A single installer is used for both the server and client installs, the only real difference being that the management tools need to be installed on the management server. Run the LAPS.x86 or LAPS.x64 installer as per your system architecture, then run through the following;

    1. Launch the installer

      install6

    2. At the custom setup screen select the management tools and select run from my computer and then click Next

      install4

    3. Click on the Finish button to finalise the install

      install1

  2. Active Direct Schema Modification

    In order for computers to write back their local administrator passwords and expiry date/time, a schema update is required. The update adds the following two values:

    ms-Mcs-AdmPwd – Stores the password in clear text
    ms-Mcs-AdmPwdExpirationTime – Stores the time to reset the password

    To add these values, launch a PowerShell session on your management server and perform the following actions;

    • Type – Import-Module AdmPwd.PS to import the required LAPS module

      psscreen1

    • Type – Update-AdmPwdADSchema

      psscreen2

      Note: If you have an RODC installed in the environment and you need to replicate the value of the attribute ms-Mcs-AdmPwd to the RODC, you will need to change the 10th bit of the searchFlags attribute value for ms-Mcs-AdmPwd schema objet to 0 (substract 512 from the current value of the searchFlags attribute). For more information on Adding Attributes to or Removing attributes from the RODC Filtered Attribute Set, please refer to http://technet.microsoft.com/en-us/library/cc754794(v=WS.10).aspx.


  3. Active Directory Rights


    Computer Rights

    In order for computer accounts to write values to the ms-Mcs-AdmPwdExpirationTime and ms-Mcs-AdmPwd attributes in Active Directory, the following PowerShell command needs to be run (note if closed the previous PowerShell window you will need to run Import-Module AdmPwd.ps again)

    Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>
    


    User Rights
    By default members of the Domain Admins group will have rights to view the local administrator passwords stored in Active Directory, however what happens if you want your desktop support team to view them?. To facilitate this you will need to delegate rights.

    To do so use the following PS command:

    Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>
    

    Going another step further you can also delegate rights to allow groups or individuals to force a password change. To do so use the following PS command:

    Set-AdmPwdResetPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>
    


  4. Group Policy Configuration

    First of all you will need to copy the LAPS ADMX and ADML files to your central store. The two files are located in the %WINDIR%\PolicyDefinitions folder on the management server.

    Now follow the below;

    1. Open Group Policy Manager and either create or modify a GPO that you wish to apply the LAPS settings.

    2. Expand Computer Configuration\Policies\Administrative Templates\LAPS

    gposettings1

    3. Configure your Password Settings, Name of the Local Admin Account and Enable Password Management, as per the below examples:

     

  5. Deploying the LAPS client
    Deploying the client is a simple process. Using the same MSI installation files you can deploy the client to your x86 and x64 clients via GPO, SCCM or other third party application deployment systems. Simply use the /quiet switch for client deployments.
  6. Check its working..Active Directory Users & Computers

    Opening the Active Directory Users & Computers console and viewing the Attribute Editor of a machine located within the OU that you earlier deployed your LAPS enabled GPO to, should result in values being available as per the below screenshot;

    aducscreen

    LAPS Admin GUI

    On the management server that earlier installed LAPS on, you will have the LAPS GUI. This will allow you to both look up details from computers but also set a new expiration date for the existing local admin password;

    lapsadmin

For more info on LAPS, visit Microsoft TechNet – https://technet.microsoft.com/en-us/mt227395.aspx