KB ID 0001638

Problem

I’ve seen this a few times now, I’ve had users that will not sync from Active Directory to Azure Active Directory (Office 365). When you look to see why, you will see something like;

The Connector {Your-Domain}.onmicrosoft.com – AAD contains another object with the same DN which is already connected to the MV.

Note: For the uninitiated, DN is Distinguished Name, and MV is MetaVerse.

If you attempt to troubleshoot the sync, you may also see something like this;

Object {Distinguished-Name} is not found in AAD Connector Space.

Solution

First we need to temporarily halt the sync;

Set-ADSyncScheduler -SyncCycleEnabled $False

Then launch Sycronization Service Manager > Connectors > Select your AAD Connector > Delete > Delete connector space only > Yes.

Note: Whoa! it says I’m going to lose data, what are we doing? 

Well we are essentially removing all the ‘cached objects associated with this connector, I think about it like ‘flushing the cache’. I’ve never seen this operation break anything, and I’ve certainly never ‘lost’ anything.

While it’s still running, do the same with your local AD connector.

Start the sync scheduler again.

Set-ADSyncScheduler -SyncCycleEnabled $True

Perform a Full Import on your AAD connector..

With the above still running you can repeat a Full Import on your AD Connector 

Providing the full import has finished (i.e the connector says ‘idle’) perform an Export on the AAD Connector.

Providing the full import has finished (i.e, the connector says ‘idle’) perform an Export on the Local AD Connector.

You can then force an AAD sync, and go have a coffee.

Related Articles, References, Credits, or External Links

Azure AD Connect: Correct Or Remove Duplicate Values

KB ID 0001639

Problem

You will see this error if you are migrating a Certificate Services Server from Server 2008, (NOT Server 2008 R2) to Windows Server 2016, (or newer).

Version of log file is not compatible with the Jet version 0xc8000202 (ESE: 514 Jet_errBadLogVersion)

You will also see the following events logged;

Event ID 17

Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Date: xx/xx/xxxx xx:xx:xx
Event ID: 17
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: 2019-CA.migrate.com
Description:
Active Directory Certificate Services did not start: Unable to initialize the database connection for MIGRATE-CA. Version of log file is not compatible with Jet version 0xc8000202 (ESE: -514 JET_errBadLogVersion).

Event ID 454

Log Name: Application
Source: ESENT
Date: 1xx/xx/xxxx xx:xx:xx
Event ID: 454
Task Category: Logging/Recovery
Level: Error
Keywords: Classic
User: N/A
Computer: 2019-CA.migrate.com
Description:
certsrv.exe (1268,P,98) Restore0001: Database recovery/restore failed with unexpected error -514.

Event ID 640

Log Name: Application
Source: ESENT
Date: xx/xx/xxxx xx:xx:xx
Event ID: 640
Task Category: General
Level: Warning
Keywords: Classic
User: N/A
Computer: 2019-CA.migrate.com
Description:
certsrv.exe (1268,P,98) Restore0001: Error -1919 validating header page on flush map file “C:\Windows\system32\CertLog\{CA-Name}.jfm”. The flush map file will be invalidated.
Additional information: [SignDbHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer:] [SignFmHdrFromDb:Create time:00/00/1900 00:00:00.000 Rand:0 Computer:] [SignDbHdrFromFm:Create time:01/17/2020 22:30:48.514 Rand:248810345 Computer:] [SignFmHdrFromFm:Create time:01/17/2020 22:30:48.529 Rand:4091580707 Computer:]

Solution

OK, if you followed a good CA migration guide like mine here, then you already have a copy of the the Database, CA certs, Private keys, and Registry settings. So you are good, don’t panic.

This has happened because the source Jet Database that Certificate Services used on the old 2008 Server, (Note: not 2008 R2) is simply too old to be upgraded straight to the one on Server 2016 or newer.

You need to spin up a 2012 R2 server, migrate Certificate Services, onto that, then migrate to Server 2016 (or 2019) from there.

Related Articles, References, Credits, or External Links

NA

KB ID 0001183 

Problem

Colleague: Windows Server, Where’s Windows Security gone?

Me: Eh?

Colleague: Windows Security!

Me: What are you trying to do?

Colleague: I want to change my password and I can’t send a Ctrl+Alt+Delete to the remote server.

Well I know that pressing Crtl+Alt+Delete would let you change you password like so;

I wasn’t aware that in Server 2008 and earlier if you were connected via RDP you got a ‘Windows Security’ option that let you do the same, like so;

