Topic
  • 10 replies
  • Latest Post - ‏2013-10-25T15:22:17Z by mark99
VarunTIM
VarunTIM
21 Posts

Pinned topic How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

‏2013-10-08T10:46:47Z |

Hi,

Currently I am working on a requirement where I am populating one multi-valued  custom attribute in person profile with the list of AD groups(filtered search on ergroup), now I have a provisioning policy in place that will provision all the selected groups from person profile to the AD target account. The question is if there are some AD groups which are not populated in the person profile and if those groups are provisioned for a user directly at the AD end then after the recon runs on AD I would like to allow those other groups on the account profile as compliant values. How to achieve that.

I hope I am clear with the requirement.

Thanks

  • yn2000
    yn2000
    1086 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-08T21:02:59Z  

    Nope. You cannot use Provisioning Policy to do that, because your requirement break the rule of the word 'provisioning policy'. When you set the provisioning policy to 'mandatory' and 'correct' compliance, you are announcing to the world, including AD, that TIM is correct and everybody else is wrong. So, when AD admin dare to change the AD groups data from AD directly, TIM would say that AD is wrong and TIM will overwrite the value. That is what the 'policy' said when you 'provision' to a target.

    Now, you want to break that policy. So, the solution would be to customize the operation the way you want it to work, and not using the entitlement in the Provisioning Policy.

    Rgds.  YN.

  • franzw
    franzw
    347 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T05:57:07Z  
    • yn2000
    • ‏2013-10-08T21:02:59Z

    Nope. You cannot use Provisioning Policy to do that, because your requirement break the rule of the word 'provisioning policy'. When you set the provisioning policy to 'mandatory' and 'correct' compliance, you are announcing to the world, including AD, that TIM is correct and everybody else is wrong. So, when AD admin dare to change the AD groups data from AD directly, TIM would say that AD is wrong and TIM will overwrite the value. That is what the 'policy' said when you 'provision' to a target.

    Now, you want to break that policy. So, the solution would be to customize the operation the way you want it to work, and not using the entitlement in the Provisioning Policy.

    Rgds.  YN.

    Well - it is not COMPLETELY true that when using "Correct Compliance" that you cannot build what is normally called a "hybrid" model - i.e. that some groups are managed as described here and some are non-managed/request based.

    But it is not (practically) possible depending on the source - meaning that you can make this difference based on where the account originates ( I could think of ways to this - but this requirement is simply to silly ;-)).

    To make such a hybrid model you basically split the group population into 2 sets - the one set is governed by mandatory polices - and the other set is based on allow policies. The easiest way to do this is by having a naming scheme for the groups - then you can basically allow/disallow them using regex policies - but it is seldom that this will be allowed.

    But - and here I have to warn you  - there is much more than this to be aware of in such a scheme - especially if you combine this with Exchange/Lync handling and lifecycle management - you can very easily get into very complex situations because compliance is evaluated and enforced in all account operations (i.e. if a policy is evaluated and violated in a step in the operations the operation will fail).

    I have implemented a hybrid model at one customer based on the the placement of the groups in specific OUs - beside the described side effects in the operations another things is that it scales pretty badly - this is not a problem there - but in the general situation it is an important thing also to consider...

    SO - my advice is - unless you bring on a consultant that knows ISIM in and out (like YN) you should forget about this - this is something that requires the highest available skill level and long long experience - I am pretty sure that YN knows how to do this - and there is a good reason you are adviced against it :-)

    Regards

    Franz Wolfhagen

  • NinadTamras
    NinadTamras
    11 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T07:27:12Z  

    In your case it seems like any AD group can be added directly from the AD resource side without consulting ITIM admins. If that is correct then you can follow the approach i am mentioning to achieve exactly what you want to implement :

    1. In addition to the existing "Mandatory" entitlement parameter for "erGroup", add one more entitlement parameter with ALLOWED enforcement of type REGULAR EXPRESSION with value ".*" (without the quotes) This way you are allowing all groups that were added directly on the AD resource side and at the same time enforcing the groups that are mandatory as per Person attributes.

    2. One more important thing to consider here is that, by default, in the AD Service Profile, the "erGroup" attribute is configured as REPLACE for Modify operation. This means when the Groups list of an existing AD Account is modified, it will send REPLACE command to agent and agent will replace the existing Groups of that account with the new list. This will cause exisitng groups added on resource side to be deleted from account. To avoid this from happening, you have to configure the "erGroup" attribute to send "ADD | DELETE" commands instead of REPLACE. To do this you have to remove the erGroup attribute from the AD Service Profile attribute "erOpMultiReplace" directly in LDAP under "ou=serviceProfile,erobjectprofilename=ADProfile". You may restart ITIM once for the ldap changes to take effect.

     

    Hope this will address exactly what you needed to implement.

    HTH

    Regards,

    Ninad Tamras

     

  • franzw
    franzw
    347 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T08:11:18Z  

    In your case it seems like any AD group can be added directly from the AD resource side without consulting ITIM admins. If that is correct then you can follow the approach i am mentioning to achieve exactly what you want to implement :

    1. In addition to the existing "Mandatory" entitlement parameter for "erGroup", add one more entitlement parameter with ALLOWED enforcement of type REGULAR EXPRESSION with value ".*" (without the quotes) This way you are allowing all groups that were added directly on the AD resource side and at the same time enforcing the groups that are mandatory as per Person attributes.

    2. One more important thing to consider here is that, by default, in the AD Service Profile, the "erGroup" attribute is configured as REPLACE for Modify operation. This means when the Groups list of an existing AD Account is modified, it will send REPLACE command to agent and agent will replace the existing Groups of that account with the new list. This will cause exisitng groups added on resource side to be deleted from account. To avoid this from happening, you have to configure the "erGroup" attribute to send "ADD | DELETE" commands instead of REPLACE. To do this you have to remove the erGroup attribute from the AD Service Profile attribute "erOpMultiReplace" directly in LDAP under "ou=serviceProfile,erobjectprofilename=ADProfile". You may restart ITIM once for the ldap changes to take effect.

     

    Hope this will address exactly what you needed to implement.

    HTH

    Regards,

    Ninad Tamras

     

    :-) - that was the scheme we ran BEFORE we implemented the more complex.

    I hope you are aware that there is one major drawback in you scheme - you cannot remove ergroups from ITIM unless you do it via the account/access request.... - removing people out of an ITIM Role will not remove the else mandatory ergroup as it will be allowed by the .* regex....

    Another point - you change some the things that is part of the profile you should for your own sake rebuild the profile with the new setting...

    HTH

    Regards

    Franz Wolfhagen

  • mark99
    mark99
    26 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T08:34:54Z  

    I don't understand why this can't be done in straight forward manner. Is the hybrid model not the way to go when starting to implement a policy driven system on top of an existing infrastructure ?

    You start with a few groups under control of TIM and expand the number of groups as you go.

    I create a few custom adapters. The hybrid model was part of the design from the start.

    Mark Vinkx

     

  • NinadTamras
    NinadTamras
    11 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T09:07:18Z  
    • franzw
    • ‏2013-10-09T08:11:18Z

    :-) - that was the scheme we ran BEFORE we implemented the more complex.

    I hope you are aware that there is one major drawback in you scheme - you cannot remove ergroups from ITIM unless you do it via the account/access request.... - removing people out of an ITIM Role will not remove the else mandatory ergroup as it will be allowed by the .* regex....

    Another point - you change some the things that is part of the profile you should for your own sake rebuild the profile with the new setting...

    HTH

    Regards

    Franz Wolfhagen

    Completely Agreed, Franz. I missed this point in my solution approach above.

    In my own custom implementation of this same scenario for a customer, I have written Javascript logic in Person Modify workflow to check the roles being removed from the person and then remove the corresponding AD groups for these removed roles from the AD Account. This way the Mandatory & Correct Compliance is also maintained.

    Somehow I forgot to include this point in my solution approach in my earlier reply.

    Thanks for bringing it to my notice. :)

    Regards,

    Ninad

  • franzw
    franzw
    347 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T09:57:05Z  

    Completely Agreed, Franz. I missed this point in my solution approach above.

    In my own custom implementation of this same scenario for a customer, I have written Javascript logic in Person Modify workflow to check the roles being removed from the person and then remove the corresponding AD groups for these removed roles from the AD Account. This way the Mandatory & Correct Compliance is also maintained.

    Somehow I forgot to include this point in my solution approach in my earlier reply.

    Thanks for bringing it to my notice. :)

    Regards,

    Ninad

    Which is bringing me to the next topic of "best practice" - you should definitely avoid the mixing of policies and changing attributes in operations - this is for many reasons a bad thing to do.

    The problem here is an architectural problem - and you should stick to model of the system as possible as this will guarantee you (at least in theory)  a lesser cost and higher TCO. The point that you forgot it in your post is actually showing the problem - you could have done the same in a project decision and only found the problem in test or even later...

    I will not go into detail here - but this is something I talk about on conferences when I get the chance...

    Regards

    Franz Wolfhagen

  • franzw
    franzw
    347 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T10:04:10Z  
    • mark99
    • ‏2013-10-09T08:34:54Z

    I don't understand why this can't be done in straight forward manner. Is the hybrid model not the way to go when starting to implement a policy driven system on top of an existing infrastructure ?

    You start with a few groups under control of TIM and expand the number of groups as you go.

    I create a few custom adapters. The hybrid model was part of the design from the start.

    Mark Vinkx

     

    The ISIM provisioning engine is very versatile - but it has not all the bells and whistles that you could wish right now - hopefully IBM will improve the situation in the next upcoming releases. Already in ISIM 6 there are interesting additions - such as the support for having account ownership types - basically this solves a very long standing problem of having multiple accounts on the same service.

    Personally I hope this improves with other additions for e.g. problems like this.

    But if you look at the background of the problem this is derived problem from going from an account request level to a role (person) level model that was not completely foreseen in the product originally. But the underlying architecture in ISIM is so flexible that there is no architectural issues in solving the problems as I see it.  But there is a lot of work to be done in the details - and these are some of those requirements that are difficult to get enough attention to - if you want to help you can always raise a RFE.

    Regards

    Franz Wolfhagen

  • yn2000
    yn2000
    1086 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-09T14:57:18Z  
    • mark99
    • ‏2013-10-09T08:34:54Z

    I don't understand why this can't be done in straight forward manner. Is the hybrid model not the way to go when starting to implement a policy driven system on top of an existing infrastructure ?

    You start with a few groups under control of TIM and expand the number of groups as you go.

    I create a few custom adapters. The hybrid model was part of the design from the start.

    Mark Vinkx

     

    I guess, I've been lucky winning a good battle over the years.

    So far, I am able to convince my customer to recognize the different between a configuration of 'provisioning policy' and 'custom'. And this is 'custom' job. And, I would ask the customer to give a bloody thumb print to step into 'custom' jobs, especially when there is a condition on what we use to call "it works, but not supported by IBM."

    So, I guess, my suggestion to VarunTIM is to call IBM support, because the line between 'configuration' versus 'custom' may have shifted.

    Rgds. YN.

  • mark99
    mark99
    26 Posts

    Re: How to Allow AD Groups That Are not part of the ISIM Provisioning Policy

    ‏2013-10-25T15:22:17Z  
    • franzw
    • ‏2013-10-09T08:11:18Z

    :-) - that was the scheme we ran BEFORE we implemented the more complex.

    I hope you are aware that there is one major drawback in you scheme - you cannot remove ergroups from ITIM unless you do it via the account/access request.... - removing people out of an ITIM Role will not remove the else mandatory ergroup as it will be allowed by the .* regex....

    Another point - you change some the things that is part of the profile you should for your own sake rebuild the profile with the new setting...

    HTH

    Regards

    Franz Wolfhagen

    Franz,Ninad

    It took me a while to figure out what was written here.  Together with some info I found on goolge I found a way to make removal of rolls work

    In my setup I have 2 groups called tim1 and tim2 that I want to control based on roles.  I made the following provision policies on an AD service s with noncompliancy action set to correct.

    pp of role1:
    manual AD account
    group exclude .*tim.*
    group mandatory tim1

    pp of role2:
    manual AD account
    group exclude .*tim.*
    group mandatory tim2

    pp of role0
    mandatory AD account
    group exclude .*tim.*

    placing a user in role0 and role1 gives group tim1
    removing role1 removes group tim1
    adding role1 and role2  gives group tim1 and tim2

    All without touching the AD groups imported by recon or obainted by request

     

    Greetings

    Mark Vinkx