none
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

    Thanks.

    Thursday, December 27, 2012 9:15 PM

Answers

All replies

  • I have one question to start... Is FIM already installed/configured in your environment?
    • The user may change things in the portal, but the AD service account is the one that updates the group memberships, ie has the permissions to modify groups in AD
    • Could you not just delegate control or use the AD powershell module (assuming Server 2008)
    • Powershell :) 

    It's worth reading through this to understand data synchronization. (but may not really be what your looking for)

    Thursday, December 27, 2012 11:39 PM
  • FIM is not quite in place yet, but it will be coming soon.

    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? 

    Thanks.

    Friday, December 28, 2012 4:04 PM
  • 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.

    Friday, December 28, 2012 8:45 PM
  • I recommend looking into the Quest Powershell Cmdlets (built off the public Resource Management Client on codeplex).

    I've personally taken a forked version, made some modifications and compiled a x86 installer.

    This DLL has the other dependent ones merged into it. It should work on an independent machine that can communicate to the FIM web services

    Modified Quest Client (x86)

    Friday, December 28, 2012 9:24 PM
  • gdilghman:  Thank you for the response. 

    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.

    Wednesday, January 02, 2013 5:41 PM
  • TUPS:  Thanks for pointing those out. 

    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.

    Thanks again.

    Wednesday, January 02, 2013 6:08 PM
  • 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.


    Steve Kradel, Zetetic LLC SMS OTP for FIM | Salesforce MA for FIM

    Wednesday, January 02, 2013 9:37 PM
  • Give this a look:

    http://fimpowershellmodule.codeplex.com/documentation

    It requires the FIMAutomation snap-in, but that is pretty easy to register on another machine using installutil.  Even better, leave it on the FIM box and hit it with WinRM.


    CraigMartin – Edgile, Inc. – http://identitytrench.com

    Wednesday, January 02, 2013 10:30 PM
  • 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.

    Thursday, January 03, 2013 4:09 PM
  • 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...


    CraigMartin – Edgile, Inc. – http://identitytrench.com

    Thursday, January 03, 2013 4:54 PM
  • RE: 

    gdilghman:  Thank you for the response. 

    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.


    • Edited by gdtilghman Thursday, January 03, 2013 4:59 PM
    Thursday, January 03, 2013 4:57 PM
  • Craig:  I got it to work!  Thanks. 

    I have a few questions that I don't think change the thread too much...

    I had to set the URI to HTTP as it wouldn't accept HTTPS and had to include the port.  The FIM Portal does use HTTPS, but doesn't require a port.  Doesn't that mean the scripted login is not secured?

    Is there a reference for the -CustomConfig string syntax?

    It's pretty slow (so far, I've only used the FIMAutomation directly).  Is the FIM PoSh module likely to make any speed difference?

    Thanks.

    Thursday, January 03, 2013 5:54 PM
  • Cool! 

    I think the admins here do things "correctly" to a fault.  They certainly don't take any shortcuts.  I suspect equal precedence won't be a problem (at least in the way you describe).

    Thanks for answering.

    Thursday, January 03, 2013 5:58 PM
  • 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 ;-) 


    CraigMartin – Edgile, Inc. – http://identitytrench.com

    Thursday, January 03, 2013 6:11 PM
  • Nice...I don't type it. :)  Its in EVERY script.
    Thursday, January 03, 2013 6:53 PM
  • 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.

    CraigMartin – Edgile, Inc. – http://identitytrench.com

    Thursday, January 03, 2013 7:26 PM