This is because if you press Ctrl+Alt+Delete it will execute on YOUR machine not the remote one. But this option is not included in Windows 2012 any more.

Solution

Well you can just normally use Ctrl+Alt+END while in an RDP session. But like me, my colleague was using a Mac and we don’t have an END key!

Mac OSX Sent a Ctrl+Alt+END Sequence

If you’re RDP connected from OSX then use Ctrl+Alt+Fn+Backspace

If you’re RDP connected using a Mac Keyboard, or from a VM session on your Mac (i.e. from a VMware Fusion Windows Machine), then use Ctrl+Alt+Fn+Right-Arrow.

Other Solution

From within the RDP session, launch the on-screen keyboard, (Start > Run > osk). Then Press Ctrl+Alt on your physical keyboard, and click the delete key on the on-screen keyboard with your mouse cursor like so;

BETTER Solution

Within the RDP session open powershell and rung the following command;

(New-Object -COM Shell.Application).WindowsSecurity()

Or use the following VB shortcut.

Set objShell = CreateObject("Shell.Application")
objShell.WindowsSecurity

Scalable Solution (Create Password Reset Shortcut)

Create a shortcut for;

explorer.exe shell:::{2559a1f2-21d7-11d4-bdaf-00c04f60b9f0}

Note: If you have a bunch of  RDP servers you wanted to roll this out to, you can set it up on your administrative account, capture your start menu to an XML file, and then distribute that start menu to all your users via group policy, (not available with server 2012 or earlier).

Related Articles, References, Credits, or External Links

NA

KB ID 0001640

Problem

I recently migrated the server that was running my Azure AD Connector. It was showing no errors post migration so I thought no more about it. A few days later I logged in to Office 365 and saw this;

AAD Connect Status
Azure AD Connect
Password sync: no recent synchronization

Solution

Apparently this can suddenly happen if you are running an old version of AAD Connect. But I checked and mine was brand new, (I’d only just installed it remember). A quick look in the Event Viewer pointed me in the right direction.

Event ID 611

Log Name: Application
Source: Directory Synchronization
Date: xx/xx/xxxx xx:xx:xx
Event ID: 611
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: {server-name}
Description:
Password hash synchronization failed for domain: pnl.com, domain controller hostname: PNL-MGMT.pnl.com, domain controller IP address: 192.168.100.3. Details:
Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error 8453 : Replication access was denied. There was an error calling _IDL_DRSGetNCChanges.

I’ve highlighted the important part, RPC Error 8453: Replication access was denied. So we have a permissions/rights problem. As I’d set a new user up for the AAD connector software, I checked their rights and found out I was missing the following;

Ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.

• Replicating Directory Changes: Allow
• Replicating Directory Changes All: Allow

Then I forced an AAD sync, and waited a few minutes, the problem then disappeared.

Related Articles, References, Credits, or External Links

NA

KB ID 0001641

Problem

So now theres a version of Microsoft Edge for macOS! Normally I would not bother, but I spend a lot of time in SharePoint and Azure so I thought, rather than my usual approach of playing ‘Browser Roulette’ I’d try Microsoft Edge and see what it was like.

My usual browser of choice is Safari, but the install wizard defaults to wanting to import bookmarks / favourites* from Chrome. (I do also have Chrome, but I don’t use it often!)

*Note: Wow! Microsoft have spelled Favourites correctly for once!

So how to get my Safari Bookmarks?

Solution

Firstly Edge needs full disk access to get the bookmarks > Apple Logo > System Preferences > Security & Privacy > Privacy > Full Disk Access > ‘UNLOCK’ > Tick Microsoft edge.

Launch Edge > {ellipses} > Settings > Import Browser Data > Select ‘Safari’ > Import.

So now they are there, but they look like a ‘bag of spanners’ all my neat folders have been moved into another folder called ‘Imported from Safari”.

From ‘Mange Favourites’, you can drag everything to where you want it.

Related Articles, References, Credits, or External Links

NA

KB ID 0001642

Problem

I’ve never really taken the time to look at pass-through authentication, I set up Azure AAD sync, then I either use ADFS or I don’t. It was only when looking at removing ADFS, that I even looked at it as an option. 

How does Pass-through Authentication Work?

