Author: Adam Fowler

Azure AD Connect Pass-Through Authentication Tips

Posted on by Adam Fowler

A few days ago, an updated version of Azure AD Connect was released – 1.1.371.0 (download). This included the public preview of Passthrough Authentication and Seamless Single Sign-on which lets an internal domain connected computer authenticate against an internal domain controller and sign into Office 365 resources. This gives a great cheap option to do this rather than requiring ADFS on premise to do this or just entering user credentials to authenticate against Azure AD; but there are caveats I’ll cover below.

Install Gotcha

After you’ve updated the client (regardless of the authentication type chosen), there’s a quick ‘gotcha’: The Azure AD Connect application shows a different message when you launch it:

“Synchronization has been disabled to allow changes to your current configuration. Azure Active Directory will not receive further updates until reconfiguration is complete.”

 

This is very different from previous versions:

As I was testing passthrough authentication at the time, I misunderstood this message to mean that something was being configured, and I had to wait. What it actually means is that by launching the application, syncs are now paused until you go finish with this program; either by making a configuration change or just exiting.

This also means that if you leave this window open, synchronization will not occur again until it’s closed – even if you have multiple servers set up. If you get an email alert saying synchronisation hasn’t occurred for a while, this is the first thing to is to check that someone didn’t leave the application open.

Azure AD Connect Passthru Auth

