Perspective Security Level Rules

[Chris_Bingham]

I agree with others above. A login experience should be intuitive. Reference other public-facing websites as a model for your login (Google, Microsoft, …).

I would either:

1. Enforce “Authenticated” in order to access the project at all (preferred, where any authenticated user is configured for read-only access by default, those with specific roles will be elevated).
2. Allow “Public” (unauthenticated) access to the project but add tag provider + tag security to ensure that only “Authenticated/Admin” has access to write.

If you wish to reject a user’s login when they are not a member of a specific group, then you should configure the filter on your AD source to be limited to members of a specific group, whereby other members will not be able authenticate at all - and they’ll be forced to back out of authentication.

For reference:

Active Directory LDAP User Search Filter - Filter out memberOf specific group(s)

Yes, hopefully this helps you and others. The method that we needed to use was the User List Filter along with the User Listing Base and User Search Filter. It’s helps to get the DistinguishedName of the path to the OU you want to use (Like Sysinternals AD Explorer). I will describe the filters strings below. #Use to narrow down which Organizational Units to search for. The more you use, the faster the audit roles will be. Being too broad can make it slower. To do this you combine your OU’s…