ADFS User Sign-In Customization

Posted on by Scott Shelton

I’m not going to lie to you, like most of my posts this is just a reference for myself but hey maybe one of you stalkers of the interwebs didn’t know how to do this.  Anywho there is a whole bunch of customizations that you can make to the ADFS sign-in page with simple PowerShell one liners, all of which can be found at this page (and its linked pages).  Me, I’m just going to highlight the few that I do.

Change the Company Logo:

Change the Illustration (the wallpaper-like image on the left side):

Customize the Update Password Page Description:

Add Help Desk Link:

There are many other things you can customize by following the link at the beginning of the post, but these are the ones I like to set.  That’s it for this one!

Enabling Password Change in ADFS 3.0

Posted on by Scott Shelton

I would like to start this off the same way that many posts on this topic do by defining the difference between password change and password reset.  Looking at the two terms they seem like the same thing, but in the wonderful nerdy world that we call our home they are two very different things.

Password Change, the topic of this post, is the ability for an Active Directory user to change their password when they know what their password currently is.  Password Reset is when an Active Directory user does not know their password and must provide alternate recovery methods, for example a phone number or security questions.  While Password Reset functionality is cool and completely possible with ADFS (psst Password Writeback), that will have to wait for another post.  Today we are focused on Password Change with ADFS, introduced in 3.0 to my knowledge, which is most commonly used for resetting expired passwords/newly setup accounts.  Without further ado, let’s dig into it.

1.  Start by logging into your ADFS server and opening AD FS Management.

2.  Expand out Service, select Endpoints, and scroll down to the Other section where you will find /adfs/portal/updatepassword/.

3.  Right click on it and choose Enable.  Restart the ADFS service and Password Change is now available on the corporate network!

4.  Chances are that you want to enable this for users on external networks (where it’s most useful).  Do this by right clicking the /adfs/portal/updatepassword/ endpoint again and selecting Enable on Proxy.  Restart the ADFS service again and Password Change will be fully enabled!

Restore a Deleted Office 365 Group with PowerShell

Posted on by Scott Shelton

Oops…So I accidentally deleted a few O365 groups last week.  Happens to everyone at some point right?  Luckily, as long as it has been less that 30 days since you deleted it, you are in the clear and can restore it!  Note: If you were a try hard and used Remove-MsolGroup to delete the group, you’re screwed.  Full disclosure the very detailed walk through I followed can be found here, but I am going to do my own quick write up for future reference.  With all that being said, strap in!

We need to start by installing the AzureADPreview PowerShell module.  Yeah, it’s in preview (haha).  So pop open a PowerShell window as administrator and run the following.  If you have a previous version of the module you will need to uninstall it and install the most up to date version.

Tough stuff.  You may receive the following prompts to download the repository and that it is untrusted.  Accept them, they’re not super hackers or anything.

Now we are all prepped and ready to go.  If you closed that PowerShell window get it open again as administrator.  Run the following to restore your group (further instructions below).

It’ll take a few seconds but you will now have your group restored and can go back to normal.

 

Convert Federated Domain to Standard with PowerShell

Posted on by Scott Shelton

This is a rather unique scenario that I found myself in recently.  I must admit, tearing down domain federation is infinitely easier than getting it set up!  Anywho, the following details the steps involved in converting a federated Office 365 domain to a managed domain and removing DirSync from Office 365.

1.) Open a PowerShell window as Administrator on a box with the msol cmdlets and connect to your Office 365 tenant

2.) Run the following command to convert the domain to a standard domain

3.) Run the following command to remove DirSync from Office 365

 

Step-By-Step Installation of Active Directory Federation Services (ADFS) using Azure AD Connect

Posted on by Scott Shelton

ADFS setup can be nothing but a headache to set up when you are new to it.  You know it.  I know it.  We all know it.  So this is my step-by-step guide for setting up a basic ADFS configuration.  Now, this is going to detail a successful installation without any errors (which does happen once in a blue moon).  To see resolutions to the errors that I have encountered in the past, please reference this post.  I will try to keep adding things as I come across them, but no guarantees.

As with anything that needs to be configured, setting up your prerequisites is key to your success.  Often not setting up your prerequisites properly will become your greatest frustration.  For reference see the Microsoft Official Post, but I will also be going through them now.  For port requirements, see this post.

Prerequisites:

1.   Download Azure AD Connect and copying that to the internal box you will be installing the ADFS role on to be installed later.

2.  Enable TLS 1.2 (Server 2008R2 and later) and configure .Net to use it by adding the following registry values and restarting the machine (I do this on both the ADFS and the WAP box).

3.  Create a Forward Lookup Zone for the domain you are federating in your local DNS.  Add an A record (Host) for adfs pointing at your ADFS server.  This will have internal requests resolve directly to the ADFS server.  In your internal domains forward lookup zone, create an A record for your web application proxy (WAP).

4.  Modify the host file on your web application proxy (WAP) to resolve adfs.domain.com to your internal ADFS server.  Public DNS should resolve adfs.domain.com to the WAP Public IP.

5.  Run the following command on both the ADFS and WAP box to enable Windows Remote Management (WinRM):

