New Free Data Courses on Pluralsight Available!

Over the past two months I’ve been busy on some Data in Azure courses for Microsoft and Pluralsight. These are free and you just need to sign-up for a free account on Pluralsight. These will shortly be available via Azure as well but are available now through Pluralsight.

Azure Stack Marketplace Management

Been doing some work with Azure Stack and wanted to easily update all the Microsoft provided extensions and a set of core images if there are new versions by running a simple script.

Script available at https://github.com/johnthebrit/AzureStack/blob/master/azurestackmarketplace.ps1. Simply run the script and after it downloads the assets it will check if there are older versions and prompt you if you want to delete the old ones.

Lots of new Azure Design and Identity free training available

I may have seemed to be very quiet over the past few months but that’s because I’ve been working pretty much every night and weekend on 11 new courses for azure.com that will shortly be available via the site but are immediately available for free via PluralSight. If you don’t have an account simply sign up for a free account and you can then access my (and other peoples tracks).

Planning Microsoft Azure Identity and Security

Planning Microsoft Azure Infrastructure

The identity track looks at identity management before diving into authentication, authorization, auditing, monitoring and risk. The infrastructure track looks at compute, storage, networking and monitoring.

I hope you find these courses useful and there are more to come.

On a side note I’m trying to raise money for Cure Childhood Cancer as part of my Ironman Chattanooga on 9/30/2018. This will be my 5th Ironman this year and 12th overall. If you can help even a little please head over to https://www.firstgiving.com/fundraiser/john-savill/IM2018 and maybe your company matches so if they do that helps as well. I’ll be trackable on the day via https://bat.live/track/imchattanooga2018?bib=356.

Thank you!

Two new videos on Azure AD – Conditional Access and Tokens!

Recorded two new videos this week. The first is an understanding of how tokens work with Azure AD and then one looking at conditional access (which can control the access to get those tokens for various scenarios).

Word of caution – I talk about terms of use in the second video. If you just enable this for ALL users it will break things that can’t accept it, for example the account you use for Azure AD Connect to sync to Azure AD so make sure you exclude accounts that can’t accept!

Understand the authentication pros and cons with Azure AD

When using Azure AD there are two types of authentication available:

  • Cloud authentication where the authentication takes place against Azure AD
  • Federated authentication where the authentication takes place against the federated service, for example using ADFS against Active Directory Domain Services

When using the cloud authentication there are two ways to validate the password:

  • A hash of the password hash from AD is replicated to Azure AD (and no matter which authentication option used this is recommended to enable Azure AD to help detect leaked credentials and give a “break the glass” fallback authentication option if your primage configuration fails) and this is used for the cloud based authentication
  • The password validation is done against Active Directory Domain Services using Passthrough Authentication (PTA) which works by writing the username/password (in an encrypted form for each PTA agent configured) to a service bus instance which are then read by PTA instances deployed to Windows OS instances which take the entry, decrypt, authenticate against ADDS then respond with the result to then complete the authentication request

There are therefore three options for the authentication configuration

  • Password hash
  • PTA
  • Federation

The order I have them is generally the preference but there are some pros and cons of each (in addition to a few considerations) and I wanted to outline them briefly here.

Password Hash

  • Pro – Cloud scale/resilience since this is all native Azure AD with no other reliance during authentication
  • Pro – Provides breach replay protection and reports of leaked credentials since the stored hash can be used to compare against credentials found on dark web (visibility varies depending on Azure AD license, P2 provides best insight). Also enabled the ability to block banned passwords during password change. This benefit is for any configuration providing password hash is replicated and does not have to be used for the authentication
  • Pro – As above even if not using password hash for authentication if its stored and the primary method, e.g. PTA of federation fails (such as loss of connectivity to infrastructure) you can quickly switch to password hash based authentication
  • Con – If the ADDS account has been locked, restricted hours set or password expired it will not impact the ability to logon via Azure AD
  • There is a delay for new accounts or changes to be reflected from AD to Azure AD. This is typically a 30 minute replication window (except for passwords which replicate every 2 minutes). Therefore plan for a delay for new accounts/changes to be reflected in Azure AD
  • You may hear talk of a con is you want the authentication to occur against on-premises DCs however the way tokens and specifically refresh tokens work is only the first authentication would hit AD and after that future access in the same session would not re-authenticate via PTA/federation anyway as the refresh token would be used to acquire additional access tokens. I will cover this in a separate video.