1. Remote client attempts to authenticate to Office 365 (Azure Active Directory).
2. Azure queues the request and sends it to an Azure Authentication Agent (on-prem), of which there may be many. Note: The requests will load balance.
3. The Azure Authentication Agents check the authentication request against the load Active Directory.
4. The Azure Authentication Agents sends its response back to Azure Active Directory.
5. The client is authenticated (or denied!)

Why is that Good?

Well you don’t need to deploy ADFS, or WAP. The agent only needs https (outbound) on the firewall Note: If you have a proxy server, theres some URL’s you need to allow. And you don’t need to wait for the default 30 minute AAD replication cycle for changes etc.

Solution

I’m assuming you already have Azure AD sync setup and running, (Simply accept ‘Express settings’ and accept all the defaults), once you have your  local AD replicated to Azure, then you can switch over to pass-through authentication.

Open Azure AS Sync > Configure > Change user sign-in > Proceed to ‘User sign-in’ >pass-through authentication > Finish the wizard.

What happens is the ‘first’ Azure Authentication Agent is installed on the Azure AAD server > Force an AAD Sync > Then look in your Azure Portal > Azure Active Directory > Azure Ad Connect > Pass-through authentication > You should see your first agent.

You can select it and check its details. Note: You can download the Azure Authentication Agent software form this page for you to deploy additional Azure Authentication Agents.

The additional agents are simple to deploy, they will require you to authenticate to Azure though.

They will appear one at a time as deployed.

Related Articles, References, Credits, or External Links

NA

KB ID 0001643

Problem

Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.

Convert-MsolDomainToStandard -DomainName {Federated-Domain-Name} -SkipUserConversion $false -PasswordFile c:\password.txt

BUT YOU DON’T NEED TO DO THAT!

I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?“

So I built it on the test bench, and did it myself.

Solution

To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.

First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.

Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.

WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.

Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.

OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;

Azure Pass-through Authentication

Because we are enabling single sign-on, you will be prompted for a set of local domain admin credentials > Complete the wizard.

Then force a Delta Azure AD Replication.

Related Articles, References, Credits, or External Links

NA

KB ID 0001644

Problem

While setting up some new backups, all the virtual machine failed like so;

Unable to allocate processing resources. Error: No backup proxy is able to process this VM due to proxy processing mode restrictions.

Solution

On the face of it this looks like a simple problem, either you backup proxy does not have the capacity, you have too many jobs running at one, or you need to deploy some more backup proxies.

However, I tested this by creating a new job with one ‘problem’ VM in it and made sure no other jobs were running. It failed with the same error. So it’s got nothing to do with lack of resources!

The Actual Problem: Was due to the fact that the backup proxy (a physical machine) had direct fiber access to the storage array, and its backup mode was set to ‘Direct Storage Access’. These new VMs were in a different Datastore/LUN that the Veeam server could not see! So you can either tick ‘Failover to network mode if primary mode fails or is unavailable’

Or a better option would be to present the correct storage LUNS to the Veeam Backup server.

Related Articles, References, Credits, or External Links

NA

KB ID 0001645

Problem

I have written about Enabling LDAPS a long time ago, but it’s a subject that’s about to become important again, so I’ll revisit the subject. Microsoft are about to ‘enforce’ LDAPS authentication against their domain controllers, in the March 2020 round of updates. 

What does that mean? Well lookups against LDAP will now need to be secure, (i.e. SSL protected and over TCP port 636,) where as before they were in plain text and over TCP port 389.

So you need to start worrying about this now!

Solution

Enable LDAPS for you Domain Controllers

As I’ve mentioned above I’ve covered this before but as a quick recap, you need to have Microsoft Certificate services deployed, please don’t just add the role to a server, and click ‘Next’ furiously. Take this opportunity to deploy Certificate Services properly!

Microsoft PKI Planning and Deploying Certificate Services

Then make sure you have a Kerberos Authentication certificate template published;

If you do not: Simply follow the steps shown below.

Then on you domain controller(s): Windows Key +R > mmc.exe > OK > File > Add/Remove Snap-in > Certificates > Add > Computer > Local Computer.

Expand Certificates > Personal > Certificates > Request a Kerberos Authentication certificate.

Ta-Da!

Windows Server Testing LDAPS

The simplest way, I’ve found to do this is to use Ldp.exe, simply run Ldp from command line. Note: Ldp will normally only be found on domain controllers, and servers/clients that have the ‘AD and DS and AD LDS Management tools‘ installed.

Connection > Connect > Enter the FQDN of the domain controller to test > Tick SSL > Ensure Port is set to 636 > OK

