You have to grant the UserAccount entitlement to a user.  This is what controls access to AD Accounts.   And to your point, NO the AD driver does not automatically add the entitlement.  It is a gatekeeper so you have to assign it somehow.

So everyone who should have AD accounts, should have the Entitlememt.  You can grant a role at the Container level.  (Not a fan).  You can start building Roles for locations or whercver that start with just the AD Account entitlement for now and start assigning those.  Then add additional entitlements when you are ready to start using them.

Hi Geoffrey,

By granting u mean I need to write a rule to add the entitlement in the driver??

Generally, you do not add the Entitlement to a user in the driver that grants it.  You could but it is not a great idea.

Instead, you should start thinking about how you plan to lay out your roles?

One approach is a loopback driver that watches events and as attributes are added/removed reacts by using the do-add-role and do-remove-role tokens to change the roles the user gets.

A second approach is to make a Dynamic LDAP group, with a filter that matches the attribute values above, and then assign each Group a Role.  RRSD will check every hour by default (I think) for dynamic group member changes.

Or perhaps your HR system, when it creates a user, assigns a role to startwith, which would include a Resource for the AD USerAccount entitilement.

Or you could be using IGA and let it do the role management.

Hi Geoffrey,

Ive added an entitlement on AD account, but where do i assign it in driver to give user the ad user account entitlement automatically? ive created a user from HR> created in LDAP> but did not create in AD due to dont have user account entitlement.

The important part to think about is how Entitlements are meant to be used.

The AD driver IMPLEMENTS entitlements, that is when a user gets an Entitlement the AD driver follows its orders and does its job

The AD Driver does not ASSIGN entitlements to anyone, unless you chose to do so. 

The original Entitlement model, used the Roles Based Entitlement driver, now deprecated.  That allowed you to specify an LDAP Dynamic group, and assign Entititlememts to members of that group. 

Next came User App, with Resources, where you assign a Role to user in policy in some other driver (for auto stuff) or manually after a request in UA.  That Role has some associated Resources.  Each of those Resources has a single (Now, used to allow more than one) Entitlement so the user gets the sum of all the entitlements in all the Resources it gets from all the Roles it gets assigned. 

Then each driver with one of those entitlements does it job.

Thus, create a Role in User App.  Create a Resource in User App called AD Account, and pick the ENtitlement from the AD driver for UserAccount.

Now associate the Resource to the Role.  (Done at Role level I believe, so maybe create Role last).  and assign a user to the Role.

The question you have to answer is, how does a new user get this Role?  Or any role?

Now, if you use Entitlements for everything, you may want an 'employee" role, which contains the AD Account entitlement, the LDAP Account Entiitlement and so on.  Specific groups, maybe come with the HR Role, or Payroll Role. 

Or maybe you have to have a Job Title or CostCenter or Location that is mapped to a Role and those Roles deliver the AD Account Enttitlement and some AD Groups.

You can make a dynamic group that defines its members as CostCenter=XYZ and then assign a Role to that group if you wanted to automate this.