none
Detecting Non-Authoritative Accounts – Part 1: Envisioning RRS feed

  • General discussion

  •   Experts Corner Article

     

    Part2: Design

    When managing user objects with an identity management system, you typically have one or two authoritative data sources that own the source information about an object and at least one target system that is populated with the authoritative information.
    For example, you might want to implement a solution, in which FIM is authoritative for your user objects in Active Directory.
    In a scenario like this, it is not possible to prevent the local administrators in Active Directory from creating user accounts.
    In the context of our discussion, these accounts are also referred to as “non-authoritative” accounts.
    The question, your implementation needs to answer is, how you can detect non-authoritative accounts in your environment.

    At some point, Henrik Nilsson and I started a discussion about this problem.
    Initially, it felt like something that doesn’t take much time to be implemented; however, after spending more time on it, we found that a “good” implementation is not necessarily that straight-forward.
    Like in many cases, “the ideal” solution might in a real world environment be blocked by political issues, budget constraints or by missing features in the software used to implement the solution.

    The quick problem turned out to become a longer discussion and we thought it might be helpful to share our findings with the community.
    To makes this topic easier to digest, we decided to split it up into smaller pieces:

    1.  Envisioning
    2.  Design
    3.  Planning
    4.  Implementation
    5.  Lessons learned

    The first four building blocks represent the general structure you should use to address and hopefully solve a technical problem.
    In our little collection, we are using the 5th part to summarize what we have learned from working on this project.

    Our intention with this collection is not necessarily to give you a silver bullet for detecting non-authoritative accounts.
    While we hope that the content will help you to find a solution that works for you, the primary goal is actually to make a suggestion for how to address a technical problem like this and also to broaden the audience for discussing this problem.

    Developing a solution

    It is Monday morning, 9 AM, and your boss comes to your office.
    “We need a solution to detect and handle non-authoritative accounts.
    By Friday, I want to know, what we are doing to address this”.
    While fictitious, this scenario might sound familiar to you.
    You get an assignment, and you need to get the job done.
    But how?
    You can go to your keyboard and start implementing something.
    We suggest using a structured approach that will in the long run help you to build better solutions and to address some issues you might encounter while developing and implementing a solution.
    Going to your keyboard might not be a bad idea; however, instead of opening the FIM UI, you might want to start with getting your project documentation in place.
    Having a solid documentation of your project helps you to address several issues.
    First, you might have to engage others to help you with the development of the solution.
    To avoid repeating the same things over and over again and to make sure that all members of the project are on the same page, you should make sure that you are spending sufficient time on documenting your project.
    As soon as you involve others to help you, it is very helpful to have an overview of:

    • What the actual goal is
    • What you have already done
    • What issues you have identified
    • What the partial solutions are you have found

    It is important to note, that the development process is an iterative as of supposed to a sequential process.
    Based on the lessons learned, you will have to go back to previous phases and update the existing documentation according to new findings.

    Phase 1: Envisioning

    The objective of the envisioning phase is to make sure that the goal of your solution is defined as crisp as possible.
    You should always provide your design goal when looking for feedback from others.
    Without knowing what your actual design goal is, it is very hard (if not impossible) for others to give you meaningful feedback.
    The design goal should also include the known constraints.
    If you have budget and time constraints, a solution that would take years and millions of dollars to be implement will not help you.
    However, tracking a “silver bullet” solution in the envisioning phase is useful because it lets others know that you are aware of it.
    In addition to this, constraints can change over the time. “In 5 years from now”, the same problem might come up again and the constraints from today might be the no-brainers from tomorrow.
    Also, if you think too early about constraints in your implementation, you might block yourself on a level that will result in a less than optimal solution.
    It is advisable to use the “ideal world” perspective as a guiding principle for building a solution.
    This means, you start from the perspective of what you would do, if you wouldn’t have constraints, and then you incorporate them step-by-step into your development process.
    This is approach will typically help you to come up with the best solution in the context of your constraints.

    Initial Analysis

    The objective of FIM is to provide a central point of administration for distributed identities.
    One typical challenge of an identity management scenario is to aggregate the distributed parts of an identity into one logical view.
    In the FIM terminology, the aggregation process is also known as join.
    If you want to build “robust” or unambiguous joins, you need an identifier, also known as Correlation ID to do this.
    In the “Design Concepts for Correlating Digital Identities”, I have summarized the issues that are related to this problem space.
    You might wonder how a Correlation ID relates to the detection of non-authoritative accounts.
    If your objective is to manage Activate Directory with FIM and you want to detect non-authoritative accounts, you should have a special attribute on your AD object that can only be contributed by FIM.
    Having an attribute like this makes the detection of non-authoritative accounts very simple.
    The objective of this attribute is to indicate that an object with a populated attribute value is managed by FIM.
    However, most scenarios do not have such an attribute.
    Typically, the attributes that are published to a connected data source are only related to the object itself and don’t contain any information about the state of an object within the identity management process.
    Imagine, your Active Directory would have an attribute called FIMID, and the value of this attribute would be the GUID of the source object in the FIM data store.
    Having an attribute like this enables you to solve several issues.
    First, it would enable you to build robust joins in your environment.
    Second, the attribute gives you a simple mechanism to find the originating master object in the FIM data store.
    Last but not least, you can use this attribute to detect non-authoritative accounts.
    If a newly imported object has a GUID but no FIMID value, the object cannot be created by FIM.
    With the FIMID, we could quickly close this case.

    If possible, you should spend some time on investigating the option to deploy at least one operational attribute in your AD environment.
    As you can see, it solves many problems in one step.
    Unfortunately, it is in real world environments often not possible to deploy a schema extension in Active Directory.
    This is, for example, the case, when you are not the owner of the Active Directory environment and you don’t have the power to convince the actual owner from the importance of it.
    One option you have is to start a probably endless battle to get your requirement implemented.
    This can quickly become a very time consuming exercise with a little chance to be successful.
    However, you should at least give it a try.
    At a minimum, you should track the “ideal” solution in your project documentation.
    Over the time, things may change and you might be able to implement the “ideal” solution at some point in the future.
    If you are not able to implement your “ideal” solution, you need to start thinking about a plan B.

    In our current scenario, this means, if you can’t extend the schema with a Correlation ID, you can only address the problem of detecting non-authoritative accounts by using information that is already in the system.
    Next to including the “ideal” solution into your project documentation, you should also track what the disadvantages of your plan B are.
    While using information in the system represents the next best option you have, one problem that is associated with this approach is the fact, that you might encounter problems during an initialization phase of your environment when you have to, for example, rebuild an environment after a system crash.
    One design goal of FIM was to provide a solution that will eventually converge.
    In such a system, you should have no dependencies on the order in which you process your objects.
    In other words, the order of your run profile runs shouldn’t matter.
    Having a FIMID would make your system independent from considerations in conjunction with this.
    In case of a system crash, you can easily get your environment back into an operating state.
    If you don’t have a FIMID, your best bet is probably using an operational attribute in the metaverse that enables to implement sort of a “first writer wins” solution.
    In case of a non-authoritative account, this account is the first one that can populate the metaverse attribute.
    The attribute flow precedence configuration should give the Active Directory management agent a lower precedence.
    This configuration enables the Active Directory management agent to populate the metaverse attribute if it hasn’t been populated yet.
    However, it also prevents this management agent from a value if the attribute has been already populated by the FIM management agent.
    As long as we are in an initialized environment, that doesn’t require full synchronizations to be performed, we can use the metaverse attribute to detect non-authoritative accounts, which might be good enough.

    First Conclusion

    Detecting non-authoritative accounts can become a simple exercise if you have the luxury of being able to deploy a schema extension that is used to track process related information contributed by FIM.
    If you can’t deploy the extension, you will have to come up with an alternate solution.
    We have already identified that this solution must be based on information that is already available in the system and an operational attribute.

    If you want to know more about how this operational attribute is used, you need to read the second part of this collection that covers the solution design.

    Part2: Design

     

      Go to the Experts Corner

     


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation
    Wednesday, January 6, 2010 11:02 PM

All replies

  • Your entire text can be replaced by a single phrase "If your objective is to manage Activate Directory with FIM and you want to detect non-authoritative accounts, you should have a special attribute on your AD object that can only be contributed by FIM"

    and can a few words about Correlation ID

    Friday, November 19, 2010 3:16 PM