Hi, I have another question where I'm stuck today. Still within a forest with 7 domains, I wnat to ensure that samAccountName is unique accross the forest. Users will be created through FIM Portal. Therefore I can ensure that AccountName is Unique. but what if an admin creates a user through a MMC? I can't prevent it, but I can create an inbound synchronization rule and trigger a workflow that would verify that the samAccountName (mapped to AccountName) is unique and send a mail to an admin of the source domain if this is not the case. Do you have an example that could help me put in place this? Regards, Emmanuel Dreux. Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

We have trimed down to 5 domains from 14 here, and have a similar problem. we allow for sub delegation, so we have a lot of admins that are capable of creating user accounts. One thing that we did was create a "seperate" UPN Extension and educated the admins to use that. Although you can have a samaccount name reused in the domains, the ADUC balks if the UPN isn't unique (you can still set it programically). It also allows for our users to login with their username@ABC.COM which makes it easier as the accounts move cross domains, as their same login works.

Well the problem is that when you import that user which was created in AD, if there's a conflict the request to create it in the FIM portal will fail which means you won't be able to trigger a workflow. IMO you have a business process problem here int aht people are allowed to create accounts outside of the process.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

There is a solution in place that is using MIIS (ILM) to provision an ADAM partition. There are domains and administrators all around the world. It sometimes happens that 2 administrators create the same samAccountName in their respective domain. MIIS generates reports errors and send them back to the administrator of the source domain. This solution is being replaced by FIM 2010 and since the portal will be put in place for different needs (password reset, self service, white pages...), it will also be proposed as a solution to create user accounts but it will not become mandatory to use it. At minimum we must stay isoperimeter. The old platform was able to detect the duplicate account (trivial in the provisionning code) and FIM 2010 MUST offer the same functionnality. So according to you, there is no way, tip or trick to achieve this? Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

There is a solution in place that is using MIIS (ILM) to provision an ADAM partition. There are domains and administrators all around the world. It sometimes happens that 2 administrators create the same samAccountName in their respective domain. MIIS generates reports errors and send them back to the administrator of the source domain. This solution is being replaced by FIM 2010 and since the portal will be put in place for different needs (password reset, self service, white pages...), it will also be proposed as a solution to create user accounts but it will not become mandatory to use it. At minimum we must stay isoperimeter. The old platform was able to detect the duplicate account (trivial in the provisionning code) and FIM 2010 MUST offer the same functionnality. So according to you, there is no way, tip or trick to achieve this? Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

Here is a summary of the other issues we are getting. Environment: 7 domains in the same forest. Several Offices/countries without administrators (too small). Specific users are given delegation to create users in specific OU. The company has 70 000+ users but the perimeter of this project affects only 5000 users. An AD domain contains several brands, and brands are present in different countries. Requirement: - Build a FIM portal for theses administrators. (+ self service for users and white pages, these parts are ok). Issue 1: Generate a SET of administrators by domain. --> Not possible to transform the existing AD group containing the correct users into dynamic sets. --> Sets will have to be populated manually; alternatively, an attribute could be flagged in order to build a query to generate dynamically the set. --> Then expose this attribute for creation/ modification in the portal so that local "admins" can maintain their list of admins through this attribute (and of course prevent them to become "admin" of another domain. Strong security isn't it?) Issue 2: Password reset portal not localized. --> 5000 users around the planet with several differents and independant administration teams, different companies belonging to the group. --> Attribute country is not filled everywhere (33% missing). --> No way to generate a set of users language by language. --> Cannot be corrected. --> There are existing AD groups containing the correct population but they cannot be used by FIM Issue 3: Helpdesk cannot reset passwords. --> There have been some discussions here explaining that this was not a valid scenario anymore because users can reset themself their passwords. --> Interesting but not realistic: In the group, not all admin team will decid to deploy the FIM password reset tool on te laptops. Some installation will fail. Remote/home users without the reset tool will call the helpdesk. etc etc. If we put in helpdesk hands this functionnality and that often at the beginning they have to go back to their current administration tool, they will quickly abandon the FIM portal and it will not be adopted by the IT team. Issue 4: Duplicate entries. This thread. The customer had very high expectations when he bought this FIM deployment project. One after the other, we cannot achieve his (basic) requirements. One more for example: Issue 5: Select target OU for provisionning. Currently, users can be provisionned in different OU (one OU per Brand). So, we have exposed a new field in the portal and the "admin" selects the target OU where he is willing to create the user. The list comes from a regex of the attribute created in the FIM schema. That works great, but when the customer saw this solutions, his first reaction was to say: "What? this is hardcoded? If I create a new OU, I have to call you back to modify the portal?" He's right, it reminds me my first days in developpement where I was hardcoding values every 2 lines. All these issues turn more or less around the quality of data. The AD are not 100% correctly filled and it is not possible to generate the SETs containing the right population. Alternatively AD groups could have been used... but not by FIM 2010 which cannot apply MPR on AD groups or generate sets from AD groups. The company is an agglomerate of hundreds of brands belonging to dozen of different companies. All of them are IT independant even if some have accepted to share an AD. It is not realistic to ask them to correct the attribute values of the users in their scope and no governance can force them to achieve this. They are completely autonomous... and powerful. We are really looking for technical solutions, FIM has to adapt to the environment, there is no luck that the contrary happens :-).Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

