Version Differences for Security

===Example of Active Directory Configuration===

+

Below is an example of a typical, albeit small, Active Directory configuration.[http://technet.microsoft.com/en-us/library/cc977992.aspx This site] explains a lot about how and why I chose the values of the fields below.

[[Image:Sample AD Configuration.png]]

+

[[Image:ADGroups.PNG]]

+

====Configuring the Authorization Realm====

[[Image:Corresponding uDeploy Authorization Zone.png]]

+

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

+

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====

+

[[Image:Authorization Realm Ex.png]]

+

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 log in, 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, 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 to the location of the groups that are important to uDeploy, all 1000 groups will be imported. This make focusing your group search base VERY important if you have a large number of groups in AD.

== Roles ==

 ===Example of Active Directory Configuration===
                 Below is an example of a typical, albeit small, Active Directory configuration.[http://technet.microsoft.com/en-us/library/cc977992.aspx This site] explains a lot about how and why I chose the values of the fields below.
 [[Image:Sample AD Configuration.png]]
                 [[Image:ADGroups.PNG]]
                 ====Configuring the Authorization Realm====
 [[Image:Corresponding uDeploy Authorization Zone.png]]
                 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
                 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====
                 [[Image:Authorization Realm Ex.png]]
                 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 log in, 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, 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 to the location of the groups that are important to uDeploy, all 1000 groups will be imported. This make focusing your group search base VERY important if you have a large number of groups in AD.
 == Roles ==