Connections > Bind > Bind as currently logged on user, (unless you want to test a particular account), any member of domain users should work > OK.

View > Tree > Select the root DN of your domain > OK

If all is well you should be able to browse your Active Directory.

Tech Tip: I do this every time I need to enter a DN, because you can browse to any object and copy its DN from here, (and I’m too lazy to type them out by hand!)

Test LDAPS Port With PowerShell

If you want to check the port is open, i.e. not blocked in the Windows firewall or a physical firewall in between you and the server use;

Test-NetConnection {FQDN-Of-Server} -Port 636

Additional LDAP Test Tools

Over on Github theres also a tool called LDAP Explorer Tool, if you want to do some more granular testing;

Find Out What’s Using LDAP and Prepare for LDAPS

If you don’t enforce LDAPS already then your Directory Service Event logs will be full of Event ID 2886, and Event ID 2887

Event ID 2886

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: xx/xx/xxxx xx:xx:xx
Event ID: 2886
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: (Server-Name}
Description:
The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.

Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure the server to reject such binds.

For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.

You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the “LDAP Interface Events” event logging category to level 2 or higher.

Event ID 2887

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: xx/xx/xxxx xx:xx:xx
Event ID: 2887
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: (Server-Name}
Description:

During the previous 24 hour period, some clients attempted to perform LDAP binds that were either:
(1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or
(2) A LDAP simple bind that was performed on a clear text (non-SSL/TLS-encrypted) connection

This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.

Summary information on the number of these binds received within the past 24 hours is below.

You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the “LDAP Interface Events” event logging category to level 2 or higher.

Number of simple binds performed without SSL/TLS: 0
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 1

Enable LDAPS Logging / Reporting

So you need to enable logging then when insecure (non LDAPS) connections are made, another Event ID will be logged which will point you towards what needs to be fixed. 

Open Regedit and navigate to;

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Change the ’16 LDAP Interface Events’ DWAORD value to ‘2’ > OK.

Or Execute the following command;

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2

Or Execute the following Powershell command;

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics’ -Name “16 LDAP Interface Events” -Value 2 -PropertyType DWORD -Force

Checking for Insecure LDAP (TCP 389) Connections

Now you can locate the insecure connections by looking for Event ID 2889

Event ID 2889

Above you can see the IP address of the device trying to bind insecurely, you can also see that Anonymous Login was attempted’.

Above you can see the IP address of the device trying to bind insecurely, you can also see the domain username that is being used ‘PNL\asa’.

Disable LDAPS (Temporarily)

LDAPS is enabled and disabled with the following registry key;

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding

Note: You will need to CREATE this DWORD yourself;

Values: 0 Disabled, and 1 Enabled

WARNING: Take note I said temporarily, just because you have a crappy old insecure appliance or service that can’t use LDAPS, does not mean you should simply turn off security. Get it fixed! However, I appreciate you work in the real world, and if systems are down and you are getting shouted at, then fair enough. But you should have read this when I wrote in January 2020 my friend – bet you wished you followed me on Twitter or Facebook now eh?

Cisco ASA Change from LDAP to LDAPS

Well I’m the Cisco ASA guy so what happens if you are securing AAA access using LDAP on you firewall (for AnyConnect, Remote VPN, or device access). How do you swap to LDAPS? Like so

You will also need to upload the Root-CA certificate from your CA Services Server to the ASA, (so it trusts the servers Kerberos Certificate).

Related Articles, References, Credits, or External Links

Moving Certificate Services To Another Server

Microsoft PKI Planning and Deploying Certificate Services

Upgrade Your Microsoft PKI Environment to SHA2 (SHA256)

KB ID 0001118 

Problem

One annoying thing about the vSphere web client is the fact it throws you out after a period of inactivity. Now I know there are straight forward security reasons for this, and on a production environment thats fine. But on my test network theres just me, sighing every few minutes and logging back in again.

As the ‘Flash’ client is getting depreciated I’ll concentrate on the HTML5 client, but I’ll mention how to alter the flash client also.

Solution

vCenter Appliance (VCSA) Web Client Inactivity Timeout

Connect directly to the console or via SSH. to launch a BASH type ‘shell’, then execute the following commands

cd /etc/vmware/
ls

You will see a folder for vsphere-ui (the HTML5 client) and vsphere-client (the legacy Flash client)

Change directory to the client you want to alter the settings for, then edit the web client-properties file.

cd vsphere-ui
vi web client-properties

Locate the ‘session.timeout = 120′ value and change it to zero ‘0’ to disable, (or a new figure in minutes).

Note: Navigate with the arrow keys  > press ‘I’ to insert >  change the text  > press ‘Esc’ >  type ‘:wq’ to save and exit.

Then restart the HTML5 client with the following commands’

service-control --stop vsphere-ui
service-control --start vsphere-ui

vCenter on Windows Web Client Inactivity Timeout

First you need to edit the config file for the web client > Windows Key + R > “%ALLUSERSPROFILE%\VMware\vSphere Web Client”

Locate the session.timeout value and change it to 0 (zero)  > Save and exit the file.

Finally restart the service. Windows Key +R > services.msc > Locate and restart the VMware vSphere Web Client service.

Related Articles, References, Credits, or External Links

NA

KB ID 0001646

Problem

While attempting to connect to a clients AnyConnect, this happened;

The VPN client was unable to successfully verify the IP forwarding table modifications. A VPN connection will not be established.

Or on older clients, you may see;

The VPN client was unable to modify the IP forwarding table. A VPN connection will not be established. Please restart your computer or device, then try again.

Solution

I was trying to connect from my house, I’d used this connection before from work and it was fine. I worked my way round the problem got my work finished, then re-looked at it the next time I was working from home.

The problem is actually quite simple, take a look at the IP I was using in my house.

Then take a look at the VPN Pool addresses that get allocated to the remote VPN clients (they overlap);

show run | incl pool

Note: This assumes you are using an ‘IP Pool’, If you are using an external DHCP server at the ‘Head end’ then you will need to check/change the scope there.

AnyConnect – Using a Windows DHCP Server to Lease IP Addresses to the Remote Clients

I fixed the problem by simply changing the ‘pool’ so it didn’t overlap.

WARNING: If you have any routing going on behind your firewall (i.e you have layer 3 switches internally, routing between networks or VLANS) you may need to change them to route the ‘new’ AnyConnect subnet back to the firewall.

Related Articles, References, Credits, or External Links

NA

KB ID 0001647

Problem

With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.

Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.

Solution

Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;

Get Ready for LDAPS Channel Binding

In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.

Duo Existing LDAP AD Sync

It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!

So your domain controller(s) will be using TCP port 389.

Your transport type will be set to ‘Clear’.

Duo Deploy LDAPS for ADSync

The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;

YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!

Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;

Rights and Permissions for Duo Service Account

Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.

All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.

Add in the Duo service account, and grant;

• List contents
• Read all properties
• Read properties

Note: They will probably, already be selected.

Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).