#1 and #2 are the same issue. You want to populate a set using group membership. You can do this in attribute flow or in custom workflow. Simply grab all the members of the groups and put them into the manually-managed membership of the set. -JeremyJeremy Palenchar

#1 and #2 are the same issue. You want to populate a set using group membership. You can do this in attribute flow or in custom workflow. Simply grab all the members of the groups and put them into the manually-managed membership of the set. -JeremyJeremy Palenchar

On Thu, 5 May 2011 22:35:16 +0000, ilinfo [MVP] wrote: All these issues turn more or less around the quality of data. You really should start a new thread for each of your concerns. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Shift to the left! Shift to the right! Pop up, push down, byte, byte, byte!

Hi There, I've dealt with a similar issue and admittedly built a tracking database of the sAMAccountName information that was searched upon the FIM Portal trying to create a new identity or a new AD Account came in as a disconnector where I used the connector filter to determine whether or not the name was unique. In the case of the portal, FIM would search the database when it generated the login ID. If it was determined to be unique, it would write it into the database thereby saying it was in use. In the case of the AD MAs, the connector filter was used to search the database for any disconnected objects (regardless of whether they were new or not) and if the value was unique, the object could be projected and in the projection code, it pushed the sAMAccountName value into the database for that object. The "failsafe" was that I also pushed in the ObjectGUID in AD (when one was present) so that I had something that I could validate with in "rebuild" situations. Initial population of the database can be a concern though as you have to assume the uniqueness has been maintained across the environments already. So if you synchronize Domain 1 which has 5 duplicates with Domain 2, then the errors would be thrown when you synchronize domain 2. (A bit of a chicken and egg problem but once the data is in place, it should be reliable for 99.9% of the situations except for additions that occured simultaneously in two domains or in FIM). Thanks B

Thanks Blain for your suggestion. When a user is created in the FIM Portal,I'll use the RCDC approach of using UniquenessValidationXPath for AccountName. When a user is created directly in an AD, I will use a standard "MIIS" approach. Source ADs should never project nor join if the portal is the only entry point. I will allow projections and block joins: If a join is ready to occur, this will mean that it's a duplicate. I will block it in ResolveJoinSearch and log the entry into a file/database. One report will be generated for each source and sent to the administrators of the source at the end of the scheduled synchronization script.Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

Hi There, I've dealt with a similar issue and admittedly built a tracking database of the sAMAccountName information that was searched upon the FIM Portal trying to create a new identity or a new AD Account came in as a disconnector where I used the connector filter to determine whether or not the name was unique. In the case of the portal, FIM would search the database when it generated the login ID. If it was determined to be unique, it would write it into the database thereby saying it was in use. In the case of the AD MAs, the connector filter was used to search the database for any disconnected objects (regardless of whether they were new or not) and if the value was unique, the object could be projected and in the projection code, it pushed the sAMAccountName value into the database for that object. The "failsafe" was that I also pushed in the ObjectGUID in AD (when one was present) so that I had something that I could validate with in "rebuild" situations. Initial population of the database can be a concern though as you have to assume the uniqueness has been maintained across the environments already. So if you synchronize Domain 1 which has 5 duplicates with Domain 2, then the errors would be thrown when you synchronize domain 2. (A bit of a chicken and egg problem but once the data is in place, it should be reliable for 99.9% of the situations except for additions that occured simultaneously in two domains or in FIM). Thanks B

