Provision shared folder for a user using FIM 2010
- Have been heavily using this forum for 2 weeks for now :) hope that I didn't bore anyone.
I would like to know how to use FIM 2010 to provision a shared folder for a user on a file server, shall I use visual studio and create a custom provisioning rule to execute the commands or how this could be done from the portal.
Thanks.
Regards, Mahmoud Magdy
All Replies
- Managing shares and ACLs is something FIM is not suited for.
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation - Hi Mahmoud!
I think it's a great idea handling user shares (not necessarily acl's) using FIM. I live in the happy world where we want as much administrative work as possible to be handled automatically. There's actually a third party MA for this made by Schakra , I have no details about it and haven't tried it.
It's important that the directory/share is created when the user already exists and this could be done using a custom workflow activity as well as an MA... Use existance test to make sure the user exist, check if the folder exist otherwise create it, set necessary folder ACL's, make it a share and set share ACL's. Of course you could handle shares during deprovisioning as well, for example remove the share, zip the whole folder and store it in a safe place.
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) - Hello Gents,
Sorry for the late reply, actually what Henrik and Lari posted is a mix of what I actually want, I am working in preparing a packaged solution over FIM where we will develop custom MA for most popular HR applications here in Egypt where we can use them with the HR application and provide automated provisioning for our customers.
I don't want to manage ACLs, I just want to create a folder for the user, what I am actually wondering can I use the FIM synch rules, attribute flow and my own DLL rule extenstions where I can provision the folders using .net funtions within that DLL.
Can I use the mix that mentioned above, My thought is using the regular data flow/sync rules, Then create a DLL where its called after the full export of the ADMA and then creates a folder for the provisioned user, can I do that?
sorry for the troubles.
Regards, Mahmoud Magdy - I think you should have a look on how to create XMA's , it's not that hard if you wish to go with the legacy or flow/sync rules or maybe have a look at the already available XMA's.
My solution for a legacy flow/sync rules scenario would be a custom call/file (you must create a textfile for confirming import of the folders you've created) based XMA that would handle the "path"-attribute for the user objects instead of filling the metaverse with custom folder objects and it would also take an attribute that's automatically set for users in AD, let's say ObjectGuid because when the ObjectGuid is set the user is created in AD and then it's alright to create the folder/share.
//Henrik
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) I will have a meeting with my dev team next week and hopefully we will be able to but all of those thoughts in a meaningful format, I am thinking about creating a MV rule extension that reads the MV attributes (for example login name) and creats a folder using it.
my concept is to create regular data flow and after the export completed and object is provisioned in AD I will read the flag that it has been exported and then initialize the dll that creates the folder for the user.
I will make my developers read the rule extension subs and hopefully we will be able to achieve it.
my last question is: can I mix using attribute flow (either old method or sync rules) with the dll calling, I mean if I will use DLL can I use it for shared folder creation only or I will have to build total data flow solution in the DLL if I will use the DLL.
Regards, Mahmoud Magdy- If one were to do this, then the dependent sync rules feature sure would come in handy. that way the user could be created before the FIM tried to create the folder.
CraigMartin – Oxford Computer Group – http://identitytrench.com - Hi Craig!
Couldn't you please give a short description on how dependent sync rule could help here? My thought was that detecting DRE's would be the optimal solution but this isn't very well documented and I haven't had time to dig deeper into this and the same goes for dependent sync rules even thought I've had plans for months now to try and describe how to solve this to the community but time is always an issue and I wish there were a place where you could buy some more. :-)
In my first answer on this thread I said existence test would be a way of solving this i.e. DRE's but for some reason I was recommending an XMA in my second answer, strange!
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) I will have a meeting with my dev team next week and hopefully we will be able to but all of those thoughts in a meaningful format, I am thinking about creating a MV rule extension that reads the MV attributes (for example login name) and creats a folder using it.
my concept is to create regular data flow and after the export completed and object is provisioned in AD I will read the flag that it has been exported and then initialize the dll that creates the folder for the user.
I will make my developers read the rule extension subs and hopefully we will be able to achieve it.
my last question is: can I mix using attribute flow (either old method or sync rules) with the dll calling, I mean if I will use DLL can I use it for shared folder creation only or I will have to build total data flow solution in the DLL if I will use the DLL.
Regards, Mahmoud Magdy
Mahmoud,
You will want to avoid any direct manipulation from the legacy rules extensions - that gets sticky and should be avoided. The recommendation to do this in an XMA is your best bet. Essentially you move the logic you are describing into the XMA such that it's performing these actions during an Export phase. This takes the interaction out of the Sync processing which can compromise your syncs and kill performance.
Craig's suggesstion to use the DRE feature is strongly recommended - as Henrik suggests, it's largely unexplored but would play a critical role in what you're suggesting as it solves one of the most important problems when doing this type of action - ensuring that the AD account already exists before you create the folder.
Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
You will want to avoid any direct manipulation from the legacy rules extensions - that gets sticky and should be avoided. The recommendation to do this in an XMA is your best bet. Essentially you move the logic you are describing into the XMA such that it's performing these actions during an Export phase. This takes the interaction out of the Sync processing which can compromise your syncs and kill performance.
Craig's suggesstion to use the DRE feature is strongly recommended - as Henrik suggests, it's largely unexplored but would play a critical role in what you're suggesting as it solves one of the most important problems when doing this type of action - ensuring that the AD account already exists before you create the folder.
This is correct.
A scenario like this should be implemented by using Object State Detection, which uses DREs as detection mechanism.
The development part in this scenario is related to a custom workflow.
Let me know if you need help with setting up OSD - it is very simple.
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation- Hi Markus!
Even thought this isn't my question I say... Yes please! As both me and Brad feels this is kind of unexplored and if it's that simple please give us a hint...
//Henrik
Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se) Hmmm, this means no more gambling for Brad at TEC since this topic has been part of my presentation :o)
The concept is simple; however, the explanation for the “how it works” part is a bit challenging.So, please let me know if you have questions when working with OSD.
That helps me to see where the obstacles are.
The first thing you need to understand is the difference between an attribute flow mapping and an actual attribute flow.What you do, when you configure something with attributes in a synchronization rule is to define attribute flow mappings.
An attribute flow mapping becomes an attribute flow when the flow mapping is applied by the synchronization rule.
The minimum requirements for DRL calculation process to work are an attribute flow mapping on the outbound side and an actual attribute flow on the inbound side.
A DRL entry is created (if it doesn’t exist yet) when the attribute values of the inbound attribute flow matches the values of the outbound attribute flow mapping.
As you can see, there is a comparison taking place. This comparison is also known as existence test.
You define your existence test in an outbound synchronization rule as a flag on an outbound flow mapping.
In an outbound synchronization rule, you can have one or more flow mappings (depending on your requirements) to define what your existence test.
If the existence test is positive, an entry is added to the DRL attribute of the affected object that eventually points to the outbound synchronization rule that has your existence test configured.
The second part you need to understand is the difference between a regular outbound synchronization rule and an operational outbound synchronization rule.
In a nutshell, an operational outbound synchronization rule is a synchronization rule that is NOT included in a workflow.
So, from an outbound perspective, this synchronization rule is never applied to an object – aka does never show up in an ERL.
When you look at the configuration, you will see why this is necessary.
About the configuration…
For this scenario, you need an inbound attribute flow for the AD GUID attribute.This attribute is the best indicator for an object that exists in AD.
In other words, if an AD object has a GUID, the GUID is a proof for the object to exist in AD.
I would extend the MV schema with something like “ADGuid” and configure an inbound flow mapping in an ISR like “objectGuid->ADGuid”.
As discussed, this is just one half of the existence test.
In addition to this, we need at least an attribute flow mapping in an OSR to do the existence test comparison.
To do so, configure an outbound operational outbound synchronization rule.
This means, configure an OSR that has next to the relationship criteria only one attribute flow mapping – “ADGuid -> objectGuid”.
Check this flow mapping off for an existence test.
As mentioned before, there is no need for a workflow or MPR – just the OSR.
My recommendation is to give the OSR a descriptive name – something like “Is AD user”.
Bring the ISR and the operational OSR into the MV.
Import an AD object into the AD connector space, and then run a synchronization on the ADMA.
At the end of the inbound synchronization phase on the ADMA, the existence test is applied.
In this case, the attribute values of the GUID from “objectGUID->ADGuid” are compared with “ADGuid->objectGuid”.
Since they match, the existence test is positive, and the DRL of your object is in the metaverse populated with “Is AD user”.
At this point, you have successfully implemented an OSD that detects existing users in AD, which is a requirement for kicking off the process of creating something like a home directory.
Does this make sense so far?
This is a perfect example for why you can’t use walkthroughs to learn how something works.
If you look at our configuration, you will probably agree that it is very simple.
However, you can do more complex things with OSD – our requirement to detect an existing AD account is just not very challenging.
As soon as this part is understood, I will explain how to get the DRL information into a Set.
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation- One way I have been doing it since the MIIS days, is to just have an import flow setup on AD for the dn attribute which flows to the metaverse, I usually name it existsAD.
When this attribute is flowed to the metaverse you can kick off provisioning code to create an object in the connectorspace.
This can still be used if you do not want to use codeless and is alot easier to do.
If you want to use the this for sometype of workflow, then using Sync Rules ex. Codeless.. then that is the way to go..
The xMA for Share provisioning is the optimal approach and is nothing new. I have been doing it for homedirectories since the MIIS days.. Should be no different for provisioning shares. One thing to watch out is for permissions, but this can be solved by setting the top folder to the appropriate permissions.. Also look into using Impersonation, so you don't give permissions to the ILM service account to create the permissions.
I plan on releasing a home directory ma as one big release for the ILM "X" Framework, releases have been slow, since I have been so busy.. But plan on having tons of new features.
HTH,
Joe
Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com Hi Joe,
the DN is not really a good attribute for this since objects are moved in AD, which results in an update of the DN.
The DN attribute fires on each move from one OU to another.
The GUID is much better suited for this as long as moving security principles does not require a move of the home directory.I doubt a bit that using an operational MA is a good idea in the FIM timeframe.
While what "simpler" means is always debatable, I would really challenge you on this - especially regarding the "optimal approach" statement, which is in my opinion not true.Operational MAs have always been a workaround for “out-of-band processing” since there was no better mechanism in ILM.
With OSD and a custom workflow, you have a more appropriate implementation for these tasks that doesn’t require the management of an additional MA.Operational MAs are adding a lot of overhead to the operational management of an environment.
There is for one the management of the additional MAs and also the dependencies you have in conjunction with run profile runs.This is all gone with declarative provisioning.
There is no need for additional MAs and no need to worry about run profiles orders.
The workflow that takes care of the out-of-band processing tasks is triggered based on the regular run profile sequence.My description might sound a bit complicated since I tried to sneak in the “how it works” into the description.
From the configuration perspective, there it is awfully simple.So, in essence, I disagree with your statement that operational management agents represent an “optimal approach” for out-of-band processing.
With OSD, you have an unified mechanism that is easy to implement and does only require some coding on the workflow side.Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation- Hi Markus,
I really don't agree with the DN not being a good attribute, if you define it for existing... It won't do much harm.
One thing that tends to bother me about workflow or transactional processing compared to state-based is what happens when someone deletes the share? Are you going to go back and check with the workflow??? How would the workflow know??
Thats where the operational ma would be the better approach.. Now if you want to set it and forget it, then I think the workflow based solution would be the optimal.
It's really all in the design of the operational ma and what dependencies you create. It would seem to me that there are quite a bit of dependencies when you are using the DRE logic... Alot of things have to be working correctly for it to work also.
When it comes down to it.. I think either side would win.. but it really comes down to what you want to do.
Honestly I think workflow is probably the best addition to ILM and has been needed for quite a while..
I have done a bunch of integration with other workflow products and as a whole it makes ILM quite the beast and makes insanely powerful.
The workflow vs state-based debate will be an ongoing issue and I think there should be some type of best practices document around it... When to use the sync engine and when to use workflow... would be a great doc....
Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com - Thanks for the awesome explanation but isn't it easier than this?
IIRC from my lab environment I only really had to mark one rule as dependant on the other. So in this example I would mark the "Provision to the Home Folder XMA" OSR as dependant on the "Provision to the ADMA" OSR. When I made this simple configuration I noticed the "Provision to the Home Folder XMA" rule wouldn't fire until after the "Provision to the ADMA" rule completed.
CraigMartin – Edgile, Inc. – http://identitytrench.com Thanks, Joe.
I really don't agree with the DN not being a good attribute, if you define it for existing... It won't do much harm.
Define harm :o)
If your goal is to detect newly created accounts, the DN, samAccountName, userAccountControl and others can't do this because these attributes can also be just updated on existing objects.
If this doesn't bother you, fine; however, I'm more wondering why you wouldn't use the GUID since it does exactly what typically is required in these scenarios and it produces 0 harm...One thing that tends to bother me about workflow or transactional processing compared to state-based is what happens when someone deletes the share?
When someone deletes the share that has some X GB of work related data, you have a much bigger problem than getting "a" share back.
In this case, there is hopefully a backup strategy in place. From that perspective, I don't consider "deleted shares" to be part of the usual state based processing space.
One thing that would be interesting to know is how you actually detect that a share that should be there was deleted.
If you are using some code that periodically polls the file system, then what value does it add to FIM to feed the information into it.
I would be helpful if you could elaborate a bit further where you see a need for state-based processing in this scenario.It's really all in the design of the operational ma and what dependencies you create. It would seem to me that there are quite a bit of dependencies when you are using the DRE logic... Alot of things have to be working correctly for it to work also.
If this is your impression from my description, then please help me to get this fixed.
The opposite is actually true. There are no dependencies when using OSD, which is the beauty of this implementation.
The state detection is part of your regular runs between AD and FIM.
All, that needs to work is the elementary data exchange.
In essence, the implementation is very simple.
The only confusing part is in my opinion the fact that you need to configure an operational OSR, while there is no intention to flow anything out.
So, if my description is not good enough yet, then hopefully this statement is :o) - there are no dependencies using OSD other than that your basic FIM logic must be functional...
DREs are an elementary part of the FIM architecture. If the DREs don't work, FIM as such wouldn't work either; which means, you would have a bigger problem than OSD.
The workflow vs state-based debate will be an ongoing issue and I think there should be some type of best practices document around it... When to use the sync engine and when to use workflow... would be a great doc....
This is very true. However, before we can do this, we need to have more discussions like this.
For example, in conjunction with the current scenario, we will have to figure out whether "recreating a deleted home directory" represents a scenario that can / should be solved in a state-based manner.From my perspective, the home- directory scenario is a one-off scenario and operational MAs for one-off scenarios can be replaced by using an OSD solution.
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation- Thanks, Craig!
yep, you can use SR dependencies to prevent an SR from firing too early.
However, provisioning creates a connector in the AD CS.
At this point - even, if the "Provision to the ADMA" SR has been completed, it is way too early to create the home directory because the user doesn't exit yet in AD.
You can make the assumption that the next export won't fail; however, is this really good enough for an Enterprise environment?
If so - OK.
The idea of OSD is to make an implementation like this "waterproof".
For example, when you import a GUID value for an AD object, there is no doubt that the object exists.
So, with dependencies, you can prevent SRs from being applied too early.
However, from the fact that a SR has been applied, you don't know what the state of the object is <RIGHT NOW>.
You know that it will eventually converge but there are decisions that require the current state.
This is why DREs were included into the architecture.
From the collection of outbound flows you have configured in an OSR for a given system, there is typically only a subset for which you need a confirmation that convergence has been taken place and is active <RIGHT NOW>.
Also, OSD is a general purpose implementation.
What I mean is that you can use it to kickoff the home folder workflow as well as others - such as a workflow that sends an email to the new hire's manager.
You may need to detect other states.
For example, we have developed a solution to detect enabled/disabled users in AD, which is based on the same underlying concepts (e.g.: DREs).
This is why I suggest using a "meaningful" name for the operational OSR.
That way, you can in the simplest case get some state information just from looking at an object in FIM.
Last but not least, in ILM, we have typically only be interested that convergence takes place at some point, which was good enough.
With OSD, you can implement a convenient reporting mechanism you can use track down why a state was changed if this is necessary.
So, I think, it is important to highlight that you can use OSD as a unified detection / reaction mechanism.
Cheers,
Markus
Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