You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.

Change Duo ADSync to LDAPS

To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)

Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will nee to paste it into the Duo Admin Panel in a minute.

In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)

Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.

Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.

All being well it should say connected.

Troubleshooting Duo LDAPS

Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging, or use the connectivity tool.

Related Articles, References, Credits, or External Links

NA

KB ID 0001648

Problem

Before you can use Duo 2FA/MFA you need to have your users enrolled. Theres a number of ways to enrol them, you can bulk email them, or manually add them. Below I’m going to Sync Duo with my Active Directory, so that if users are members of a specific AD group, they will ‘appear’ in the Duo Admin Portal. Then I’m going to enter a users mobile phone number and send them an SMS to enrol.

Tip: When setting up your Duo Account, I’d recommend creating as new user, just for Duo admin, you can use your own account, but it means enrolling twice.

Duo: Setup ADSync

Log into the Duo Admin Portal > Users > Directory Sync > Active Directory > Add New Active Directory Sync > Take note of the Integration Key, Secret Key, and the API hostname (copy them to a text file). Add your domain controllers (internal IP address(s) and set the port to 636 (LDAPS). Scroll down.

Set the ‘Base DN’ of your domain, here I’m simply using the root of the domain, you can set to to a specific OU of you prefer. Scroll down.

Select LDAPS > Paste in the PEM certificate file of your CA Server certificate. Save Directory.

Note: If you don’t know what a PEM file is, read this post.

On a member server in your domain, install the Duo Security Authentication Proxy software. (Note: This server needs TCP port 443 (HTTPS) outbound permitted on your corporate firewall.

Navigate to C:\Program Files (x86) Duo Security Authentication Proxy/conf folder locate the authproxy.cfg file and open it with WORDPAD.

Delete the contents, and paste in the following, change the values in red to match you domain and put in the keys you coped to Notepad earlier;

[ad_client]
host=192.168.100.3
service_account_username=svc_duo
service_account_password=Password1
search_dn=dc=pnl,dc=com

[cloud]
ikey=XXXXXXXXXXXXXXXXXXXX
skey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
api_host=XXXXXXXXXXXXXXXXXXXXXXXXXXXX

Note: Where 192.168.100.3 is your domain controller, and svc_duo is the service account you created for the proxy service, and Password1 is the password for that account.

Then start the service with the following command;

net start DuoAuthProxy

Note: If your service wont start, you may need to grant your ‘service user’ some additional rights, see this post for further information.

Back in the Duo Admin Portal your ADSync should now say ‘Connected’.

Now you can see your groups, select the group that contains the users you want to sync.

Note: DON’T USE ‘Domain Users’, it wont work, neither will creating a group and putting the domain users group within it. Add your users, if theres a lot, you can bulk add users to the group.

Duo: Enrol Users via SMS

Obviously you will need know the users mobile phone number, and they will need to have the Duo app installed, this can be done on Android/iPhone/iPAD from either the App Store or Google Play. (The app is free).

Select your user in the portal  > Add Phone > Enter the mobile number > Add Phone.

Activate Duo Mobile.

Generate Duo Mobile Activation Code.

Send instructions by SMS.

On the users phone, they will see something like this, they need to click the link.

This is what it should look like when successful, (Note: The reason I have TWO entries is because I’m also the Duo Admin for this site).

Related Articles, References, Credits, or External Links

NA

KB ID 0001649

Problem

I’m doing some work for a client that has Azure AD Sync running, and we keep kicking each other off the server, so I thought I’d login with another account. However, when I tried to open the Synchronisation Service Manager;

Unable to connect to the Synchronisation Service

Some possible reasons are:
1) The service is not started.
2) Your account is not a member of the requires security group.

