Limiting Login Restrictions to Azure AD to Regions

I was running a cloud enablement workshop today for a customer to lay out the options of providing SaaS applications an Identity Provider for SAML2 or OATH2 authentication.  We went through the various options, AD FS, Azure AD, Passthrough and third party providers.

One of the questions that was asked was "Is it possible to limit the Azure AD Regions which a users password hash is synchronised to" - when using Azure AD Connect and Password Hash Synchronisation.

My immediate answer to that question was "No".

The Azure AD architecture has write instances and many "read only" instances in Data Centres all over the world.  It is designed so that any datacentre or country can be lost and identity information will remain available, hence all Azure AD data is in all Azure Datacentres around the globe.

For more information on Azure AD architecture, see the following articles which are good reads:

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-architecture

https://cloudblogs.microsoft.com/enterprisemobility/2014/09/02/azure-ad-under-the-hood-of-our-geo-redundant-highly-available-distributed-cloud-directory/

Whilst the user password hashes will be replicated to all Azure datacentres around the globe, it is possible to restrict which countries or regions can authenticate against Azure AD.

This is done through a feature called "Conditional Access" using Location conditions.  For example it is possible for a company to lock down their users in their Azure Tenancy so that only Australian (people connecting from an Australian IP address) can make authentication attempts against Azure AD.

For more information on this feature please read:

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition

PowerShell List Local Administrators on all servers

I needed to list all Local Administrators on all servers at a company as part of a report.

I could not find a good PowerShell script which queried the server to see if it was online, then send a WMI query to enumerate the Local Administrators.

Here is a copy of the script I put together

$serverlist = Get-Content C:\Users\clint-b\serverlist.txt

foreach ($server in $serverlist)

    {

    $ipAddress = $pingStatus.ProtocolAddress;

    # Ping the computer

    $pingStatus = Get-WmiObject -Class Win32_PingStatus -Filter "Address = '$server'";

    if($pingStatus.StatusCode -eq 0)

        {

        Write-Host -ForegroundColor Green "Ping Reply received from $server.";

        $server | Out-File -NoClobber -Append C:\Users\clint-b\localadmins.txt

        $admins = Gwmi win32_groupuser –computer $server

        $admins = $admins |? {$_.groupcomponent –like '*"Administrators"'}

        $admins |? {$_.groupcomponent –like '*"Administrators"'} | fl *PartComponent* | Out-File -NoClobber -Append C:\Users\clint-b\localadmins.txt

        }

    else

    {

    Write-Host -ForegroundColor Red "No Ping Reply received from $server.";

    }

    }

In order to use this script you will need to put together a text file which has all the servers/workstations you want to query.  I used DSQUERY to make this text file but you can use numerous tools.

The text file must have the hostname of each member server on a separate line like:

SERVER1
SERVER2
SERVER3

Under the Out-File section, specify the location of where you want the data to be stored.

Forcefully Reseeding an Exchange Server on Exchange 2010

One of our customers had an Exchange 2010 DAG with databases on two servers.  One of the databases could not be mounted.  Before calling us, the customer removed one of the servers as a database copy.  So we only had one server with one copy of the Mailbox Database.

We attempted to re-add the other server as a DAG Member after the customer removed it with the following command:

Add-MailboxDatabaseCopy -Identity "MAILBOXDATABASE" -MailboxServer "EXHANGESERVER"

The DB was created, however the seed fails.  This can be caused by real-time anti-virus on Exchange servers without the appropriate exclusions in place or a corrupt transaction log / or inconsistent transaction log checkpoint file.

To fix this we forced the seed using the following procedure:

1. We dismounted the active database.
2. We suspended the passive copy (if active)
3. We deleted the EDB and Log Files from the Passive Server.  (You can move these to a different location as an alternative).
4. We checked the Active Server was in a clean shutdown state - see https://clintboessen.blogspot.com/2010/09/flush-transaction-logs-in-exchange.html
5. Once we know the Active Server database was in a clean shutdown, we cleared all transaction logs only from the production server by moving the logs to a temp folder.
6. We then re-mounted the Active Server database.  This database needed a force mount (Mount-Database DatabaseName -Force)
7. Lastly we forcefully updated the passive server with the following command:

Update-MailboxDatabaseCopy -Identity "MAILBOXDATABASE\EXCHANGESERVER" -DeleteExistingFiles

The PowerShell window will show a progress bar of the reseed progress.

Hope this post has been helpful.

Troubleshooting Account Lockout's

I often get asked by customers for assistance with troubleshooting account lockout issues, where a user constantly gets locked out but IT doesn't know how they are getting locked out or what device they are being locked out from.

Diagnosing account lockout issues can be a difficult task as you need to look at the audit logs on the domain controller for which the user attempted the failed authentication request.  For companies without audit collection software (software which pulls audit logs from multiple servers in a central place) this can be a difficult task.  There are many enterprise auditing products on the market such as Snare, Splunk, Tripwire, ManageEngine or even Microsoft ACS which is part of System Centre Operations Manager.

For companies without an enterprise auditing product, Microsoft has made a simple tool called Account Lockout Status (LockoutStatus.exe) which is free which just looks at invalid password attempts.  This tool queries the audit logs on all domain controllers.  This tool can be downloaded from the following location:

https://www.microsoft.com/en-gb/download/details.aspx?id=15201

If we look on Bentley-DC Security Logs we can see the unsuccessful login occurred from AT-LT-03.

Hope this post has been helpful.