Active Directory Role Management

Microsoft Active Directory and LDAP (Lightweight Directory Access Protocol) are “single sign-on” facilities available from Microsoft and other vendors that provide a single sign-on and user authentication facility. A user signs in once, and that sign in is transferred to all applications used by the user, saving them the time to sign in to each individual application. Moreover, these facilities provide centralized user access control for IT departments, making it easier to manage user accounts.

Microsoft Active Directory and LDAP

The main purpose of Active Directory is to provide central authentication and authorization services for Windows-based computers. Active Directory also allows administrators to assign policies, deploy software, and apply critical updates to an organization. Active Directory stores its information and settings in a central database.

The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying directory services running over TCP/IP. Microsoft Active Directory uses the LDAP protocol for communication with the Active Directory server, primarily in Microsoft Windows environments. The client sends operation requests to the Active Directory server, and the server sends responses in turn and these requests and responses are LDAP protocol compliant.

Iron Speed Designer does not use the typical .NET membership model for several reasons:

Iron Speed Designer allows you to configure groups and must be able to retrieve all groups from the Active Directory server, not only those belonging to the currently logged in user. This is possible using LDAP but not the .NET membership model because this approach allows Iron Speed Designer to create a DirectoryEntry object in order to run DirectorySearcher on Active Directory.
Iron Speed Designer populates Active Directory connection strings without forcing you to enter any Active Directory related information in your application’s Web.config file.
Iron Speed Designer applications allow users to log in with a different name than the one used to run the application.
Iron Speed Designer applications allow remote login.

For a detailed explanation of LDAP protocol: http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol

For a detailed explanation of Active Directory: http://en.wikipedia.org/wiki/Active_directory

Active Directory request encryption

Security for Active Directory calls is handled by the Microsoft DirectoryServices API. Also, user authentication is provided by Active Directory itself by creating a DirectoryEntry object for the specific user’s credentials.

Novell eDirectory is not supported

Iron Speed Designer does not support Novell eDirectory. However, you can add authentication and access control security for Novell eDirectory via a code customization.

Active Directory role management (Windows User Groups Role Management)

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 Sign In page. (Note: The application user will not be signed in if the requested page’s security role is set to ‘Everyone’, ‘Anonymous’ or no roles are configured for the page. 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; [email protected];
The application user will be authenticated and the roles will be retrieved for all domain controllers which have domainname.

Page has roles associated with domains

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.

No access

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.

Nested groups

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.

Naming restrictions for Active Directory groups

The following special symbols are not allowed in the Active Directory group names:

/, \, ”, ;

These symbols are used as dividers between groups, domains and strings in Iron Speed Designer applications. If an Active Directory group containing any of these symbols is used to secure a page it will not be recognized and may lead to a compilation error.

Some built-in groups such as Domain Users, Domain Admins and some others also cannot be used as roles.

Multiple domain controllers

If you have complex Active Directory forest and configure multiple connection strings to different domain controllers, you might experience problems retrieving roles for some connections. In this case try using a specific port in the LDAP connection string. The default port for the LDAP connection is 389, but sometimes port 3268 should be used instead to ensure proper connection and retrieval of user information. Consult your IT administrator to verify if port 3268 is enabled.

For more detail: http://technet.microsoft.com/en-us/library/cc978012.aspx