Skip to main content

We recently attempted to set our NPA policies to our "Domain Users" (in our case "corp.alfacompanies.com/Users/Domain Users") group rather than leaving the "source/user=" field empty so it applies to All Users. 

 

After the policies had time to simmer, we began noticing problems with

  • file shares (likely a DNS or Domain Controller conflict)
    • lost access to the file shares
    • Windows Security prompts asking for credentials
  • gpupdate /force
    • failed almost immediately due to failure to connect
  • Forticlient EMS 
    • status failed over to "not reachable"

After changing our NPA policies related to domain controllers and DNS back to user=all users (aka empty) and allowing time for the settings to propagate , access returned to normal. 

That begged the question, why would setting the policy to "Domain Users" create such an adverse issue. In your experiences, if all domain users need access, do you typically leave the "source/user=" field empty?

@AlfaBane


 


The entitlements that the client receives are based on matching the authenticated user's assignments in real-time protection policies based on group, OU, direct assignment to their user, and the empty assignment (all users).  In this case, it sounds like changing to the Domain Users Group assignment caused a failure for this entitlement to reach the client.  We would need to check if it's an issue where the user(s) aren't in that group in Netskope (failure in provisioning or something else) or an issue generating the SRP on our backend.   You can start by verifying that Domain Users in Netskope contains all the provisioned users.  Additionally, was this Domain Users group imported via Directory Importer or SCIM? 


@sshiflett  it looks like this was all orginally configured via directory importer. Upon further review, the Domain Users>Details looks to be empty despite similarly aged groups having contents (users). 

After some internal discussion, we're now curious if we are " using the best architecture for AD integration"? 


If you have Azure AD or Okta you can use SCIM provisioning which is preferred. Otherwise, you will need to keep using Directory Importer. 


@AlfaBane the discussion here refreshed my memory.  The Domain Users group membership is not imported due to the LDAP query used for group membership.  Since Domain Users is the primary group of most users, the query doesn't return this membership when Netskope queries it.  This is documented here.  If you want to assign to all domain users I'd suggest using a custom group or just not selecting user.  The second option mentioned will include all users AND the prelogon user if you are using that functionality.   


Reply