none
Why is Domain required for an identity in the FIM Service? RRS feed

  • Question

  • I have a scenario where FIM is managing identity, but not all identities have an Active Directory account. I have a flag in the FIM Portal (Service) that indicates if a particular user is entitled to an AD account or not. My provisioning setup adds or removes the AD account as appropriate. To support FIM Portal activities for those that do have AD accounts, I populate AccountName, Domain, and ObjectSID in the FIM Service from their corresponding attributes in AD.

    What I have noticed is that it does not seem possible to null out or delete the Domain attribute for a user in the FIM Service. I can delete the attributes for both AccountName and ObjectSID without issues.

    When attempting to remove the Domain attribute for a user I get the following in the event logs:

    Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other ---> System.Data.SqlClient.SqlException: Procedure or function 'GetDomainConfigurationIdentifiersFromDomain' expects parameter '@domainName', which was not supplied.

    I assume that something internal to the FIM Service is trying to do some magic with validating the domain name and the domain configuration. I did found a post saying, “Yeah, you have to populate Domain”:

    http://social.technet.microsoft.com/Forums/en-US/f207caa9-3a6f-4f2d-8461-a83777280803/fim-service-ma-export-failedmodificationviawebservices-error?forum=ilm2

    My question is why is Domain required for a user? It is obviously needed for users that have AD accounts an must authenticate with the Portal, but in the case where a user does not have an account (and therefore does not have a domain), it feels odd to store the incorrect data for the user. It also looks weird when you bring up list of users in the portal and see domain values for users that do not have accounts. In this particular case, the client has many domains and does have the Domain and AccountName attributes displayed on the user search results page.

    Friday, February 21, 2014 2:08 AM

All replies

  • Domain is needed to log in to FIM Portal (for example if you change user's domain in FIM Portal to any other value), he would not be able to log in.

    I bet that it is used for validate requester of each operation - from logging into FIM Portal to registering user for password reset and, during password reset process, to verify that domain\user exists in Portal.


    Keep trying If you found my post helpful, please give it a Helpful vote. If it answered your question, remember to mark it as an Answer.

    Friday, February 21, 2014 7:08 AM
  • As I mentioned above I know you need a domain value for users that need to log into the portal (and if you don't have a domain value along with an account name and object SID, you can't log in.) My question is more from a FIM Service database schema point of view, why is it a required value? There are cases where you have a user that does NOT need to log into the FIM Portal (because they don't have an AD account). For these users (identities really), why does the FIM Service require a value for the Domain attribute?
    Friday, February 21, 2014 7:05 PM
  • Hi Rex

    Per default a value in Domain is not required. You can evaluate this by creating an object using the FimAutomation Powershell Snapin. You can create a user object without Domain, you can add a value to the domain Attribute later and you can remove the value from an existing user object.

    You possibly have another root cause for your Problem.

    Henry  

    Friday, February 21, 2014 8:07 PM
  • Hi Henry,

    When I am doing support, "Works for me" is one of my favorite things to say as well... (/grin)

    Unfortunately I see different results. I have tried on two different installs (Build 3419 and 3508) and in each instance if I try to delete the value for Domain I get the error in my original post in the FIM Service event log. I have tried both from the FIM Portal (using the advanced view) and via PowerShell FIM automation. Interestingly when I set the Domain attribute (and only the Domain attribute) via PowerShell, the FIM request history shows an update to both Domain and DomainConfiguration. When I try to remove the Domain attribute I get the error. I even tried to remove both the Domain and DomainConfiguration values at the same time - that didn't work either.

    I was able to create a user (from PowerShell) with no Domain value, but once I set it, I could not clear it.

    Since it works for you, what FIM build are you on?

    Thanks,

    Rex

    Saturday, February 22, 2014 12:45 AM
  • Hi Rex

    my FIM Test Environment is Version 4.1.3496.

    When I add a Domain Attribute I can see the following in request Details:

    Then I delete the Attribute writing an empty string:

    SetAttribute -object $importObject -attributeName "Domain" -attributeValue ""

    In both cases the only relevant MPR triggered is "Administration: Administrators can read and update Users".

    Henry

    Saturday, February 22, 2014 9:41 AM
  • Hi Henry,

    When you use the SetAttribute PS function with an attribute value of "", you are setting the attribute value to an empty string, you are not deleting the value. Looks like you can set the domain to an empty string - I was able to do this in my environment. If you have time try it again, but actually attempt to delete the attribute from the FIM Service.

    Try this function (It is just the SetAttribute function with the value assignment removed):

     function NullAttribute
     {
        PARAM($object, $attributeName)
        END
        {
            $importChange = New-Object Microsoft.ResourceManagement.Automation.ObjectModel.ImportChange
            $importChange.Operation = 1
            $importChange.AttributeName = $attributeName
            $importChange.FullyResolved = 1
            $importChange.Locale = "Invariant"
            if ($object.Changes -eq $null) {$object.Changes = (,$importChange)}
            else {$object.Changes += $importChange}
        }
    } 

    The distinction between sending an empty string and a attribute deletion request is important because when the Sync engine "flows a null", it sends a request to delete the attribute.

    Rex

    Edit: I don't have any other MPRs firing either.


    • Edited by Rex Wheeler Saturday, February 22, 2014 5:46 PM
    Saturday, February 22, 2014 5:43 PM
  • Hi Rex

    You are right, I also was not able to really remove the Attribute instead of setting an empty string. But then I removed the Domain value using the advanced view and I saw that not the Domain was remove but the DomainConfiguration. So I tried to remove the DomainConfiguration using your script example and it works. Now the question is how to use this knowledge. I would create a custom Attribute and sync the Domain to this as well. and whenever this Attribute gets deleted by the Sync Account I would start a workflow which actually deletes the domainConfiguration of the target object.

    Cheers, Henry

    Sunday, February 23, 2014 3:12 PM
  • Hi Henry,

    Using another domain attribute and workflow to maintain the actual Domain and DomainConfiguration is a good suggestion, thanks.

    My original question still stands however... Why is Domain required in the FIM Service?

    It is sounding like the answer is "It is not really required on it's own, but there is an internal process that requires it if there is a value for DomainContext set (and there is some magic that sets DomainContext, so you have to manually clear it.)"

    Since DomainContext is automatically set when a client writes a value to Domain. I would suggest that it is a bug that DomainContext is not automatically cleared when Domain is cleared.

    I poked around a bit and the bug can be fixed by changing the stored procedure definition to allow null parameters. In the FIM Service database the stored procedure [fim].[GetDomainConfigurationIdentifiersFromDomain] has a parameter declaration of "@domainName NVARCHAR(448)". If this is changed to "@domainName NVARCHAR(448) = null" the problem appears to be solved. Making this change would of course be totally unsupported, but perhaps it can be included in a future product update.

    For now I will use Henry's workaround, or just live with potential out of date Domain data.

     Thanks

    Sunday, February 23, 2014 6:38 PM
  • Hi Henry/Rex,

    FIM Service may also be using domain name attribute to ensure account uniqueness. 

    In FIM 2010 R1, we were not able to have two users with the same account name for two different domains. 

    I have noticed that with FIM 2010 R2 we dont have that limitation any more. We now can have users with the same account name from two different domains. Ofcourse, their ObjectSID needs to be different as well.

    Given that, my bet is on the fact that domain name attribute is used for account uniqueness. 


    Thanks,

    Jameel Syed | Identity & Security Strategist | jameel.syed@credexo.com | Simplified Identity and Access Management


    Tuesday, February 25, 2014 8:02 AM