Answered by:

possible to make deployable PoSh utility for FIM?

Question

First, let me say that I am a complete and total noob with regards to FIM or any identity management solution. I'm a secondary AD administrator that would like to build a PowerShell script to allow me to more easily and quickly manage AD security
group memberships without having to go through the FIM portal.

The answer to my first question may negate my other ones:

Is it possible for a user who has permission to change security group membership via the FIM portal to manipulate said security group via PowerShell from an ordinary domain-joined workstation?

How might one do that? I'm not asking for someone to write a functioning script (though I won't complain if they do!), but I can see from
here that it should be possible in certain situations. However, it seems to require the FIMAutomation snapin which requires the FIMAutomation class be registered. After following info
here on doing that, I am still getting errors related to "Microsoft.ResourceManagement, Version=4.0.2592.0 or one of it's dependancies. I have also found
this, but I don't have Visual Studio (and don't really want it either - I'm not a developer, just a script writer/administrator).

What is the bare minimum required on a workstation to do the above? I'd love to be able to use (or have others use) this, but if I have to install Visual Studio and FIM components, it's not worth it.

If I'm simply barking up the wrong tree because I have no concept of how Identity management works, please let me know that.

In either case, I would love some pointers toward understanding how FIM works on the surface without needing to understand all the administration/setup/configuration parts -- kind of a "technical managers guide" -- if anyone can make suggestions. Everything
I've been finding either jumps right into the depths of jargon hell, or wants to walk me through a full test configuration (requireing SQL server, and a FIM installation) so I can play with it

I have been using a handy Powershell script myself and offering it to others (who really like it) that uses the already delegated permissions on AD groups for managers to make membership changes (and list imports and exports) easily without the complexity
of the MMC.

I've been informed that any AD objects controlled by FIM can't be (permenantly) changed outside of FIM, and thus any changes made in AD (like with my Powershell script) will be quickly overridden by FIM when it synchronizes. Frankly, the FIM portal
really stinks for any kind of power user (not to mention being IE only). It's like the Exchange web interface; Handy to have available for when you are away from your machine and adequate for basic users, but any serious user knows to use Outlook.
The problem is that apparently, FIM doesn't have a stand-alone interface (at least for users -- I have to assume FIM admins have something).

I am here because I would like to modify (or create anew) the Powershell script to work with FIM. I suppose if someone here can correct my understanding regardig FIM and AD synchronization, that would be very helpful too.

So: Do changes made in FIM automatically override changes made in AD? If so, is there a way for users not on the FIM console to manipulate objects in FIM via powershell?

If you have equal precedence on the membership attribute of the group so changes made in either FIM or AD are authoritative, you can continue using your powershell script. Any decent FIM person will tell you that's not sustainable in the long run.
Once you go down the FIM rabbit hole, you need to be prepared to have it be authoritative for as much as possible.

You can use the powershell scripts in conjunction with the FIMAutomation snapins to continue letting the managers do changes, but to FIM will the changes be made...not AD itself...for that FIM does it in sync a little later. I do not recommend this.
It's a whole lot easier to let the group "owners" learn the FIM portal and do the changes there than any script anyone could ever write. Truly. Everybody is familiar with web interfaces like FIM.

It is, however, recommended to use the powershell scripts with the snapins for the admins to make certain bulk changes to groups and users....for that purpose, they are generally very helpful.

I saw in the link Cameron offered the info on equal precendence and thought it was a great solution. Could you describe more why "Any decent FIM person will tell you that's not sustainable in the long run."? I can't imagine it is a technical
problem.

