Testing 8.0 Credential phishing prevention

[dkordyban]

Support says eveything has been setup properly for this to work. How would you test that users would not be able to enter domain credentials into bogus site? 

[ArthurEmr]

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.

[Brandon_Wertz]

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)

[staustin]

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.

[Brandon_Wertz]

---

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

[staustin]

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.

[Brandon_Wertz]

---

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

---

Also regarding your "step 1"

I'm not sure how larger your AD environment is, but with service account, process control accounts, and various user accounts/types numbering best guess 25k+; for us to accomplish this "Step 1" would be an extremely long process and would be fraught with potential for missing critical accounts.  Hence my stance in bypassing this whole headache and just move this to a writeable DC.

[Brandon_Wertz]

Just my theory...they don't want to be liable if something malicious happens and the software is somehow used to make changes to account creds when the purpose is meant to protect credentials so I see why the stated architecture is on an RODC.

In practice it doesn't seem to be like a viable option though, if the only way to use the RODC is to also use a group which would cache creds to RODCs we don't want.

[staustin]

This isn't necessarily true.  You could do it in a single line powershell script.  This should copy everything in domain users to a group2

Get-AdGroupMember -Identity "Domain Users" | %{Add-AdGroupMember -Identity "group2" -members $_}

[Brandon_Wertz]

---

@staustin wrote:

This isn't necessarily true.  You could do it in a single line powershell script.  This should copy everything in domain users to a group2

Get-AdGroupMember -Identity "Domain Users" | %{Add-AdGroupMember -Identity "group2" -members $_}

---

<-- Traditional FW/Network guy with 3 years of AD experience 14 years ago so my knowledge on how easy / difficult some processes are aren't to great.

It's good to see this is doable.  Unfortunately it still leverages a group which for us probably wouldn't work from a security risk perspective.  Maybe we can use this user ID scrape for future needs though.

[Brandon_Wertz]

Response from TAC on my support case just relayed to me that:

"I have confirmed that the UID credential agent only query the Allowed RODC Password Replication Group."

So until there's an update to the software (FR) users of this product will be required to utilize the "Allowed RODC password Replciation Group"

[staustin]

figured as much.  sorry to hear that.

[ArthurEmr]

The Domain Users group is now supported (8.0.10) for use in "Allowed RODC Password Replication Group"