See the Synchronisation Service documentation for details.

Solution

Well it was the second option in my case. Open Server Manager > Tools > Computer Management > System tools > Local Users and groups > Groups > ADSyncAdmins > Add your user in here.

Related Articles, References, Credits, or External Links

NA

KB ID 0001650

Problem

I was asked if I’d ever set this up the other week. Surprisingly I had not, I’d deployed Duo for other things, but not for Cisco AnyConnect. As I had some other ‘Duo’ related tasks coming up, I was deploying it on the test bench, then adding in my Cisco ASA and AnyConnect wasn’t much more work!

Here’s my topology;

• My ASA is running version 9.1
• My Duo Authentication Proxy is installed on Windows 2019
• I’m running Cisco AnyConnect Version 4.8

Cisco AnyConnect Duo Pre-Requisites

I already have a Duo Authentication Proxy server setup and my users are enrolled, you will need to set this up first. See the following article;

Duo: ADSync and Enroll Users via SMS

Also I’m using LDAPS, if you have not set that up (it’s easy) then see the following article;

Get Ready for LDAPS Channel Binding

I would also setup AnyConnect and have it working with LOCAL authentication before migrating to Duo/2FA Authentication;

Cisco ASA 5500 AnyConnect Setup From Command Line

Duo: Deploy Cisco RADIUS VPN

Log into the the Duo Admin Portal > Applications > Protect an Application > Search for and select Cisco RADIUS VPN > Copy the Integration Key, Secret Key and the API hostname to notepad.

Back on your Duo Authentication Proxy, (because you completed the pre-requisites) add the following to the bottom of your authproxy.cfg file;

[radius_server_auto]
ikey=XXXXXXXXXXXXXXXXXXXX
skey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
api_host=XXXXXXXXXXXXXXXXXXXXXXXXXXXX
radius_ip_1=192.168.254.254
radius_secret_1=666999
client=ad_client
port=1812
failmode=safe

Note: 192.168.254.254 is the inside interface of the Cisco ASA, and 666999 is the shared secret we will enter on the firewall in a moment. I’m not sure you have to, but at this point I’d restart the Duo Auth Proxy service as well.

Configure Cisco ASA for Duo RADIUS

Log into the ASDM > Configuration > Device Management > Users/AAA > AAA Server Groups > Add.

You only need to add the name of the server group i.e DUO-RADIUS, and ensure protocol is set to RADIUS > OK > Apply.