I’ve been waiting all year for this option, but there is a lot of misinformation around what it actually can do. After having the privilege of speaking to the Senior Program Manager on SSO and Passthru Auth for Azure AD Connect Ross Adams for two hours (thanks Ross for your invaluable time!) I found out about these key points:

  • Passthrough Authentication right now does not give you a pure automatic authentication experience. It avoids the requirement of having to retype your password, you still need to choose your account
  • Azure AD App Proxy is required for Single Sign-on and Passthrough Authentication, but won’t function for actual application proxying when in this mode. You’ll need a different box running App Proxy if you use it this way.
  • Appending your domain onto supported urls with WHR (Custom login page e.g. https://login.microsoftonline.com/?whr=contoso.com) will reduce the amount of clicks a user needs to get in – generally a single click to pick their account

This doesn’t quite match the experience compared to having ADFS on premise, as I confirmed with friend     Ken Goodwin. This is his explanation of the ADFS experience:

If you just go to office.com to logon, after you type in your email address it’ll redirect you to the adfs server which will automatically log you on (assuming internal). If you pre-specify the domain using https://login.microsoftonline.com/?whr=domin.com, then the logon will be automatic.

This might act differently if you’re able to enable auto-acceleration on your SharePoint sites at least which drops the WHM requirement – as long as you have Azure Active Directory Premium.

Keep in mind, Passthrough Authentication and Single Sign-On are still in public preview so this may change and improve. I’m still having a mixed experience on a few items, so don’t go too crazy with rolling this out to your live setup yet. I expect we’ll see some updates soon, and finish up with a really solid new feature to improve the experience for all.

Update: Another tip – if you disable and re-enable Pass Through Auth then your old Kerberos tickets will be invalid. Wait 10 hours or run the command “Klist purge” on an affected PCs – otherwise you’ll get weird authentication errors when trying to log into a site.

Websites Timing Out – This Page Can’t Be Displayed

Posted on by Adam Fowler

timeout

I came across this issue where a particular user was getting lots of timeouts for websites via Internet Explorer. The problem didn’t follow the user to other PCs, and I couldn’t see any firewall issues. The websites were random, but I did notice they were generally slow to load websites.

Another symptom was getting this same error when signing up for things or processing payments – all processes that can take a while to respond. Even loading pictures on emails sometimes timed out this way!

I did find a 3rd party search engine had been added to IE and removed that, but that made no difference.

After a bunch of testing and research being convinced it was a local profile issue, probably around IE timeout settings, I found this article which gave a registry setting around timeouts. I adjusted the value for KeepAliveTimeout in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings but it made no difference.

What I did notice though, was another registry value in the same spot – ReceiveTimeout. This was set to 5000 which would equate to 5 seconds converted from milliseconds, similar to the KeepAliveTimeout setting.

Comparing it to another computer, that registry setting didn’t even exist. I tried upping the value to 60000 for a minute, and after lots more testing, the problem appeared to be fixed! I then deleted the registry key and the problem didn’t reoccur.

My assumption is that the 3rd party search engine (which seemed a bit dodgy) added certain registry settings under the user’s profile for their own purposes, and removing it didn’t clear it up.

Of course, deleting the profile would have had the same result, but then we wouldn’t understand why it broke!

 

 

Changing Many File Permissions Without Inheritance

Posted on by Adam Fowler

I ran into a scenario when moving files from an older Windows Server 2003 box to Windows Server 2012, where I couldn’t access folders even as an administrator.

It turned out that not having Users (ServerName\Users) causes problems beyond Windows Server 2003. When moving a mass of files with many folders lacking inheritance, this can be a problem.

After some research and testing, it’s reasonably easy to modify NTFS security permissions to lots of files, while leaving existing settings in tact and not requiring inheritance to apply changes.

Scripting Guy covered it pretty well here, but here’s the condensed version:

First, install File System Security PowerShell Module because it’s easier to do than using native PowerShell Set-ACL commands. This can be installed on a remote box from where the files are, but remote can be slow based on latency and the amount of files you’re dealing with. Read the installation notes on that page so you’re ready to go with the module.

You can test it’s working by running a command like:

get-ntfsaccess -path c:\PutAFilenameHere.Now

You’ll get the permissions of the file back.

To change your permissions on mass, you need to get a listing of the files and pipe that to your modified settings:

dir \\FileServerName\ShareName -recurse | add-ntfsaccess -account “BUILTIN\users” -accessrights read

Note that the -recurse switch gives you all files and subfolders of the share, and although the permission you’re looking at via Windows Explorer will show Users (ServerName\Users), this is actually the BUILTIN\users permission. If you try to use the servername, you’ll get this error:

Add-NTFSAccess : Cannot bind parameter ‘Account’. Cannot convert value “servername\users” to type
“Security2.IdentityReference2”. Error: “Some or all identity references could not be translated.”

That’s it, you can now add, remove or modify permissions all over the place without affecting other existing permissions or affecting the inheritance.

Edit: The actual issue I describe here can also be fixed by changing a few Group Policies too.

AzureAD – Assign Application to User via PowerShell

Posted on by Adam Fowler

Scenario:

You’ve created an application in Azure AD, and want to script allocating access to the app rather than using the web interface. App show up at https://myapps.microsoft.com

Azure AD Premium is required for group access which would be ideal, but if you don’t have that you’ll need to add access on a user by user basis.

Answer:

PowerShell of course. First, you’ll need Azure AD for PowerShell (Preview version 2.0.0.17 at time of writing).

The below script which I modified from Philippe’s comment here should cover both internal, cloud and B2B invited users. The original script was using -objectid rather than -searchstring which works better and is more accurate for the internal and cloud accounts, but doesn’t work at all for B2B accounts.

The AppID can be obtained from this command:

Get-AzureADApplication -SearchString “Display Name for App”

Put the corresponding AppID into the below script, and you’re good to go. You’ll get prompted for Azure AD credentials as per usual. You can also get this

This is designed for a single user addition, but you could easily import the email addresses from a CSV file, and do a ‘for each’ on each entry like I did here.

# The UserPrincipalName or ObjectId of the user
  $userId = "[email protected]"

# The AppId (a.k.a. "client ID") of the app to assign the user to
  $appId = "AppIDGoesHere"

# Connect to Azure AD
  Connect-AzureAD -Confirm

# Get the user to be added
  $user = Get-AzureADUser -searchstring $userId

# Get the service principal for the app you would like to assign the user to
  $servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"

# Create the app role assignment
 new-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId $servicePrincipal.ObjectId -Id ([Guid]::Empty)

 

Note: If you try this and get the error below, it’s because the app is already assigned.

new-AzureADUserAppRoleAssignment : Error occurred while executing NewUserAppRoleAssignment
StatusCode: BadRequest
ErrorCode: Request_BadRequest
Message: One or more properties are invalid.
At Z:\script.ps1:17 char:1
+ new-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-AzureADUserAppRoleAssignment], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewUser
AppRoleAssignment