I question the design decision that AD will never join (what happens if you rebuild your metaverse?), BUT if that is the case and you can assume that any disconnected users in AD are not ever to join to a user created in the FIM Portal, then you could extend your MV and FIM Portal schemas to include another object type and project non-FIM-Portal-Created users into the Metaverse and provision to the portal as that type. Then you can create a set that includes users of the secondary type... trigger an MPR on that set that has a workflow which checks for the uniqueness of the account name, sending a notification any time a duplicate is encountered. And, then in your UniquenessValidationXPath statement for create user you just need to ensure that the other object type is included in the scope. Done this way, you can ensure that your non-FIM-Portal-Created-Users can't be edited via the FIM Portal and that also, importantly, that new users created via the FIM Portal don't conflict with manually created users that already exist. Unless I'm missing something, that sounds like it might work for you? - Ross Currie

Interresting approach. But the manually created user has to be/become managed as well by the portal. This answer is also for Brian who wrote : "IMO you have a business process problem here in that people are allowed to create accounts outside of the process." Doing MIIS projects for years, we have always taken the assumption that an administrator must be able to do his work even if MIIS (and now FIM Portal) is unavailable. That is, if MIIS is KO and cannot provision a target, an administrator must be able to create an account manually in a target in order to handle urgent issues (give access to a financial application immediatly for example). When MIIS is back and executes MAs, everything gets joined and provisionned correctly. Same for the portal. If for any reason it's unavaible, an admin can use his standard mmc, script or tool and create an account out of the the portal/miis. Second reason, in the worldwide deployment, the adoption of the solution by local admins, helpdesks and delegated users will take a long time over which there will be a coexistance of new and former administration solutions during a few months.Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

Interresting approach. But the manually created user has to be/become managed as well by the portal. This answer is also for Brian who wrote : "IMO you have a business process problem here in that people are allowed to create accounts outside of the process." Doing MIIS projects for years, we have always taken the assumption that an administrator must be able to do his work even if MIIS (and now FIM Portal) is unavailable. That is, if MIIS is KO and cannot provision a target, an administrator must be able to create an account manually in a target in order to handle urgent issues (give access to a financial application immediatly for example). When MIIS is back and executes MAs, everything gets joined and provisionned correctly. Same for the portal. If for any reason it's unavaible, an admin can use his standard mmc, script or tool and create an account out of the the portal/miis. Second reason, in the worldwide deployment, the adoption of the solution by local admins, helpdesks and delegated users will take a long time over which there will be a coexistance of new and former administration solutions during a few months.Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

But the manually created user has to be/become managed as well by the portal. Okay, so then it would probably be easiest to keep them as the same object. In this case, I would recommend doing this: - Have no joins between AD and the MV. Project only (this is as per your description above) - Provision these users to the FIM MA - Add a new attribute to your FIM Portal schema called "accountNameIsUnique" - Create a set of users where the value is not set, create an MPR that triggers on that set, create a workflow that populates that attribute. Ie, when a new user comes into the FIM Portal, they should be checked for unique account name and if it is, that value is set. If it's not, an e-mail notification is sent. Then you have two options... 1) You could leave users so that they can be managed by the FIM Portal, even while their accountname is duplicate 2) You can make it so that these 'duplicate' accounts can't be managed until their account name is fixed (which is what would happen if you block the join). So, update your user default search scope to only include users that have "accountNameIsUnique" set. This way they won't show up in the users panel until the issue is fixed. Once fixed, the new sAMAccountName will flow through to the portal, the unique attribute will set, the user will get put in the correct set and they will show up in the user management space. Alternatively, you could even have a workflow which checks their account name for uniqueness, and if it's not unique, change it to one that is, and send it out to an admin via a notification. Of course that does mean the user won't know their account until the admin notifies them, so may be best if that step is done manually. How about that one? - Ross Currie

It's a good idea. I will try to implement that next time I visit my customer in 2 weeks. Thank you very much for this suggestion. I'm also delivering a training on FIM 2010 in June and will include this a lab. This will be a good example for demonstrating when and how a workflow can be used. Cordialement, Emmanuel Dreux http://www.bcpsoft.fr http://www.ilinfo.fr

Cool, good luck with it. Just as a side note, creating a set where a value is not present can be a bit tricky in FIM. Most of the posts I've seen about this refer to RC0/RC1... for RTM onwards it's a bit different. For your set, under advanced view / extended attributes, the XPath Filter should be something like this: /Person[not(starts-with(AccountName,'%'))] Essentially that reads as "Account name does not start with any value" - Ross Currie

Cool, good luck with it. Just as a side note, creating a set where a value is not present can be a bit tricky in FIM. Most of the posts I've seen about this refer to RC0/RC1... for RTM onwards it's a bit different. For your set, under advanced view / extended attributes, the XPath Filter should be something like this: /Person[not(starts-with(AccountName,'%'))] Essentially that reads as "Account name does not start with any value" - Ross Currie