topic Re: AD Security Event 4776 in Network Access Control

AD Security Event 4776

paul — Thu, 19 Dec 2019 18:26:36 GMT

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.

Re: AD Security Event 4776

Colby LeMaire — Thu, 19 Dec 2019 23:01:20 GMT

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.

Re: AD Security Event 4776

paul — Fri, 20 Dec 2019 02:19:55 GMT

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

Re: AD Security Event 4776

supporto rai — Thu, 16 Jan 2020 12:54:41 GMT

Re: AD Security Event 4776

marco.merlo — Thu, 16 Jan 2020 12:57:08 GMT

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

Re: AD Security Event 4776

marco.merlo — Fri, 17 Jan 2020 14:36:35 GMT

Hi patch 11 did not solve the issue.

Re: AD Security Event 4776

hslai — Sat, 18 Jan 2020 18:26:02 GMT

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.

Re: AD Security Event 4776

marco.merlo — Mon, 20 Jan 2020 07:32:40 GMT

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

Re: AD Security Event 4776

hslai — Mon, 20 Jan 2020 15:52:48 GMT

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).

Re: AD Security Event 4776

marco.merlo — Tue, 21 Jan 2020 06:50:47 GMT

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