Security
Configuring LDAP
Example of Active Directory Configuration
Below is an example of a typical, albeit small, Active Directory configuration.This site explains a lot about how and why I chose the values of the fields below.
Configuring the Authentication Realm
Fields that may need clerification:
Authorization Realm: this is what determines how groups are handled when a user logs in. When you create Authentication Realms, this list is populated with them. See below for configuring one.
User Search Base: this is what determines where uDeploy searches for "users". See the note below.
Search User Subtree: This will search lower level OUs for the users. E.g. If I set my User Search Base to ou=Support,DC=ad-env-test,DC=dev,DC=urbancode,DC=com, It wouldn't find my users in ou=SupportUsers unless I checked this box.
Stuff you can't see all of:
LDAP URL: ldap://ad-env-test.dev.urbancode.com
User Search Base: ou=SupportUsers,ou=Support,DC=ad-env-test,DC=dev,DC=urbancode,DC=com
Note: AD doesn't distinguish between object types, so a user is a group is a computer when importing. So, if you have your user search base set to a location that contains users, groups, and/or computers and you attempt to import all objects (by clicking import users and using a wild card *), thinking that it will only get the users, it will get all of the objects that exist in your defined location. So you'll have users, as well as groups and computers that look like users, in your authorization realm. This won't break anything, but it will be really annoying for you when trying to configure roles. This isn't a problem if you don't try to import everything... ever. As long as you only import intelligently, let the users log in themselves (which does the same thing as importing), or only have users in your user search base location, you won't have a problem.
Configuring the Authorization Realm
Final Notes
Once this configuration is completed successfully, the expected functionality would be when a user attempts to login to uDeploy, a quarry is made to Active Directory. Assuming that a username is found and that the password for that user is correct, the user's information is imported to uDeploy, including the groups that the user belongs to.
With this in mind, it's important to limit your user and group search bases to users and groups that are useful in uDeploy. When regarding this, a user will only be imported when they attempt to login, thus only 1 user will be imported per login attempt. This means that you could configure you user search base to be the entire AD structure, but you would only have extra users if those extra users attempted to login. This makes limiting the user search base important only in regards to limiting the users that CAN login to uDeploy.
However, this is not the same for groups. If one user logs in and belongs to 1000 groups, unless you've limited your group search base, all 1000 groups will be imported. This make focusing your group search base to only the location that contains the groups that are useful in uDeploy VERY important if you have a large number of groups in AD. The consequences of importing this many groups could be catastrophic to the usability of uDeploy, causing extremely slow load times as the uDeploy server quarries the database for the permissions that these groups have every time you navigate to a location that you need permissions to access.
Our advice is to create an OU that contains groups that have been made specifically for use in uDeploy, and configuring your group search base in your authorization realm to point to it.
Roles
Deployment Approvals
The minimum permissions a user needs to make approvals is read on the Application/Environment/Component requiring the approval, as well as access to the work items in the UI.
The minimum steps required to set up an approval process are as follows:
Creating roles for approvals and assigning users:
- Create a role that will define the approvers on the Application/Environment/Component(depending on the level of approval you want), giving users assigned to the role at least read access.
Settings>Role Configuration>Applications/Environments/Components
- Create a role (or use the default Approver role) on the Web UI tab, giving users assigned to that role access to at least the Work Items tab.
Settings>Role Configuration>Web UI
- Assign users/groups to the role created in step 2 on the UI Security tab.
Settings/UI Security
- Assign users/groups to the roles created in step 1 on the Application, Component, and/or Environment.
Application/Component>Security and/or Application>Environment>Security
Configuring the Environment to require approvals:
- Create/edit an environment, choosing to require approvals.
Application>Environment>Edit
- Configure the Approval Process, choosing the level of approval and the role that will be approving.
Application>Environment>Approval Process
