Joel Christiansen https://docs.microsoft.com/archive/blogs/joeleo/feed.xml How we fixed it, handy tricks, and other interesting stuff I want to share with the world Tue, 16 Apr 2019 06:11:45 GMT en-US hourly 1 SPN and user name/password errors when trying to add an additional AD FS server with a Group Managed Service Account https://docs.microsoft.com/archive/blogs/joeleo/spn-and-user-namepassword-errors-when-trying-to-add-an-additional-ad-fs-server-with-a-group-managed-service-account Thu, 08 Sep 2016 16:59:43 GMT https://blogs.technet.microsoft.com/joeleo/?p=245 https://ril3y.wordpress.com/2014/08/19/error-when-adding-second-2012r2-ad-fs-server-when-using-gmsa/ Essentially, there needs to be a trio of conditions met:
  • The AD FS server being set up is not the first AD FS server in the farm.
  • The AD FS service is being run under a Group Managed Service Account (gMSA).
  • There are no Windows 2012 R2 DCs in the site where the new AD FS server is being set up.
If these conditions are met, you may be presented with the following errors during install.
  • There were no SPNs set on the following service account '<ServiceAccount>'. Specify the service account used to configure the other Federation servers in the farm, or set host SPN for the farm on the service account.
  • The user name or password is incorrect
  • Unable to determine the Service SPN. There were no SPNs set on the following service account '<ServiceAccount>'. Specify the service account used to configure the other Federation servers in the farm, or set host SPN for the farm on the service account.
  • Unable to retrieve configuration from the primary server. The user name or password is incorrect
  • One or more prerequisites failed. Please fix these issues and click "Rerun prerequisite check"
  In this scenario, there was no possibility of getting a 2012 R2 DC in the new AD FS server's site. So, we started looking for work arounds. We set the following registry key to hard code the new AD FS server to a specific site and override automatic site lookup. Path= HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ Name= SiteName (String) Value= <Name of the Site where the 2012 R2 DC is located> After setting this new registry value, we rebooted the server. We configured the server as a new AD FS server in an existing farm, still using the gMSA account.  This time the configuration wizard completed successfully. We removed the SiteName registry value and rebooted. The AD FS service started just fine. :0) -Joel Shout out to Giles Pauli for all the help on how to manipulate site determination.   ]]> Admin Consent Option Missing https://docs.microsoft.com/archive/blogs/joeleo/admin-consent-option-missing Fri, 10 Jun 2016 17:37:29 GMT https://blogs.technet.microsoft.com/joeleo/?p=165 The Setup: An administrator had turned off user consent for Integrated Apps. This basically prevents users from being able to consent to an application to access the user's O365 profile data. Here is what the Integrated Apps setting looks like when it is disabled. ACIntegratedApps   Since the users no longer have the ability to provide access to their O365 profile data, the admin must provide consent on behalf of the users. The Story: The customer was trying to use the application https://fasttrack.microsoft.com, however, the application wasn't providing the option for the admin to approve for the entire organization. The admin would only get the option to approve consent for the admin account only. The Fix: This turned out to be an application behavior issue. The solution is simple, but not at all obvious.  After clicking sign in, the admin will be presented with one of the two sign-in screens below depending of the user already logged in before or not.
  • On this screen, add the following text to the end of the URL: &prompt=admin_consent
  • After adding this text, press enter in the address bar to refresh the page with the new setting.
  • Then complete the sign-in