6.  On the ADFS box, add the WAP box to you WinRM Trusted Host list with the following:

7.  Confirm WinRM is functional by running the following from the ADFS box:

8.  Obtain a valid SSL certificate for the ADFS subdomain of your federated domain (ex. adfs.domain.com).  See this post about creating a custom csr with an exportable private key from your web application proxy (WAP).  Make sure you use the Legacy key template.  Export that to a PFX with its private key and copy it to your ADFS server.

9.  Add the domain name you plan to federate to your domains UPN Suffixes via Active Directory Domains and Trusts.

10.  Download Microsoft Exchange Server (Current version is 2016 found here).  Copy that to the Domain Controller that holds the Schema Master role, open a command prompt window in that directory and run the following command:

11.  Create a Group on the domain you plan to federate to specify which user accounts will be synced.  This is optional as you can choose to sync all user accounts if you wish.

12.  Create a service account on the domain that you plan to federate and add it to the Domain Admins and Enterprise Admins groups.  You can split this into two accounts if you wish.

13. Pro-Tip: Check the time and date on your servers.

Installation:

1.  Run the Azure AD Connect .msi to install it and agree to the license terms when prompted and select next.

2.  Select Customize

3.  Select the “Use existing service account” option and input the service account credentials you set up during prerequisites and select Install.

4.  After a little while you will be brought to a User sign-in window.  Select the “Federation with AD FS and select Next.

5.  Insert Global Administrator credentials for your Azure AD/Office 365 and select Next.

6.  Add the local domain you wish to federate and select Next.

7.  Confirm the domain you wish to federate with is verified, that userPrincipalName is selected and select Next.  If your domain you wish federate with is not present/says Not Added you need to verify it in your Azure AD/Office 365 tenant.

8.  Confirm the options are selected as below and select Next.

9.  Select “Synchronize selected” option, add the DN of the your local AD group, confirm it resolves, and select Next.

10.  Leave everything unchecked and select Next.

11.  Upload your Certificate .pfx, confirm the appropriate Subject Names appear, and select Next.

12.  Input the FQDN of your ADFS server, select Add, and select Next.

13.  Add the FQDN of your WAP. select Add, and select Next.

14.  Input your service account credentials and select Next.

15.  If prompted, input your service account credentials again and select Next.

16.  Select the appropriate Azure AD domain to federate with and select Next (typically there is only one available).

17.  Select te “Start the synchronization process when configuration completes.” option and select Install.

Phew.  At this point go grab a cup of coffee, and maybe start praying a little bit.  Assuming everything was configured correctly, you will get a success message and be prompted to verify your DNS configuration.  Once that all checks out you’re off to the races!

 

 

Installing Office 2016 on RDS Server with Shared Computer Licensing

Posted on by Scott Shelton

When installing Office on an RDS Server accessed by multiple users, you need to configure the installation for shared computer licensing.  To do this, you begin by downloading the Office Deployment Tool.  Once you have that downloaded, run the executable.  This will provide you with two files; configuration.xml and setup.exe.  Edit the configuration.xml file and you should see something similar to what is below:

This is missing a few key configuration options, such as the “SharedComputerLicensing” which is the primary reason for this post.  Also, I’m personally not all that interested in adding Visio to most of my RDS environments, but I am interested in deploying the 64-bit version of Office.  See this Office Support page to see all of the configuration options.  It should look more like what is below:

Once you have that done, save the configuration.xml file.  Shift + right-click somewhere in the file explorer window and select the “Open command window here” option to make your life a little easier.  Then run the following two commands:

The second command will take a while as it is actually installing.  Once it is done, you are done!

Azure AD Identity Synchronization Error 105: UserPrincipalName is not valid

Posted on by Scott Shelton

Had a request to change the UPN from one Federated Domain to another today and it gave me a bit of trouble.  I made all the appropriate changes in AD thinking it would be that simple, but alas I began getting the following error on my DirSync to O365:

Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.

Looking at the synchronization service I got the same error with the error number of 105 (I was really hoping for more information).  I did some digging on the internet and came across this article that contained the answer to my problem.

Turns out that when switching a local AD account from one federated domain to another, Azure AD/O365 doesn’t like that too much and doesn’t make the change for you.  Lame.  So I used the following bit of PowerShell to resolve that:

Then kick off a Full Sync on your DirSync box, let it finish, and you’re good to go.

 

Office 365 “Mailbox hasn’t been migrated to Exchange Online” Error

Posted on by Scott Shelton

When working with an on-prem AD synced with O365 via Azure AD Connect (DirSync), I have been coming across this error from time to time with accounts that used to be connected with an on-prem Exchange server.

Error message received in Office 365:

To resolve this issue, follow the steps below.  As a general disclaimer, this will remove any existing mailbox.

  • Remove the AD account from the DirSync group and any groups that may apply licenses (essentially anything to do with O365).
  • Run either a Delta or Full sync via Azure AD Connect

  • Open PowerShell as administrator and run the following command:

  • Clear all of the AD User attributes beginning with msExch
  • Re-add the user account to all appropriate groups and run another Delta/Full Sync
  • Apply license in O365 and confirm mailbox creates successfully

