AD Security Event 4776

[paul]

I am seeing what is described here:

https://social.technet.microsoft.com/Forums/en-US/d2869c14-a0e8-4084-b555-6172cd9c703a/cisco-ise-and-ad-authentication?forum=winserverDS 

The poster describes forcing ISE to use Kerberos instead of MS-RPC.  I don't see any setting like that in ISE.  I know when I do a  Test User against AD I can simulate this exact issue.  When I use MS-RPC I get the duplicate 4776 logs on the domain controller (failure followed by a success).  If I changed to Kerberos life is good.  Just not sure how to force ISE to use Kerberos for 802.1x auth.

[Colby LeMaire]

There is an option in ISE under External Identity Sources->Active Directory-><Your Domain>->"Advanced Authentication Settings" called "Use Kerberos for Plain Text Authentication".  I think that may force ISE to use Kerberos instead of MS-RPC.  If that doesn't work, then you can block TCP/UDP/135 at a firewall and ensure that TCP/88 is open.

[paul]

Yeah we aren’t doing plain text authentication. I saw that setting as.well.

[marco.merlo]

I saw the same issue while migrating fron ACS to ISE 2.3 LWA authentication.

Since PAP authentication was involved I got rid of the duplicated events switching from RPC to kerberos for plain text protocols.

This was against cisco recommendation bus our AD forest is quite simple so I took the risk.

Now we are migrating wired and wireless dot1x to ISE as well and the issue is present again because of peap ms-chapv2, this is a not plain text protocol so I am afraid that user can be authenticated just with NTLM over RPC because ISE migth not be able to know user password and do "kerberos proxy".

The good news is that at the end Cisco admitted that

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf45991/?rfs=iqvred

is not a microsoft only issue.

It seems that patch 10 for ISE 2.4 fixed it.

We are going to install patch 11 finger crossing

Regards

MM

[marco.merlo]

Hi patch 11 did not solve the issue.

MM

[hslai]

To use the fix, we need configure a registry key in AD Advanced Tuning page in ISE:

Registry Key:
REGISTRY.Services\lsass\Parameters\Providers\ActiveDirectory\WorkaroundForFalseFailedLoginEvent

By default the registry key is set to NO.

Set it to YES to use the fix.

[marco.merlo]

Great.
The advanced tuneing page reports
"This page should only be used under instruction from Cisco Support. Parameter values can be adjusted to tune the Active Directory Connection"
Should I ask TAC for support?
Regards
MM

[hslai]

Sure, if you like.

Please keep in mind that the two failure audit log entries is due to DC trying its local DB first before reaching out to the real AD. This happens because ISE uses UPN.

The fix with the registry key is to use sAMAccountName with a non-empty domain name. This may potentially cause ambiguity, as it's not as unique as UPN.

Thus, my recommendation is not to use it unless sAMAccountName is real unique in your deployment(s).

[marco.merlo]

Thank you very much.

Actually on our ActiveDirectory sAMAccountName  are unique even between trusted domains, anyway  we have just one kerberos realm per domain. So if with this configuration ise sends sAMAccountName  along with NTB domain name, it should work.

Do you think the patch might  rise some issue in trusted domain searches given that there are not duplicated sAMAccountName between trusted domain?

I asked our TAM to reach for ISE BU and ask them to write down some official documentation about this patch.

I saw that the configuration makes AD connector to restart with less then a minute traffic disruption but TAC is not able to confirm because of lack of documentation

Regards

MM