(Admin hasn't signed in before)     ACSignon1 (Admin has signed in before) ACSignon2 After refreshing the sign-in page with the new setting and signing in, the admin will see the option to provide consent for all users to O365 profile data. ACSignon3  ]]> Unable to delete Azure B2C directory https://docs.microsoft.com/archive/blogs/joeleo/unable-to-delete-azure-b2c-directory Fri, 06 May 2016 13:37:15 GMT https://blogs.technet.microsoft.com/joeleo/?p=115 https://support.microsoft.com/en-us/kb/2967860 I've had a few customers hit the following error when trying to delete a B2C directory.

Cannot delete '<B2cDirectoryName>' The following issue(s) prevented deletion of this directory: • Directory has one or more applications that were added by a user or administrator.

NoDelB2C When the admin browses to the Applications section of the directory, they don't see any application to delete. Here are the instructions to delete the b2c-extensions-app that gets added to the directory when an Azure B2C directory has been configured. First, browse to the directory in the classic portal:
  1. Click on Active Directory on the left hand ribbon
  2. Click on the little arrow next to the B2C directory
This will open that directory and show you the options. BrowseToB2CDir Second, expose the b2c-extensions-app and delete it.
  1. Click the Applications option along the top row.
  2. In the Show selection box, choose Applications my company owns
  3. Click the check box to the right to refresh the application list with the new selection.
  4. Finally, click the DELETE icon on the bottom ribbon. Confirm the deletion of the b2c-extensions-app.
DelB2CApp3 After the b2c-extensions-app is removed, you will be able to delete the directory. Yay! -Joel  ]]> Login to O365 fails with error "We received a bad request." https://docs.microsoft.com/archive/blogs/joeleo/login-to-o365-fails-with-error-we-received-a-bad-request Fri, 25 Mar 2016 14:14:27 GMT https://blogs.technet.microsoft.com/joeleo/?p=103 The Setup: Two Web Application Proxy Servers and two AD FS 2.0 servers. Users are Office 365 users with a federated domain suffix so they must authenticate via AD FS. The Story: Initially, only a few users were having issues logging into Office 365. As the day wore on, more and more users were having issues until there was a full on outage. Both internal clients and external clients were affected. The clients were getting this error when trying to log into Office 365 
Sign In
Sorry, but we're having trouble signing you in.
We received a bad request.
Additional technical information:
Correlation ID: <ID>
Timestamp: <timestamp>
AADSTS50008: SAML token is invalid
The Hunt: On the AD FS servers there were no errors being logged in the AD FS/Admin event logs. We were able to browse to the self test site: https://<ADFS Server public FQDN>/adfs/ls/IdpInitiatedSignon.aspx Using the test site, a user account using a machine located within the corporate network, was able to authenticate successfully against AD FS. But logging into O365 failed for the same users. As we were switching remote desktop sessions, the administrator, from the corner of his eye, noticed a time skew between the AD FS server time and the WAP server time.  Upon further investigation, we found that the domain machines all had a time skew of about 20 minutes in the future of the actual time. Since the WAPs are not joined to the domain, they are not using the DCs as the time source. This time skew made perfect sense in relation to the error the clients were receiving.  The authentication token that AD FS was granting was not yet valid when it was received by O365 servers. The Fix: We set the time right on the DCs and rebooted the AD FS servers. After the AD FS servers were available again, with the correct time, users were able to log into Office 365 successfully. :0)]]> Web Application Proxy PowerShell cmdlets are not available in x86 https://docs.microsoft.com/archive/blogs/joeleo/web-application-proxy-powershell-cmdlets-are-not-available-in-x86 Mon, 01 Feb 2016 15:20:40 GMT https://blogs.technet.microsoft.com/joeleo/?p=33 The Setup Starting in Windows Server 2008 R2, the operating system no longer ships on the x86 platform (link). However, there are many backward compatibility features included in the x64 product to enable older 32 bit applications to run without issue on the x64 platform. One of the compatibility features is a x86 PowerShell executable. On the start screen, type Powershell, and you will see the x86 version of the prompt.

The Setup

Starting in Windows Server 2008 R2, the operating system no longer ships on the x86 platform (link). However, there are many backward compatibility features included in the x64 product to enable older 32 bit applications to run without issue on the x64 platform. One of the compatibility features is a x86 PowerShell executable. On the start screen, type Powershell, and you will see the x86 version of the prompt. PS943ur Here are the actual paths: 
Powershell
x64: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
x86: %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe

Powershell ISE

x64: %windir%\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe
x86: %windir%\syswow64\WindowsPowerShell\v1.0\PowerShell_ISE.exe

The Story

A customer and I were working on updating the Service Communications certificate for AD FS. We had a change document that we were following, based primarily on the information in this blog post.  During the  change implementation window, we hit a snag. The command to update the Web Application Proxy (WAP) SSL certificate was not working. (Set-WebApplicationProxySslCertificate -Thumbprint <thumbprint>) This was the error: PS943as 
Get-WebApplicationProxySslCertificate : The term 'Get-WebApplicationProxySslCertificate' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-WebApplicationProxySslCertificate
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-WebApplicationProxySslCertificate:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
However, we had tested this command in the validation environment previously without issues. Why was the command now failing?

The Hunt

It turns out that if we look for the Web Application Proxy commands in the x86 PowerShell prompt, we don't get any results. Get-Command -Module WebApplicationProxy PS943are   However, if we look for the commands at a x64 PowerShell prompt, we see the commands. PS943asr

The Fix