Passthrough-Authentication (PTA)

  • Pro – If a concern with this method you don’t have to store password hashes in Azure AD (however this is a risk vs reward discussion and the benefit of having the hash greatly outweighs any downside IMO)
  • Pro – This is lighter than using federation and establishes an outbound 443 connection to Azure AD not requiring any inbound port exceptions
  • Pro – Any AD account restrictions like hours, account lockout, password expired would be enforced
  • Con – Legacy authentication (pre 2013 Office clients) may not work with PTA
  • This is lighter than federation and easy to deploy multiple PTA instances on-premises for scale and resiliency but does still require deployments
  • When users authenticate, their password is sent to Azure AD (encrypted via HTTPS and then sent via PTA for authentication)

Federation

  • Pro – 3rd party MFA, Azure MFA Server and custom policies/claim rules (outside of the Azure AD 3rd party MFA integration like Duo). It is also possible to create a multi-site ADFS farm, then coupled with some type of geo-DNS solution you can authenticate a user to their closest ADFS “presence
  • Pro – Certificate based authentication
  • Single-sign on if on AD joined machine in corp network. This can be matched with password hash and PTA with seamless-sign on enabled
  • Password never hits the cloud, it is send to federation server. Both others the password is sent to the cloud
  • INITIAL authentication hits federation servers for policy (but subsequent app requests won’t go via ADFS since will use refresh token gained)
  • INITIAL authentication against AD DS domain controllers
  • Con – Large amount of infrastructure required (proxy, adfs servers) especially when other federations moved to Azure AD. The OpEx cost is also a major consideration. Think about the maintenance (managing servers, trusts, certificates) and staff to operate this.
  • Con – With the ADFS proxy it means firewall exceptions to enable inbound traffic
  • Con – Can limit scale/availability

Note that for all scenarios I can still use features like Conditional Access. I try to start at the top of the options and work down if needed. I really consider the federation a legacy option that most organizations are moving away from since Azure AD would be used for the actual application federations moving forward.

Microsoft has a good doc at https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn which should also be reviewed.

Any thoughts, please post below!

Getting PowerShell 6

PowerShell 5.1 marks the last major update to PowerShell we are likely to see built into Windows. The future of PowerShell has gone the open-source path with PowerShell 6 being available via GitHub and available not just for Windows but also multiple Linux distributions and MacOSX. This is made possible as PowerShell 6, or rather PowerShell CORE 6.0 is built on .NET Core (which is cross platform) instead of the Windows exclusive .NET.

The good news is PowerShell 6 can be installed alongside the PowerShell that is part of Windows/WMF. Download and install from https://github.com/PowerShell/PowerShell/releases. Once installed you can launch by running pwsh.exe. If you look at $psversiontable you will see you have the Core PSEdition instead of the standard Desktop.

I recommend installing this and running alongside the regular PowerShell and getting used to it. The good news is most regular PowerShell will run and if you execute get-module -listavailable you will see the built-in modules. For non-built in modules you will need to check if they are supported with PowerShell Core.

Read the Microsoft article at https://blogs.msdn.microsoft.com/powershell/2018/01/10/powershell-core-6-0-generally-available-ga-and-supported/ for a great overview and walks through the key features that are not part of PowerShell Core 6, e.g. workflows in addition to key considerations.

