In Dynamics CRM, how much of a non null, predictable-format identifier is really "domainname"?

3
votes

I have code that calls the Dynamics CRM Web API to get information about a Dynamics user. It doesn't know the user's internal Dynamics identifier ahead of time and thus relies on their Active Directory login as a key in queries.

I have a few doubts and questions about that :

  • domainname (i.e. user login) is a mandatory field when you create a user in Dynamics, but will it always be non-empty - even when you disable the user for instance?

  • I noticed that you can indifferently specify a login in the form domain\username and username@fulldomainname at user creation. Login seems to be kept intact inside Dynamics, so when you use the API you must be aware of the format it was entered in in the first place. For instance, searching for mydomain\bob won't give you a bob@mydomain user.

    Are there any other possible formats for a user's login in Dynamics CRM or are we safe assuming that it will follow one of these 2 patterns?

  • Is domainname case-sensitive?

  • How do Dynamics modules or third party tools that somehow only have windows logins to start with manage to find users deterministically? For instance, we could have an external application that needs to access all the Leads owned by a particular user in Dynamics. Do they systematically try all different login formats and all combinations of cases? I think it would be pretty spooky.

1
active-directorydynamics-crm

1 Answers

3
votes

  • The attribute domainname will not be emptied on disabling the user - this will only affect the state of the record.

  • It's true that you have to consider both variants if your authentication authority allows both variants (see last point) when using domainname as a query criteria.
    I could not think of a real world 3rd variation that allows omitting the domain name.

  • The domain name is not case-sensitive.

  • Since there are basically 2 (real world) options for on-premise systems, it's not that spooky after all: You can either authenticate against IIS directly or SSO via STS/ADFS. Both impose the accepted login and use common windows authentication methods.
    There's nothing special CRM needs to handle - it relies on users arriving with a valid authentication token.