Now select the DUO-RADIUS group in the top window, and click ‘Add’ in the bottom window > Specify the interface that’s facing the Duo Auth Proxy Server > Add its IP address > Change the Timeout to 60 seconds > Set the Server Authentication port to 1812 > Set the Server Accounting Port to 1813, (though it will NOT do accounting) > Type in the Secret Key you specified above > Untick Microsoft CHAPv2 Capable > OK.

Testing Cisco ASA Duo 2FA Authentication

I’ve written about testing AAA before in the following article;

Cisco – Testing AAA Authentication (Cisco ASA and IOS)

But essentially with the SERVER selected > Test > Select Authentication > Enter the username and password for a user.

What about passcodes and 2FA? This will send a push notification to the users Duo Authenticator (phone), you can enter the password then a comma, then the passcode from the Duo App if you wish, I just prefer the push notification).

Like so! Approve the request.

Authentication should be successful.

Change AnyConnect To Use Duo 2FA (AAA)

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Profile > Select yours > Edit.

I don’t have one! OK Create one and link to your AnyConnect Profile.

Preference (Part 2) > Scroll to the bottom > Change Authentication Timeout to 60 seconds > OK > Apply.

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles > Select the one used for your AnyConnect > Edit.

Change AAA Server Group to DUO-RADIUS > OK > Apply.

Give it a test, Don’t forget to save the changes when you are happy (File > Save Running To Flash.)

Related Articles, References, Credits, or External Links

NA

KB ID 0001651

Problem

I had a client machine struggling to get an DHCP address, and when I looked in DHCP the scope it was full of this;

BAD_ADDRESS This address Is Already in Use

Solution

A tour of Google and forums is full of posts by people with this problem, and other than, ‘Oh I looked in the logs and fixed it’ (with no mention of what log, or where this log was), or ‘Yeah I used Wireshark and located a problem client‘, then no follow up on what they did, or scanned for. So I pretty much had to slog through and work it out for myself. I’ll detail each step I took below, most of which didn’t help, or sent me in the wrong direction, but for you that may be a better solution.

And I will give you enough information to at least be helpful!

Firstly Common Sense Check: If this has just happened what have you changed? Have you added any Wireless Controllers, or Access Points? Have you deployed any new Switches or Firewalls. In my case, it was my test network so it could have been happening for months!

The most frequent cause of this error is simply because someone has setup another DHCP server on the network. That will be easy to diagnose, simply ‘Stop’ your DHCP Server;

Then on a DHCP client, issue an ifconfig /release and ifconfig /renew, If it gets an IP address, issue an ifconfig /all and look for the IP of the DHCP server it’s using, that’s your culprit. However as you can see, mine didn’t get an IP address so this wasn’t my problem.

The next most popular suggestion is to enable ‘Conflict Detection‘, though in most places the information on where to find this, is incorrect, (as it’s been copied and pasted around the forums without actually checking it!) See below, you locate it on the properties of the Protocol not the Server > Advanced Tab > You are supposed to set it between 1 and 6 so I went for 5, (but after deleting all the BAD_ADDRESS entries, they were all back after 30 minutes or so, so this didn’t work for me either).

Look in the logs: Well they were useless also, DHCP creates a new log every day in C:\Windows\System32\Dhcp called ‘DHCPSrvLog-DAY.log’ as you can see it was not helpful.

At this point I put my networking head on, and ‘thought outside the box’, If DHCP is detecting these as BAD ADDRESSES, then they must be in the arp cache on the DHCP server right? Well look at this;

arp -a

Well that’s encouraging, at least now I’ve got a suspect MAC address, lookup up that MAC address online, and it comes back as VMWare (which sent me off in the wrong direction, it was not a VMware virtual machine in my vSphere in the end). Ive got a decent Cisco Switch so I thought I’d see which interface it was connected to, (but it wasn’t there).

show mac address-table

At this point I was still thinking it was a VMware virtual machine, so I used PowerCLI (Thats PowerShell for VMware), to query for that MAC address, but that revealed nothing.

So, my last hope was Wireshark, I fired it up on the DHCP server, and set the filter to;

bootp.option.type == 53

Then I deleted all the BAD_ADDRESS entries, left Wireshark ‘sniffing’, and went for lunch. I returned to this (see below). Now 192,168,100,107 was one of the BAD_ADDRESS entries, and I did not know what it was. The other entries on there for 192.168.100.3 are understandable, (that’s my DHCP server!) So now I had a Layer 3 address to hunt.