Tools like Visual Studio Code can be used with PowerShell 5.1 and PowerShell Core 6.0. Simply change the settings for Visual Studio Code to add pwsh, e.g. add the following to user settings (File – Preferences – Settings) (change to your specific PowerShell version). I added this just under the existing User Setting (the , goes after the existing line in the file).


Happy PowerShelling!

Understand precedence with PowerShell

There are many ways to create functionality in PowerShell including basic cmdlets, aliases and functions. When you use multiple combinations its important to understand the precedence. This is best understood by walking through a basic example.

Firstly just run:

get-process

This will result in processes being displayed as expected.

Now lets create a function called get-process that lists child items.

function get-process { Get-ChildItem }

Now if you run get-process it will show child items so the function trumps the built-in cmdlet.

Now let’s create an alias so get-process points to get-service.

New-Alias get-process -Value get-service

Run get-process and it shows services so an alias trumps a function (which trumps the native cmdlets).

Note, you can always force running the cmdlet by its full name.

microsoft.powershell.management\get-process

Once you’ve finished you can reverse by deleting one-at-a-time.

 

Email people via Office 365 from PowerShell when passwords about to expire

I have a demonstration environment where many users have accounts but they never logon to AD directly nor look at this demonstration email mailbox. They only use the environment via Azure AD where they logon at Azure AD via the replicated password hash. Because of this they don’t get password expiry notifications and continue to logon however if they try and access something that does hook into AD and not Azure AD the logon fails.

They wanted to be emailed of upcoming password expiry to their real-email. To accomplish this their real email was stored in extensionAttribute10. I didn’t use the proxyaddresses as this may have SIP information. This attribute could be easily set with:

I had a mailbox for a core process I use. Now that user has no other rights so I placed the password in the script but that’s not ideal at all. If this was Azure Automation I could have used a credential object, I could have at least made the password harder to read by creating an encrypted version of the password and then storing that in the file (but its still reversible, just slightly harder to glance at!), e.g.

However the account can’t do anything except email and access to the script location was highly restricted so I left it as text which was also easier to demonstrate below however in my environment I used the alternate approach above just to make it a little harder to get the password on glance :-). Replace this with your own email and password.

The script looks for any password expiring in less than 10 days and emails a simple message. Customize as you like! It has a basic HTML block with a placeholder (MESSAGEHOLDER) that is replaced by a custom string for the user.

Have fun!

Add group members to another tenant via Azure AD B2B and PowerShell

I needed to add members of a number of groups from one Azure AD tenant to a group in another Azure AD tenant that would then be given access to a resource. The goal was to not require the users added to have to redeem the invite which is common when adding a B2B user. To do this the first step was a user invited via B2B the normal way, that user redeemed the invite and in this case was then made a global admin (although another option would have been to enable guests to invite guests). The key point was this user had the ability to invite people via B2B and could enumerate users in the invited Azure AD instance which would mean invites would not have to be redeemed.

My first version of the script was very simply however I soon realized I would have to rerun the script to add new users and so I enhanced it to extract the current members of the group, convert to regular email format (since when invite to Azure AD the users have @ replaced with _ and is put in a string with various components separated by a #). The script therefore extracts the first part and converts the _ back to a @. Then looks for only for people who are not already members.

In the script below replace the group names, Azure AD names and IDs to meet your requirements.

 

 

Create AD sites through PowerShell

I recently needed to create an AD site for each MTC (an office), add the IP range assigned to that MTC (which was in a CSV file) and then associate the site with a site link for its region. This is so the Active Directory automatic site coverage feature will enable DCs to populate per-site DNS records for the MTCs ensuring authentication traffic uses the most optimal DC. The DCs are spread over four regional locations.

The CSV file simply had one or two second octet numbers for the /16 IP range associated with the MTC. The code therefore enumerates through each OU, checks to see if the MTC can be found in the CSV data for the IP ranges. Next if the site does not already exist it is created, added to its regional site link (based on the parent OU name and for NA if its East or West) and then the IP ranges for the MTC assigned.