Self service account creation/management

Hi jody gilbert 

There are a number of options available to enable <some group of users> to be able to request the creation of an account, but depends on your use case.

All of them in some part relate to granting permissions to perform the desired task via Access Templates, then linking that Access Template to some OU where these service accounts should be created, granting it to some trustee (a user or group).

To enable someone to create a service account (for initial testing), I do the following:

1) Create a new security groups call "Allowed to create service account" (or something more inline with your naming standards

2) Add some test user account into that group (not an account which already has full ARS Admin permissions)

3) Confirm (or Create) the OU where the service accounts should be created

4) Link the Access Template "CN=Users - Create User Accounts,CN=Active Directory,CN=Access Templates,CN=Configuration" to the OU where the service account should be created, adding the "Allowed to create service account" group as the trustee

5) Also link the Access Tempalte "CN=All Objects - Read All Properties,CN=Active Directory,CN=Access Templates,CN=Configuration" to the Managed Domain where the Serviec Account OU exists, adding the "Allowed to create service account" group as the trustee

NB: the 5th entry is only required if the users don't already have access to that OU somehow, this is not least privilege, it would grant members of that group, permissions to read everything in that managed domain. But for demo purposes

6) For testing, open a second Active Roles Console, and log in as the test user added into your group in step 2., Then navigate to the Service Account OU, right click and choose New  and User

7) Continue through the new user form and test the creation of the user

The permission granted so far, are only to create the object, not to change any of the properties.

As I suspect you don't want everyone in the  "Allowed to create service account" to bew able to change things (like passwords) against any service account in that OU, you're not going to want to grant permissions to the  "Allowed to create service account" group. Instead if as part of creation, you set the Managed By attribute to be the creating person or someone set as part of the creation. You can grant for example

Link the Access Template "CN=Users - Help Desk,CN=Active Directory,CN=Access Templates,CN=Configuration" to the active roles well known principal "Manager" and apply against your service accounts OU. Then as long as the service account has a manager attribute assigned against it, the user listed as the manager will be able to perform whatever tasks against objects they own as granted by the users - help desk access template, in this case it would be "Reset user passwords, unlock user accounts, assign or remove digital (X.509) certificates from user accounts, view all properties of user accounts."

Then if you got back into the console where you logged on as the test user, and re-connect, when you right click the service account, you'll get a different set of options than before (including reset password)

Also please note, as John pointed out to me, that this would need to be done from the full web portal, not self service. The SelfService portal does not provide the ability to create objects.

You might however be able to call the create user for of the ARSWebAdmin site from the SelfService portal from a custom tile from the SelfService homepage.

many thanks for the detailed response, this is exactly what I'm looking for.

One other question, I'm afraid, is it possible to have the Manager attribute default to the current user when creating the user account?  We have got manager configured as a required attribute, I just cannot see how to have it default to the person creating the account.

I believe I worked this out by using the following script that is included as a policy for the OU in question:

function onPreCreate($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function onPreModify($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function onInit($context) {
}

function onCheckPropertyValues($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function DefineDefaultManager($Request){
    $manager = $Request.GetPropertyItem("manager", $Constants.ADSTYPE_CASE_IGNORE_STRING)
    if($null -eq $manager){
        $strSan = ""
        $strDN = ""
        $Request.WhoAmi([ref]$strSan, [ref]$strDN)
        $Request.Put("manager", $strDN)
    }
}

I believe I worked this out by using the following script that is included as a policy for the OU in question:

function onPreCreate($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function onPreModify($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function onInit($context) {
}

function onCheckPropertyValues($Request) {
    if ($Request.Class -ne "user") { return }
    DefineDefaultManager($Request)
}

function DefineDefaultManager($Request){
    $manager = $Request.GetPropertyItem("manager", $Constants.ADSTYPE_CASE_IGNORE_STRING)
    if($null -eq $manager){
        $strSan = ""
        $strDN = ""
        $Request.WhoAmi([ref]$strSan, [ref]$strDN)
        $Request.Put("manager", $strDN)
    }
}