I have been playing around with FIM and following some guides, and I was wondering the following: A) I know it's possible to flow certain values to the userAccountControl flag in Active Directory (like 512/514 for a normal/disabled account) and as such change the status of the account. Suppose you want to provide this functionallity to operators from the portal. What is the best way to trigger that attribute flow? Would it be nice to let the people managing the portal set an attribute like employstatus to "non-active" and based on some function (IIF) then flow the 514 value, or is there a "nicer" way? B) I know it's possible to provision your users by building up a nice DN and accountname. Suppose you have a user called "Robert Jordan" and you want RoJo001 to be used as his account name. A custom expression could be Left(givenName,2)+Left(sn,2)+001. Is their any way to trigger the 001 to be a counter in case the account name is already in use? Like say earlier a user was provision with the name Ron Johnson. Or does this kind of stuff really needs to be done through custom rule exentions (custom coding). Or is it impossible to perform some "uniqueness" checks from within the sync rules on the portal? Checking whether the name exists in the portal users or metaverse would actually be fine. Thnks for any feedback!

a) I've done a myself with an MPR that uses a set transition. Create a SET something like 'non-active', I've done this based on EmployeeType. I did this because Employeestatus is an attribute not available by default in portal and i had some trouble adding it and then populating it. I used a Transition in MPR, so it triggers when someone moves into the 'non active' set. Also create a workflow that you can attach to this MPR. The workflow could be an action workflow o the add type, connect that to a sync rule that you created for this that sets the useraccountcontrol to 514. I also added a new flow for DN to put a user in a different OU when he is disabled, but that doesnt work for me yet. If someone managing the portal had the rights to change someone's employeeType then this should work. Small note that I'm very new to all of this myself so there might be better ways. b) I've no experience with this, I would go around it by adding something like employeeID to the accountname, but mabe someone else can give you a real solution here

Hi Thomas. A: I think that your approach should be ok. Anyway, you should not use the hard-coded values 512 and 514, but rather set or unset the appropriate bit. Your expression should look like IIF( Eq(EmployeeStatus,"Disabled") , BitOr(2,userAccountControl) , BitAnd(-3,userAccountControl) ) -> userAccountControl Check this article for more details (and this discussion for the reason why 9223372036854775805 in the bit mask can be replaced with -3). B: you have to write a custom activity, there is no built-in functionality that allows you to create a unique account name. Check the document "Identity and Access Management Operations Guide", it is an excellent guide on how to write a custom activity (it was written for RC0, but it's still mostly valid). The Cortego ILM 2 Workflow Activity Library by Henrik Nilsson should contain an example of unique value creation. CheersPaolo Tedesco - http://cern.ch/idm

Robin, Thanks for your feedback. I think i can help somehow: If you want the "employeestatus" attribute to be available for the FIM Portal users, you should go to Administration - Schema Management, create a new attribute and then create a new binding between the user (resource) and employeestatus (attribute) If you want your users to be able to see it and edit it, you might have to add it to some MPRs which restrict access to attributes. In particular the "Administration: administrators can read and update users". If you want it then to show up in the "nice" user creation/editting wizards you have to edit the RCDC's, some intelligent copy paste should do the trick there. make sure to backup the original xmls you're changing... That should do the trick. For your "moving to a disabled ou". Make sure you have hierarchy provisioning (ou's) on, or that the OU exists. then it should be as easy as flowing the dn to the disabled ou's dn... good luck!

Thanks alot Paolo! That seems like a very decent place to start from. I'm still a bit wondering whether using the IIF statements in the regular attributeflow is to be preferred, or just use different sync rules and set transition MPRs. But I guess that depends on the complexity if the things needed to be achieved. regards, Thomas