Assuming it's an organizational issue, I can certainly understand why the attributes on user accounts should be authoritative. However, I don't understand why if FIM allows changes to group memberships based on AD permissions anyway (which is how
I read Cameron's post), why group membership being authoritative (via FIM) makes a difference. If only certain people have rights to change group membership, what does it matter which method they use to do so?

I'm not trying to argue as I have no ID management experience. I'm just trying to understand so I can argue (or refrain) a case for equal precidence (for specific attributes) with the FIM administrators.

I previously found a half-dozen or so projects on CodePlex related to FIM, but I wasn't sure what their status was and didn't realize any were associated with Quest. I've really liked the Quest AD tools, so I expect they have a nice product.
However, the project you pointed to is "Alpha" and hasn't been updated/changed in 2.5+ years. This is well before Dell purchased Quest, so I don't have much hope for any changes.

I'd like to find some way to interact with FIM (if necessary -- see my post to GDlighman) via Powershell that doesn't rely on third-party software (especially abandonware) even if it is OSS as I'm not a developer.

I would expect this to be do-able through the FIM web service interface, but bear in mind it will be fairly complicated--you'd have to figure out the FIM ResourceID of the user and of the group, and then
submit a workflow request to update the group membership.

From a developer's perspective, the information around FIM's web services is a little thin.

Craig: Thanks for the suggestion. It looks like you did some nice work there with the FIM PoSh module.

Unfortunately, it's not quite as easy and you make it seem to get the FIMAutomator snap-in working. I have it registered, and I can add it into PowerShell, but any time I try to use one of it's cmdlets, I get something like:

Export-FIMConfig : Could not load file or assembly 'Microsoft.ResourceManagement, Version=4.0.2592.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

I doubt very highly that I will be allowed to hit the FIM server with any kind of remote scripting functions, so if someone can explain how to get the FIMAutomator snap-in working on my (and others') machine, I think I would be OK.

However, at this point unless someone can explain why setting equal precendence is not a good solution, I'm leaning toward pushing heavily for that.

You're close, you just need to figure out which file is missing. The error message gives a pretty good clue, but there is actually another one. when I register the DLL I include all these files in the same folder:

Microsoft.ResourceManagement.Automation.dll

Microsoft.ResourceManagement.Automation.dll-Help.xml

Microsoft.ResourceManagement.dll

Microsoft.IdentityManagement.Logging.dll

If you are allowed to perform an operation at the FIM Portal, then your permission should also work with the FIMAutomation PowerShell Snap-In because both are just clients of the FIM web services. Of course a determined FIM admin could restrict access
to the FIM web services ports (5725/5726) such that only the FIM Portal can call the FIM web service...

I saw in the link Cameron offered the info on equal precendence and thought it was a great solution. Could you describe more why "Any decent FIM person will tell you that's not sustainable in the long run."? I can't imagine it is a technical problem.

Assuming it's an organizational issue, I can certainly understand why the attributes on user accounts should be authoritative. However, I don't understand why if FIM allows changes to group memberships based on AD permissions anyway (which is how
I read Cameron's post), why group membership being authoritative (via FIM) makes a difference. If only certain people have rights to change group membership, what does it matter which method they use to do so?

I'm not trying to argue as I have no ID management experience. I'm just trying to understand so I can argue (or refrain) a case for equal precidence (for specific attributes) with the FIM administrators.

Thanks.

The argument is more organizational. It really all depends on if your admins are doing their job correctly or lazily. I.E....lets say the create a new user by copying another user from AD using ADUC....group membership copies with it,
but in the case of using FIM correctly and criteria basing groups, the admins will now have a manual membership to a group which was never supposed to have it. So....if you or someone is able to explain why things like that shouldn't happen and actually
get them to listen....by all means....go equal precedence on the attribs you need it.

HTTPS is only to SharePoint. SharePoint then communicates with the FIM Service on port 5725, as configured in the 'resourceManagementClient' section of SharePoint's web.config file.

So both SharePoint and PowerShell are talking to the FIM Service on the same port.

The beauty of Export-FimConfig is that it takes any XPath filter that FIM supports. To get more detail on FIM and XPath, search for those two works and you'll find the FIM XPath Filter Dialect on MSDN.

The beast of Export-FimConfig is that it CAN be slow for some queries because of the hard work it tries to do in chasing references. I almost always turn this off by using the -OnlyBaseResources switch parameter, but even then the command is still
sometimes slow, but I still use it a LOT. I've probably typed "Export-FimConfig -Only -Custom" more than anybody on this forum. There should be a prize for that ;-)

I tend to type it for ah-hoc queries when I'm messing around or troubleshooting. It's the lowest common denominator, except for the FIM web service itself. If something is broken I try to repro using Export-FimConfig or Import-FimConfig, then
I can rule out my scripts and focus on the FIM policy.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.