When an application user starts your application, and the ‘Automatically Sign-In’ option is set to ‘Yes’, your application will try to sign in using the application user’s identity information provided by Microsoft Windows. This is frequently referred to as ‘single sign on’. If sign-in is successful, the application will retrieve the application user’s roles from the Active Directory. ‘Roles’ refers to the Active Directory’s User Groups for which the application user is member. If any of these roles matches any of the specified roles for the page, the page will be displayed. If the roles do not match, the application user is redirected to the Forbidden page. If the user can’t be authenticated by the Active Directory, he is redirected to the Sig In page. (Note: if the requested page’s security role is set to ‘Everyone’, ‘Anonymous’ or no roles are configured for the page, the application user will not be signed in. Application sign in occurs only when requesting a page that requires secure access.)
Your application retrieves roles (groups) from the Active directory for the user name provided at sign in. Valid name formats are:
username. In this case the application assumes that the user belongs to the default domain. The user is validated and all roles are retrieved from the default domain controller.
domainname/username;
domainname\username; username@domainname.com;
The application user will be authenticated and the roles will be retrieved
for all domain controllers which have domainname.
When your application decides whether a user has access to a particular page or control, it compares its list of user roles and the list of roles applicable to the page. If there is a match and the application does not have domain\no-one role, the application user is granted access to the page or control.
Example:
DC1: LDAP://DC=dom,DC=com (default)
DC2: LDAP://upperdomain.dom.com/DC=dom,DC=com
roles for page1: dom\no-one; upperdomain\signed-in users
Example 1: The user signs in as: username // password
He will be authenticated against the DC1 and if username / password combination is valid, than all his roles will have the format of dom\role1;dom\role2, etc. So when he attempts to open page1, he will be forwarded to the Forbidden page because for dom this page has the ‘no-one’ role set.
Example 2: The user logs as upperdomain\username // password.
In this case, the user is authenticated against DC2 and if username/password combination is valid with this domain controller, his roles will be upperdomain\role1;upperdomain\role2,… dom\role11;dom\role12… (because DC2 has both domains in its definition: upperdomain and dom). So when access to page1 is requested, the application will deny access for domain dom, but allow this user to access the page1, because the user also belongs (has roles) to domain upperdomain and page1 has the upperdomain\signed-in users role set.
This structure allows you to fine tune access rights for different domains. Note: that if domain controller has several domains in its connection strings all of them will be included in the list.
If the page has All Domains\No one role, then no one will be able to see this page. However, if the page has domain\No one and otherdomain\otherrole roles, users that have otherrole and belong to otherdomain will be able to see the page.
Controls with roles specified either shown or not depending on user’s roles and they do not cause redirection.
The Active Directory Groups role management implementation recognizes only direct members of any group (role). It does not recognize nested groups (roles). For example, assume user ‘BradPitt’ is a member of the ‘HollywoodActors’ group and this group itself is a member of the ‘Actors’ group. If you restrict access for a page to the ‘Actors’ role, your page will not be accessible to ‘BradPitt’ unless you include ‘BradPitt’ as a member of the ‘Actors’ group.
Active Directory and Microsoft Authorization Manager Configuration