When you get the AD adapter installed and configured the first time you recon the AD all the groups from your AD will be imported into the TIM LDAP in the container defined for the AD Service you created. If you export one of these group objects from the TIM LDAP it would look something like my AD Domain Users group here:
dn: eradgroupguid=5fcbe38c66d1f343b7572848a642a8e9, erglobalid=77847836466036
35175, ou=services, erglobalid=00000000000000000000, ou=CA, dc=ca,dc=com
eradgroupguid: 5fcbe38c66d1f343b7572848a642a8e9
objectclass: erADGroup
objectclass: erManagedItem
objectclass: top
description: All domain users
eradprimarygrptkn: 513
eradgroupcn: Domain Users
eradgroupdn: CN=Domain Users,CN=Users,DC=CA,DC=local
So on the entitlement -> Advanced Provisioning Parameters you will need to add some JavaScript which will look up the GUID for the group or groups you want your user to belong to when provisioned to AD. Also, the Primary Group uses a Token represented in TIM by the eradprimarygrprkn attribute. One way to cheat here is to use the standard view of the provisioning parameters and use the search button to find the groups you want. Then switch to the advanced provisioning parameters view and you will see the GUIDs for the groups you chose:
Click on the screen shot to see a larger view.
The installation and configuration guide mentions that you can set certain Windows registry keys that will change the behavior of the adapter. One of these options is the useGroupCN setting. If you set this to true then you can reference the common name of the group in your provisioning parameters. This option may make it a bit easier for scripting.
I'm still having some issues with the Home Directory behavior, but I think the key to that is also in part how I set these registry configurations in the AD adapter. So far though, I have the AD adapter working pretty well in my sandbox system.
6 comments:
Hi charles
Can you please provide me with the javascript to do this. We tried with the userGroupCN attribute using AD Agent 4.6.1 and Tivoli 4.6 but it dint work. Infact the agent dint have an attribute called userGroupCN and we had to create it explicitly.
Regards,
Sairam
You would need to use newer AD Agent. I have it working with 4.6.12.
Please refer URL below for details
http://www-1.ibm.com/support/docview.wss?uid=swg21246156&aid=58
Once this is enabled, you could just refer the Groups just by the Names.
I am consulting at a client doing some Identity mapping. They have TIM Tivoli which has AD data already in it. I need to pull their usernames (eruid), employeeIDs (eradEmployeeID) from objectclass eradaccount (AD stuff), I also have to get their email accounts (which are under a custom objectClass (did not come from AD originally). I was trying to write a VBScript to pull everything. But Unfortunately all the code that's out there on the web is very AD specific (AD Provider, adspath etc) and so far I am not able to properly run a query from a script to hit LDAP. Do you have any idea how I can do this?
Yes TIM is quite a "bear" when you try to dig into it. It's not usually a good idea to interact with TIM at the DB2 layer except for maybe doing some historical reporting against the transaction database. Talking to the LDAP DB2 directly is dangerous. If you are looking to read data you could make LDAP calls to get what it is you need or you can write a web service to talk to TIM via the Tivoli API's. All the Tivoli Java Docs are available on the TIM server under /opt/itim/extensions/examples. If you need to just read some attributes then LDAP calls would be easier.
Also, TIM comes with TDI which is a very powerful tool for moving data around. You could leverage that as well. Chances are if they are running TIM then they have licenses for TDI and this is a very easy tool to run from your desktop or server. It has many connectors already built for LDAP, JDBC, file system connectors with built-in parsers, and much more. You can code JavaScript in that tool to pull data very easily from one system to another.
BTW, TIM comes with connectors to Peoplesoft, so you could integrate Peoplesoft directly with TIM or you could be using TDI to connect the two. I'm not sure what data your trying to move from where to where.
To see what's under the hood in TIM, you will need access to login to the TIM LDAP and point an LDAP Client at the TIM Box. There are TIM Identities (TIM Profiles) which are the Persons in the TIM System. These reside in a subtree like the following:
ou=people,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
There will be another entry for each person's accounts under the following subtree:
ou=0,ou=accounts,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
In this subtree you will find all the user accounts which are linked to the account owner. So the owner attribute for each account references the DN value for the TIM Person who owns that account. All the attributes for an AD user would be contained in the AD account entry for that use. See for example the following LDIF for an AD account on my test system:
dn: erglobalid=6796497576162093792,ou=0,ou=accounts,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
owner: erglobalid=3423009676372459862,ou=0,ou=people,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
eradrequireuniquepassword: false
givenname: Kai
eradnochangepassword: false
erprofile: \\Ad1\Users\KZhao
eradwtsallowlogon: true
ercreatedate: 200802280434Z
objectclass: top
objectclass: erADAccount
objectclass: erManagedItem
objectclass: erAccountItem
mail: kzhao@xyz.xyz
cn: Kai Zhao
eraddialincallback: 4
eradwtsclientdrives: false
erparent: erglobalid=3423009676372459862,ou=0,ou=people,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
erglobalid: 6796497576162093792
eradhomedir: \\Ad1\Users\KZhao
eruid: KZhao
eradpasswordrequired: false
postexec: md \\Ad1\Users\KZhao\notes\data
eradhomedirdrive: "H:"
eradprimarygroup: 513
eradallowencryptedpassword: false
eradwtsclientprinters: false
eradpasswordforcechange: false
eradallowdialin: false
eraccountstatus: 0
eradsmartcardrequired: false
sn: Zhao
ergroup: Domain Users
ergroup: Remote Desktop Users
eradpasswordneverexpires: false
eradwtsinheritinitialprog: false
eradisaccountlocked: false
erservice: erglobalid=3765903646723516930,ou=services,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
eradwtsclientdefaultprinter: false
erlastcertifieddate: 200803111907Z
erlastrecertificationaction: CERTIFIED
erhistoricalpassword:: AEVTSEEtMjU2Ok1XNXpiMk4yY3pKbWJXRnU6MWpNVUdyQTRpSWxYcmVxemFQMDU3d2FMbzcxZG1j
dEpNcEZTNDgxYkswYz1TSEEtMjU2OmFISmliRFU1WW1OdVozVnk6YWNkV2xoNHVPRHVUaTZJQjFT
REtpOXFRRWpYazdId013Q3hmRXNEV1hQND0=
erhistoricalpassword: ESHA-256:NzZ5eHU2eWc5OW85:1FBBQ+JpFWyNXsPJiumBchKB+Jmdv0NkRgJ4OdvvmLk=SHA-256:azBuempwMWJ1djE2:mvdGAbIXAPNP13u/tj0vw6/IAmhMxFshZGBkh4dzM5c=
erpswdlastchanged: 200803111912Z
Hope this helps.
Regards,
Charles
Can anyone recommend the well-priced Network Management utility for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: [url=http://www.n-able.com] N-able N-central remote pc access
[/url] ? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!
We are currently on 4.6 and will be upgrading to 5.1 in a few months.
It seems we always have issues with password syncing. One reason is the issue you mentioned in your blog about different password requirements in downstream systems.
Also, we have AD Password complexity turned on. We have users who use the CTRL-ALT-DELETE option to change their password and they can change their password without adding the required special characters.
Short story, do you know if there have been any improvements to the reverse sync in ITIM 5.1 when AD Complexity is turned on?
Also, if ITIM's password requirements are stronger than AD's password complexity rules, does it fall under "So it is important that there are no systems being managed by ITIM which more restrictive password policies than your AD password policy. Otherwise users in AD will set their password to something that passes the AD checks and fails when ITIM tries to sync that password to other systems."
Any info you could provide would be greatly appreciated.
Thank you.
Post a Comment