When I RDP connected to it, I got prompted for a password, so now I know it’s a Windows box! I hunted all through my VMware virtual machines, it was not there. Just as an afterthought I remembered I have a Hyper-V server, could that be running a virtual machine? BOOM! There is is SCVMM server, I was using for some Zerto testing a couple of months ago! Turned it off, problem solved!

Hope you find your culprit quicker than I did!

Related Articles, References, Credits, or External Links

NA

KB ID 0001652

Problem

While trying to connect Outlook (2016) to an Office 365 email account;

We can’t connect you

It looks like we can’t connect you to one of our services the moment. Please try again later, or contact your helpdesk if the issue persists.

0xCAA70010

{ADFS-URL}

Solution

This was happening because my ADFS server was using a ‘self-signed’ certificate (i.e. not a purchased one). This should NEVER be done in a production environment, but this is my test network, (so I refuse to spend money on certificates for testing etc!)

I cured the problem by simply importing/trusting the CA Certificate from my internal Certificate Services CA server, (that issued the ADFS servers certificate).

If you see this on a production server, with a publicly signed certificate, check that the ‘problem’ client does not need a Windows Update, to update its trusted CA Certificates, or that your certificate simply hasn’t expired, and you ‘forgot’ to renew it. If so;

ADFS: Changing the Certificate

Related Articles, References, Credits, or External Links

NA

KB ID 0001653

Problem

On EE this morning someone asked how to map a drive to only two users, so that wherever they logged in, they got their mapped drive. Seemed like a good Idea for a post so here you go;

Solution

If you do not already have one, create a group for your users.

Add the users, (as appropriate).

On a Domain Controller > Administrative Groups > Locate the OU that contains your users (Note: if your users are in multiple OU’s, then after you have created the policy simply ‘Link‘ it to the applicable OUs).

Edit the policy.

User Configuration > Preferences > Windows Settings > Drive Maps > New  > Mapped Drive > Action = Create > Location = Set the UNC path to the mapped drive > Tick ‘reconnect’ > Label as ‘What you want the user to see it called’ > Select the drive letter you want > Apply > OK > Close the policy editor.

With the policy selected > Delegation. > Advanced > Authenticated Users > REMOVE ‘Apply Group Policy’.

Add. >Add in your ‘Security Group’.

ALLOW ‘Apply Group Policy’ > Apply > OK.

Then either wait, or force a group policy update.

To prove it’s not all ‘Smoke and Mirrors‘, I log on as one of those users and…

Related Articles, References, Credits, or External Links

NA

KB ID 0001654

Problem

Yesterday I wrote a post about Deploying a ‘Mapped’ Drive to a couple of users using Group Policy. This received a comment that was basically ‘Why not simply use Client Targeting?’ To be fair that’s a good point, I was using a Group Policy Preference and they can be specifically targeted. So here’s how to do that.

Solution

If you do not already have one, create a group for your users.

Add the users, (as appropriate).

On a Domain Controller > Administrative Groups > Locate the OU that contains your users (Note: if your users are in multiple OU’s, then after you have created the policy simply ‘Link‘ it to the applicable OUs).

Edit the policy.

User Configuration > Preferences > Windows Settings > Drive Maps > New  > Mapped Drive > Action = Create > Location = Set the UNC path to the mapped drive > Tick ‘reconnect’ > Label as ‘What you want the user to see it called’ > Select the drive letter you want.

Common tab > Select Item-level targeting  > Targeting > New Item.

Security Group. (Look at all the other cool stuff you can specify to target this group policy preference!)

Add in your security group > OK > OK > Apply > OK

Then either wait, or force a group policy update.

To prove it’s not all ‘Smoke and Mirrors‘, I log on as one of those users and…

Related Articles, References, Credits, or External Links

NA

KB ID 0001655

Problem

If you have something boring/repetitive to do then Powershell is your friend! I needed to do this for a client that’s replacing their Office365/Azure AD MFA (Multi Factor Authentication) with Duo.

Solution

Connect to your Microsoft Services Online, i.e. Office365/Azure, using your administrative credentials with the following command;

Connect-MsolService

Then (Note: I’ve got more than 1000 users so I need to add the MaxResults switch).

Get-MsolUser -MaxResults 2000 | Set-MsolUser -StrongAuthenticationRequirements @()

Office 365: Disable MFA For One User

Similar to above;

Get-MsolUser -UserPrincipleName {user-name} | Set-MsolUser -StrongAuthenticationRequirements @()

Related Articles, References, Credits, or External Links

NA