ADFS Trials and Tribulations

Posted on by Scott Shelton

This post began as the couple issues I ran into the first time I ran through an ADFS deployment with Azure AD Connect.  As months have gone by and I have done this over and over, I have hit an impressive amount of weird issues.  Thus I am going to turn this post into more of a living document, where I dump issues that I come across when deploying ADFS with Azure AD Connect.  Follow this link for my Step-by-Step Guide.

Original Post:

The other day I was presented with a new challenge at work; to set up ADFS (Active Directory Federation Services) for syncing an on-premises AD for a new customer with their new Office 365 tenant from scratch.  Now I have done pieces of this process in the past, but I always had my “Obi-Wan” right behind me to correct me when I steered in the wrong direction.  “Old Ben” essentially told me it’s time to be a big boy and do it all so that’s what I did…but I hit a couple speed bumps along the way.  Do note this was all done on Server 2012R2, so it all pertains ADFS 3.0.

Issue #1: Cannot Add Web Application Proxy (WAP) during Azure AD Connect setup

My first issue occurred when I was configuring access to my WAP DMZ box.  I had all my PS-Remoting/WinRM and DNS set up appropriately yet for some reason I could not authenticate to my WAP.  Spoiler alert: this was a face palm moment.  All in all I could enter a PSSession without issue via PowerShell, but the Azure ADConnect wizard (found here) would not establish the connection.  Naturally I was flipping out how this doesn’t make sense since I literally had a PSSession open to the dang box at the time.  Long story short, I was trying to use the hostname of the box only instead of the FQDN that its record in DNS has (hostname.domain.com).  Even though the WAP box was a workgroup machine in the DMZ, the internal A record in DNS I created gave it an FQDN as if it were on the domain.  DUH!

Issue #2: ‘ma-run-data’ was not found. Line 1, position 2. Error

After that hour of frustration was over I moved through the wizard without any issues and it began installing all of the necessary requirements on both machines.  This generated an error because the service account was using for it to interface was an Enterprise Admin and not a Domain Admin.  No problem, I added the account to the Domain Admins group and hit retry to be met with another error (would you just work already!).  It kept failing with the error ‘ma-run-data’ was not found. Line 1, position 2.  A few Google searches later I found the solution was to run a Full Import on my AD Connector.  After this was done wa-lah no more error and installation completed successfully (Uncle Google credit found here).

Issue #3: User accounts not exporting with status “Connectors without flow updates”

Alas, this was not the end of my problems.  Now that I had everything installed and configured, I naturally wanted to Sync an account up to Office 365 and apply a license to test everything right?  Of course it didn’t work, why would it.  When under the Connectors section of my Synchronization Service the account that I was attempting to Sync up was showing under the “Connectors without flow updates” section.  This was a new one for me so I decided to dig into the Event Viewer logs to see if there was anything a little more enlightening.  I found the root cause of my issue there…four fresh errors.  I am just going to list the numbers here: 106, 108, 6801, 6803.  The answer to all four of my errors came from just one part of 108: Error validating credentials. AADSTS50054: Old password is used for authentication.  This took me down the hunting trail, I knew that it wasn’t my service account so it must have been the auto-generated account on the Office 365 side.  I changed the password, updated the connector via the AD Sync Service and BAM!  Problem solved.

That sums it up for the issues I had with my first time setting up ADFS from scratch by my lonesome.  I did have some help with using Postfix to route the SSL Cert emails, but you can see this post about that one.

Updates Since Then:

Issue #4: Your credentials are not authorized to access Windows Azure Active Directory.

When setting up a new ADFS instance recently on Server 2016 with Azure AD Connect I ran into the following error after hitting the install option:

I did some googling and found this post which told me to run the following command on the ADFS box and give it a shot:

Issue #5: Export Status = stopped-extension-dll-exception

Got everything up and running on a new deployment and I noticed my users weren’t exporting.  Ran to the Synchronization Service and came across the weird status you see below:

Came across this msdn blog post which made me reset the auto-generated synchronization user account password and wha-lah we’re fixed.  Seemed like a familiar issue…(Cough issue #3 cough).

Issue #6: Error when attempting to establish a trust relationship

This one popped up on me and I felt like the biggest dummy of all time.  I was really scratching my head on this one for a long time, but then I stumbled upon this technet post which made me look at the time and date on my WAP.  Yeah…they were a day apart.  Fixed that stupid issue and we were off to the races.  Pro-tip, always double check the little things you take for granted on non-domain joined machines!  #pool.ntp.org

 

Change Office 365 UPN from onmicrosoft.com with PowerShell

Posted on by Scott Shelton

Ran into an issue recently that was a little tricky.  I have a DirSync environment and two of my users for some reason decided that their UPN was going to be username@domain.onmicrosoft.com rather than username@domain.com.  There was no issues on the AD side.  All the attributes for the account were set appropriately, but the UPN in particular was just not making it up to O365 appropriately anymore.  I used the following bit of PowerShell to resolve the issue.