Testing 8.0 Credential phishing prevention

Reply
Highlighted
L2 Linker

Re: Testing 8.0 Credential phishing prevention

@dkordybanThe reason I ask is that I hooked up a debugging mechanism to the pan user id credential agent connection between the credential agent and its RODC ldap connection that exists locally on the machine, because credential phishing detection (based on username/password) combo was not working.  If i just switch it to username that would work, but that net is too large.

 

This is the query that the credential agent runs against LDAP to enumerate users in the "Domain Users" group, assuming that's the one of the groups present in "Allowed RODC Password Replication Group".

 

(&(&(objectclass=Person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(memberof=cn=domain users,cn=users,dc=saustin,dc=com))

 

This query would absolutely work for any group EXCEPT the primary group.  The reason is that enumerating users in the primary group can't be done like this in AD and this query returns 0 user names and thus no credentials would be read via the credential agent for that group. 

I verified this in my lab setup and production.  I then added a random second (non-primary) group to "Allowed RODC Password Replication Group" that exist in my AD forest and bounced the credential agent.  The credential agent was able to enumerate those users and create a bloom filter for them just fine.

 

You can check the number of credentials sent from the credential agent to the firewall by running this commandimage (5).png

I have well over 2000+ users in my AD forest, and currently 500~ passwords cached on the RODC (verified via active directory tools) which is quite a bit larger than 67.  67 is conviently the exact number of users that exist in the non-primary group I added to verify my hunch about the credential agent not properly enumerating users in the "Domain Users" group.

 

If you're seeing that the credential count for the bloom filter on the firewall corresponds to all the users in your AD, i'd be curious to know what version of the credential agent and user-id agent you're using.

Tags (1)
L2 Linker

Re: Testing 8.0 Credential phishing prevention

netflix seems to always be a good test for us. Yes, we decrypt most traffic.

L2 Linker

Re: Testing 8.0 Credential phishing prevention

I see. I wasnt aware of that restriction.

thanks

L2 Linker

Re: Testing 8.0 Credential phishing prevention

Wondering if I could just nest the domain users into another global group then make it a member of Allowed RODC users?

L2 Linker

Re: Testing 8.0 Credential phishing prevention

That unfortunately wouldn't work as the credential agent just recursively goes through all groups in the allowed rodc password replication group, then runs a direct ldap query trying to enumerate that group.  The only way to enumerate users in "Domain Users" doing a ldap query is to use (primaryGroupID=513).  I'm trying to raise the issue with my account rep.

L1 Bithead

Re: Testing 8.0 Credential phishing prevention

Hi,

 

The issue has been raised a little while back.  Support for the "Domain Users" group may be ported into 8.0.10 but has not been yet.

aemr
L6 Presenter

Re: Testing 8.0 Credential phishing prevention

Has anyone made any progress getting this working?

 

I'm currently in the process of trying to get this deployed in my environment (have an active support case) but am running into a fair amount of obstacles.

 

We have multiple RODCs in our environment so we created a new RODC just for this purpose.  We removed the inherent "Allowed RODC Password Replication" group vice adding to this group as we didn't want to cache accounts globally across the enterprise.  

 

Looks like we're initially being told from TAC that the credential software will only query this inherent group .  (which we've removed - FR likely to query something other than "Allowed RODC Password Replication" )  Instead we added "Domain Users" to be allowed to be cached locally on this RODC in question.

 

We probably have 25,000+ user/service accounts and so far we only have 570 cached account on the RODC post allowing "Domain Users" to be cached. 

 

*EDIT* UIA/Cred software is creating a Bloomfilter that currently only contains 20 user accounts

 

 

My AD guys are telling me that the caching process only occurs when the RODC proxies an auth request for a specific account.  Apparently you can force the RODC to cache an account, but it's on an individual account basis and can't be done via user/security groups.

 

*EDIT* Using RODC 2016 - UIA/Cred software 8.0.9-6 (also tried 8.0.8-2)

L2 Linker

Re: Testing 8.0 Credential phishing prevention

Hi @Brandon_Wertz,

 

There could be a few reasons it's not working.  I want to confirm I understand you correctly first.  Are you saying that you removed the "allowed rodc password replication group" from the password replication policy tab of the RODC?  And then you replaced it with "Domain Users" and set it to allow in the password replication policy tab of the RODC?  

 

The first reason this doesn't work is because the PAN credential agent cannot enumerate users in "Domain Users".  The reason it can't do it is because "Domain Users" is a special AD object and the credential agent does't form the ldap query properly.  In addition to the aforementioned issue, I don't know if the credential agent will query any group that's not in "allowed rodc password replication group" (this is a conjecture as i've only nested groups in "allowed rodc password replication group".  The second part may not be a contributing factor.

 

What I had to do to get it working is as follows:

1.  I created an AD object called allmyusers and added all user accounts to the group.

2.  I added allmyusers object to "Allowed rodc password replciation group"

3.  Bounced the pan userid and credential agent

 

Until PAN fixes the issue, "Domain users" will not work and you have to create a different group that essentially does the same thing but isn't the build in "Domain users" group.

L6 Presenter

Re: Testing 8.0 Credential phishing prevention


@staustin wrote:

Hi @Brandon_Wertz,

 

There could be a few reasons it's not working.  I want to confirm I understand you correctly first.  Are you saying that you removed the "allowed rodc password replication group" from the password replication policy tab of the RODC?  And then you replaced it with "Domain Users" and set it to allow in the password replication policy tab of the RODC?  

 


 

Yes

 


@staustin wrote:

Hi @Brandon_Wertz,

 

 

 In addition to the aforementioned issue, I don't know if the credential agent will query any group that's not in "allowed rodc password replication group" (this is a conjecture as i've only nested groups in "allowed rodc password replication group".  The second part may not be a contributing factor.

 .


 

 

This is what we did, and we're being told the user-agent / cred software is likely only coded to query this inherent group.  We don't want to use this inherent group utilized across our enterprise on other RODCs (scope creep / security risk...why push cached creds to RODCs on RODCs that don't need it)

 

 

 


@staustin wrote:

Hi @Brandon_Wertz,

 

 

 

What I had to do to get it working is as follows:

1.  I created an AD object called allmyusers and added all user accounts to the group.

2.  I added allmyusers object to "Allowed rodc password replciation group"

3.  Bounced the pan userid and credential agent

 

Until PAN fixes the issue, "Domain users" will not work and you have to create a different group that essentially does the same thing but isn't the build in "Domain users" group.


 

 

There's the inherent problem with our deployment.  Why would we replicate our entire enterprise password cache to "sensitive" locations in our environment by putting all users in an inherent / global group?  This doesn't seem very secure.

 

I've actually got this working previously using software on a writeable domain controller.  it seems like it would be smarter to just utilize a writeable DC and not touch what should be this protected group.

 

 

L2 Linker

Re: Testing 8.0 Credential phishing prevention

Your concerns about security are definitely valid.  I was able to work with the constraint in my environment because we only have 2k users and all our DCs live in the same place.  PAN heavily recommends not using a writeable DC, but there's nothing stopping you.  You can still try not using the global allowed rodc password rep group and create a custom group with like 20-40 users in it first to see if the cred agent will try and query it.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!