As you may have surmised by this point, the fix was to run the commands at the x64 prompt. PS943534 I don't know for certain why there isn't an x86 version of these commands, but I suspect it may be because the Web Application Proxy wasn't available until Windows Server 2012 R2, the third generation of the OS that doesn't ship for the x86 platform. I wouldn't be surprised if there are other modules that don't have a corresponding  x86 module. In fact, I think it will become more common as x86 becomes increasingly antiquated.]]> A tale of Event 422 on WAP servers https://docs.microsoft.com/archive/blogs/joeleo/a-tale-of-event-422-on-wap-servers Fri, 08 Jan 2016 19:45:03 GMT https://blogs.technet.microsoft.com/joeleo/?p=21 The Setup: Two Active Directory Federation (AD FS) Servers running Windows 2012 R2, located on the corporate network. Two Web Access Proxy (WAP) servers located in the DMZ. The Story: At first event 422 was logged here and there, but over the course of a couple of days, it began to be constant. The error being logged was occurring on the WAP servers in the AD FS\Admin log. 
Log Name:     AD FS/Admin
Source:       AD FS
Event ID:     422
Task Category: None
Level:         Error
Keywords:     AD FS
Description:
Unable to retrieve proxy configuration data from the Federation Service.

Additional Data
Trust Certificate Thumbprint:
<snip>
Status Code:
Exception details:
 System.Net.WebException: The operation has timed out
 at System.Net.HttpWebRequest.GetResponse()
 at Microsoft.IdentityServer.Management.Proxy.StsConfigurationProvider.GetStsProxyConfiguration()
  However, the WAPs were able to establish the trust to the AD FS server successfully: 
Log Name:     AD FS/Admin
Source:       AD FS
Event ID:     391
Task Category: None
Level:         Information
Keywords:     AD FS
Description:
The federation server proxy was able to successfully establish a trust with the Federation Service.
Eventually, the WAPs stopped servicing authentication requests to the AD FS servers. The Hunt: We took a network trace while restarting the AD FS service. We found that after the WAP connected to the AD FS server, the WAP was the last to send a TCP ACK and then there was no traffic on the connection. After 100 seconds exactly, the WAP sent a TCP FIN and closed the connection.   The customer mentioned that when starting the Device Registration Service the service took a long time to start. We investigated this angle and found that Device Registration was initialized (Initialize-ADDeviceRegistration had been run), but Device Registration was not actually being used. When we ran Get-AdfsDeviceRegistration on the AD FS server, it took about 3 minutes to complete. At this point, I’m thinking about how the WAP closes the connection to the ADFS servers after 100 seconds, but it Get-AdfsDeviceRegistration is taking at around 180 seconds. We tried to update the DRS configuration via PowerShell on the WAP to isolate this process. Sure enough, the process failed. 
PS C:\> Update-WebApplicationProxyDeviceRegistration
Update-WebApplicationProxyDeviceRegistration : Unable to retrieve Device Registration Service configuration data from
the Federation Server.
At line:1 char:1
+ Update-WebApplicationProxyDeviceRegistration
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo         : NotSpecified: (:) [Update-WebAppli...iceRegistration], ConfigurationErrorsException
+ FullyQualifiedErrorId : System.Configuration.ConfigurationErrorsException,Microsoft.IdentityServer.Management.Pr
oxy.Commands.UpdateAdfsProxyDeviceRegistration
  We continued to troubleshoot DRS and eventually came across the following hotfix: 3020773 Time-out failures after initial deployment of Device Registration service in Windows Server 2012 R2 https://support.microsoft.com/kb/3020773/EN-US While the symptoms manifested in this case were quite different than what is documented in the hotfix, the symptoms were in line with “it takes a long time to find a valid key”. Taking a long time to find something would definitely result in an operation timing out. The hotfix sounded promising. The Fix: We needed to prepare the machines for the update: Install this rollup first. 2919355 - [Windows 8.1 Update 1] Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: April 2014   (https://support.microsoft.com/kb/2919355) (If you get a "not applicable" error installing 2919355, install https://support.microsoft.com/en-us/kb/2919442 ) Install this rollup second. 3000850 November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 (https://support.microsoft.com/kb/3000850)  Finally, install the DRS issue hotfix. 3020773 Time-out failures after initial deployment of Device Registration service in Windows Server 2012 R2 https://support.microsoft.com/kb/3020773/EN-US After installing the updates on the AD FS and WAP servers and rebooting all the machines, the issue was resolved.]]>