fixing cisco umbrella AD connector issues

Some AD connectors were in a state of error

The customer had not actioned the API key and AD username updates.

Step 1 - Fix the API key as per cisco's instructions

Make sure to save your secrets in a pw fault

https://www.cisco.com/c/en/us/support/docs/security/umbrella/225982-configure-and-verify-new-authentication.html

Step 2 - Confirm password for opendns_connector user, now cisco_connector

Testing pw cmd:

• runas /netonly /user:OpenDNS_Connector@domain.int notepad.exe

Testing pw powershell:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement

$ctx = New-Object System.DirectoryServices.AccountManagement.PrincipalContext('Domain','domain.int')

$ctx.ValidateCredentials('OpenDNS_Connector', (Read-Host 'Password'))

Update the username in AD to Cisco_Connector

Reset the password if needed

Step 3 - Download latest connector installer and script from umbrella dashboard 

Step 4 - Uninstall connector, run script, re-install connector

Uninstall old connector

Run AD script 

Install connector, choose AD

Enter the Cisco_Connector password we updated above

Step 5 - Check logs and wait for cloud sync (15 min)

Check logs in

C:\Program Files (x86)\Cisco\CiscoADConnector\v1.x.x

CiscoAuditClient

2026-10-02 10:34:01.522: Bearer token request Successful

2026-10-02 10:34:01.522: GetBearerToken() Success: 200

CiscoAuditClient.error

Check for errors

Hard refresh the umbrella dashboard ctrl + F5.

If sync issues are not resolve gather logs and raise case with cisco TAC

palo alto updates quirk

Sometimes to get the updates to load 

Go to

dynamic updates

check now

software untick all boxes

check now

now look for version eg 11.2.10

click download

If its still not showing check firewall rules allow management IP's to access paloalto updates

investigate failover on palo alto firewall

 Log into both firewalls

In the Dashboard > High Availability widget, you may notice the primary has change from active to passive.

On both firewalls go to 

• Monitor > System
• Filter the log 
• subtype eq ha

You should see a reason for the failover. 

Often the link monitors fail (internet connection issue). You can check them here

• Device > High Availability > Link and Path Monitoring 
• Link group will show the interfaces that need to be up (Layer 2)
• Path group will show the IP's the firewall will try to ping to confirm link is up (Layer 3)

 Have seen the auto updates trigger failovers as well

palo alto nat across S2S VPN to reach mgmt interface

Customer had 192.168.x.x network overlapping

I needed to reach 192.168.0.82

I decided to NAT on customer side.

I sent traffic to 172.17.19.0 (This was in the VPN proxy ID)

172.17.19.0 (cust side) <> 172.16.100.0 (my side)

Now for NAT

Source Zone: VPN-ZONE (don't forget tunnel interface setup)

Destination zone: LAN

Source add: 172.16.100.0

Destination add: 172.17.19.0

Translated packet

Destination address translation

Translation type: Static IP

Translated address: N-192.168.0.0-24

Also note that mgmt interface IP config is not sync'd so you will need to get your IP's allowed under 

device > setup > interfaces > management > permitted IP addresses 

switch meraki mx to new internet connection

*** Important 

Cisco messed up the local status page passwords. Autogenerated pws but they weren't stored by cisco or given to customers.

Step 1 - Make sure local status page is enabled and pw reset

• Network wide > configure > general 
• Scroll down to Device configuration
• Make sure "local device status page enabled" is selected in the drop down
• Change password, enter a 14 char pw with numbers/upper and lower case and symbol
• Click update
• Allow time for cloud to sync

Step 2 - Test local status page before switching

• Before switching anything 
• Plug laptop into a meraki LAN port (check the port is on right vlan)
• Visit the local status page for MX it should be http://wired.meraki.com
• One customer said it only worked in edge but not chrome 
• test login works

Step 3 - Switch over to new interconnection and reconfig

• Switch over to new internet connection
• Plug WAN port into the new ISP
• Log into local status page. 
• Config the new settings and save
• Give it a few minutes to connect to cloud (check LEDs)
• It should come online and appear in cloud
• You may also change the cloud config to match 

Meraki status pages

MR - http://ap.meraki.com

MS - http://switch.meraki.com 

MX - http://mx.meraki.com or http://wired.meraki.com

MG - http://mg.meraki.com

Any - http://setup.meraki.com or http://my.meraki.com

FYI - Cisco reset local status page passwords, it used to be admin and the serial of the device but in 2025 cisco auto generated one and asked users to set a password.

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page

policy based routing (PBR)

I was working on an issue with something not working related to PBR.

A good rule of thumb is do the PBR's on outbound traffic. Next the next hop IP to outside gateway or LAN switch

Let NAT's handle inbound traffic

Outbound

LAN1 > LAN2

LAN1 > Outside > NAT > Internet

Inbound

Internet traffic > Outside > NAT > LAN1

cisco duo authproxy using ldaps cert expired

The DC certs were renewed. The CA that signed them had also been renewed. The ssl_ca_certs_file in authproxy.cfg was now pointing to an old/incorrect CA certificate that no longer matched. This caused the SSL verification to fail and preventing users from logging in.

From the authproxy server. Run this power shell. You'lls need to update the name of DC1.domain.local to match your DC

$tcpClient = New-Object System.Net.Sockets.TcpClient("DC1.domain.local", 636)

$sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream(), $false, {$true})

$sslStream.AuthenticateAsClient("DC1.domain.local")

$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain

$chain.Build($sslStream.RemoteCertificate)

$chain.ChainElements | ForEach-Object {

    $c = $_.Certificate

    Write-Host "Subject: $($c.Subject)"

    Write-Host "Thumbprint: $($c.Thumbprint)"

    Write-Host "---"

}

This should let us know the new thumbprint

Now we can use it to export the certs we need 

$tcpClient = New-Object System.Net.Sockets.TcpClient("DC1.domain.local", 636)

$sslStream = New-Object System.Net.Security.SslStream($tcpClient.GetStream(), $false, {$true})

$sslStream.AuthenticateAsClient("DC1.domain.local")

$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain

$chain.Build($sslStream.RemoteCertificate)

$caCert = $chain.ChainElements | Where-Object { $_.Certificate.Thumbprint -eq "NEW-CA-THUMBPRINT-HERE" } | Select-Object -First 1

$bytes = $caCert.Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)

$b64 = [System.Convert]::ToBase64String($bytes, [System.Base64FormattingOptions]::InsertLineBreaks)

$pem = "-----BEGIN CERTIFICATE-----`n$b64`n-----END CERTIFICATE-----"

[System.IO.File]::WriteAllText("C:\certs\DC-CA-new.cer", $pem)

Write-Host "Done - saved to C:\certs\DC-CA-new.cer"

Update authproxy.cfg file

under [ad_client] section

ssl_ca_certs_file=C:\certs\DC-CA-new.cer

Stop/start the authproxy service

net stop DuoAuthProxy && net start DuoAuthProxy

run connection tool again all should be fixed:
C:\Program Files\Duo Security Authentication Proxy\bin> .\authproxy_connectivity_tool.exe