Topic
  • 4 replies
  • Latest Post - ‏2013-11-03T08:36:13Z by goonitsupport
312000
312000
8 Posts

Pinned topic reconciling the multivalued CN attribute to TIM

‏2013-10-29T22:55:02Z |

Hi,

I am currently trying to reconcile an TAM account from ITIM admin console but ending up with an 'non-compliant' accounts warning message. It is observed that the ITAM 'cn' value is multivalued attribute.

<Message Id="{
 "status": "fail",
 "connectorname": "LDAPUserMod",
 "operation": "update",
 "exception": "javax.naming.directory.SchemaViolationException: [LDAP: error code 67 - Not Allowed On RDN]; remaining name 'cn=9bcde230-b53b-4df1-a06d-223b9473cb,ou=users,dc=com'",
 "message": "[LDAP: error code 67 - Not Allowed On RDN]",
 "class": "javax.naming.directory.SchemaViolationException"
}"><Token tokenValue="tamModify"/></Message>


Any help to get rid of these warning/failure messages would be appreciated.

Attachments

  • franzw
    franzw
    393 Posts

    Re: reconciling the multivalued CN attribute to TIM

    ‏2013-10-30T06:50:24Z  

    What you need is to look at you provisioning policy for the CN attribute. There seems to be difference between the policy there and what the adapter can correct. This is actually as far as I can see from your very sparse information as if your policy is trying to change the value from one to another - but you document shows that it tries to remove the value ?

    So  - what is the rules for CN in your setup ? What is the underlying ldap (AD, TDS) ?

    First you should get your provisioning policy aligned with your business requirements - then the cleanup of non-compliant account may be clearer (it is not clear to me at all what you are trying to do here business wise - technically I understand - but that is not enough).

    Why is the CN a UUID - this seems rather strange to me - if this is something that should be adopted I would expect the CN to be a real name. Or are you trying to have CN being both a name and a UUID - then you should create an allow entitlement that allows this.

    When your policies are right there may be some situation you may have to clean up in the target system because thyey are not correctable using the adapter functionality - but I doubt that is the case here...

    You may also want to study a little more about provisioning policy - so check out the  formal documentation here : http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.isim.doc_6.0/admin/cpt/cpt_ic_admin_provisionpolicy.htm

    HTH

    Regards

    Franz Wolfhagen

  • 312000
    312000
    8 Posts

    Re: reconciling the multivalued CN attribute to TIM

    ‏2013-10-31T00:01:43Z  
    • franzw
    • ‏2013-10-30T06:50:24Z

    What you need is to look at you provisioning policy for the CN attribute. There seems to be difference between the policy there and what the adapter can correct. This is actually as far as I can see from your very sparse information as if your policy is trying to change the value from one to another - but you document shows that it tries to remove the value ?

    So  - what is the rules for CN in your setup ? What is the underlying ldap (AD, TDS) ?

    First you should get your provisioning policy aligned with your business requirements - then the cleanup of non-compliant account may be clearer (it is not clear to me at all what you are trying to do here business wise - technically I understand - but that is not enough).

    Why is the CN a UUID - this seems rather strange to me - if this is something that should be adopted I would expect the CN to be a real name. Or are you trying to have CN being both a name and a UUID - then you should create an allow entitlement that allows this.

    When your policies are right there may be some situation you may have to clean up in the target system because thyey are not correctable using the adapter functionality - but I doubt that is the case here...

    You may also want to study a little more about provisioning policy - so check out the  formal documentation here : http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.isim.doc_6.0/admin/cpt/cpt_ic_admin_provisionpolicy.htm

    HTH

    Regards

    Franz Wolfhagen

    Hi Franz,

    Thanks for your quick response.
    Underlying ldap is TDS.. I 've checked the provisioning policy for TAM combo adapter and could see that the
    'eritamdn' is configured as "cn='+uniquenumber+',ou=users,dc=com"      - Ex: cn=78b4c871-0ba1-4a95-99b3-f584c36e205d,ou=users,dc=com
    'Full name' is configured as "subject.getProperty("cn");

    Also the 'EnforcementType' for 'eritamdn' and 'Full name' are Default and Mandatory respectively.

    With the above 'entitlement parameters', when provisioned the TAMId is looks as:

    pdadmin> user show Tedsrws24
    Login ID: Tedsrws24
    LDAP DN: cn=78b4c871-0ba1-4a95-99b3-f584c36e205d,ou=users,dc=com
    LDAP CN: firstname lastname
    LDAP SN: lastname
    Description: Test user
    Is SecUser: Yes
    Is GSO user: No
    Account valid: Yes
    Password valid: Yes

    When the reconciliation[against TAM combo service] is performed for the above user Id from ITIM admin console, the 'CN' is appearing as Non-compliant attribute as the 'CN' in TAM is multi-valued[with UniqueId , 'firstname lastname'] attribute and in TIM 'CN' is Full name'.

    Any thoughts to avoid the 'non-compliant' errors for 'CN' in above scenario?

    Attachments

  • franzw
    franzw
    393 Posts

    Re: reconciling the multivalued CN attribute to TIM

    ‏2013-10-31T06:48:09Z  
    • 312000
    • ‏2013-10-31T00:01:43Z

    Hi Franz,

    Thanks for your quick response.
    Underlying ldap is TDS.. I 've checked the provisioning policy for TAM combo adapter and could see that the
    'eritamdn' is configured as "cn='+uniquenumber+',ou=users,dc=com"      - Ex: cn=78b4c871-0ba1-4a95-99b3-f584c36e205d,ou=users,dc=com
    'Full name' is configured as "subject.getProperty("cn");

    Also the 'EnforcementType' for 'eritamdn' and 'Full name' are Default and Mandatory respectively.

    With the above 'entitlement parameters', when provisioned the TAMId is looks as:

    pdadmin> user show Tedsrws24
    Login ID: Tedsrws24
    LDAP DN: cn=78b4c871-0ba1-4a95-99b3-f584c36e205d,ou=users,dc=com
    LDAP CN: firstname lastname
    LDAP SN: lastname
    Description: Test user
    Is SecUser: Yes
    Is GSO user: No
    Account valid: Yes
    Password valid: Yes

    When the reconciliation[against TAM combo service] is performed for the above user Id from ITIM admin console, the 'CN' is appearing as Non-compliant attribute as the 'CN' in TAM is multi-valued[with UniqueId , 'firstname lastname'] attribute and in TIM 'CN' is Full name'.

    Any thoughts to avoid the 'non-compliant' errors for 'CN' in above scenario?

    If you setup the DN to be "cn='+uniquenumber+',ou=users,dc=com" and cn to be "subject.getProperty("cn");" you will get into trouble.

    Basically you can solve this in 2 ways which is quite logically :

    1. Make cn consistent  with single value - e.g. use "cn='+subject.getProperty("cn")+',ou=users,dc=com" for dn and "subject.getProperty("cn");" for cn
    2. Make cn consistent with multivalue - e.g. use "cn='+uniquenumber+',ou=users,dc=com" for dn and "subject.getProperty("cn");" AND uniquenumber for cn - the 2 values for cn should both be mandatory.

    Anyhow - you will have a problem if you cn is not unique - this is a very common error when designing directories that the uniqueness of the rdn is not ensured (internally in IBM this is the case for our Domino directory).

    In general you should add something to the cn that makes it unique or use e.g. uid (assuming that your userid is unique). Many customers are using the combination of cn + userid to ensure uniqueness - e.g. "John Doe - JD1"

    HTH

    Regards

    Franz Wolfhagen

  • goonitsupport
    goonitsupport
    117 Posts

    Re: reconciling the multivalued CN attribute to TIM

    ‏2013-11-03T08:36:13Z  
    • franzw
    • ‏2013-10-31T06:48:09Z

    If you setup the DN to be "cn='+uniquenumber+',ou=users,dc=com" and cn to be "subject.getProperty("cn");" you will get into trouble.

    Basically you can solve this in 2 ways which is quite logically :

    1. Make cn consistent  with single value - e.g. use "cn='+subject.getProperty("cn")+',ou=users,dc=com" for dn and "subject.getProperty("cn");" for cn
    2. Make cn consistent with multivalue - e.g. use "cn='+uniquenumber+',ou=users,dc=com" for dn and "subject.getProperty("cn");" AND uniquenumber for cn - the 2 values for cn should both be mandatory.

    Anyhow - you will have a problem if you cn is not unique - this is a very common error when designing directories that the uniqueness of the rdn is not ensured (internally in IBM this is the case for our Domino directory).

    In general you should add something to the cn that makes it unique or use e.g. uid (assuming that your userid is unique). Many customers are using the combination of cn + userid to ensure uniqueness - e.g. "John Doe - JD1"

    HTH

    Regards

    Franz Wolfhagen

    I think the best advice here is not to use cn in the distinguished name for users (ok for groups perhaps).

    I typically use uid in the dn but you could extend the schema in your case with a new attribute e.g. uuid.