locked
User Management Such As Change Password In CRM IFD Mode RRS feed

  • Question

  • Hi,

    Due to using CRM 4.0 in IFD mode with users that do not share the same domain, we had to deploy a separate Active Directory to handle the user management aspect. All CRM users will then have to be added into this Active Directory in order to access CRM.

    We therefore have several issues below. Is there any sort of AD interface exposed in CRM allowing us to address the issues below:

    1)      Upon creation of the users in Active Directory, they are given a user name and password by the system administrator  who then defines the user on CRM.  Once this is done, there is no mechanism currently to auto send the user name and password to the user, hence the admin needs to e-mail it or manually deliver it to the user.

    2)      The second part of the problem is once the user receives the user name and password, there is no mechanism for him/her to change it after wards, which means that he/she is stuck with whatever password the administrator has given.  It also means that the admin needs to be creative in creating passwords that cannot be easily guessed and unique to the user.

    3)      The third fold is if the user forgot his/her password, then the only way to get it back or to get a new one is by emailing the system admin.

    Appreciate the community's thoughts on this one - we want to avoid custom coding if we can, but of course, if there is no other choice, then we will think about doing this.

    Kind Regards,
    Tuesday, March 16, 2010 8:24 AM

Answers

  • This could be managed in CRTM but you'll need to write some custom process between AD and CRM.  Below are some ideas for consideration:

    1)      Upon creation of the users in Active Directory, they are given a user name and password by the system administrator  who then defines the user on CRM.  Once this is done, there is no mechanism currently to auto send the user name and password to the user, hence the admin needs to e-mail it or manually deliver it to the user.

    In your custom process, you can pass the username and password to the User's CRM record or a custom entity built in CRM to store the User Name and Password only.  I prefer the custom entity approach so that you don't need to give write access to the CRM user record.  You can then use a workflow to automatically send an e-mail to the user with the information when a new record is created in CRM.  You'll need to create two custom fields in CRM to store the information.  There are security implications that you'll need to consider with regard to storing passwords and sending them in an e-mail. 

    2)      The second part of the problem is once the user receives the user name and password, there is no mechanism for him/her to change it after wards, which means that he/she is stuck with whatever password the administrator has given.  It also means that the admin needs to be creative in creating passwords that cannot be easily guessed and unique to the user.

    You can accomplish this by requesting that the user update the password field on the custom entity and pass the updated password to AD.  In your customization between AD and CRM you'll want to include a process that updates the AD password with changes that the user makes to the password field in CRM. 

    3)      The third fold is if the user forgot his/her password, then the only way to get it back or to get a new one is by emailing the system admin.  You'll need to write a custom aspx page that allows the user to request the password.  You can have that page trigger a workflow that retrieves the user name and password from CRM and send it to the user.

    I realize you said you didn't want to write customization but since the communication between Active Directory and CRM is one-way, this will require some customization.  However, a savvy developer should be able to get this up and running fairly quickly by leveraging the CRM SDK and similar tools available for AD.

    You can also have a look at this tool to see if it will work for you as you don't really need to manage this in CRM.  You might be able to manage it directly with AD.

    Tuesday, March 16, 2010 1:23 PM
  • Hi Asim,

    Currently there is no such functionality out of the box.  However, the above can be done with a bit of custom code against active directory. 

    We encountered this same issues with many of our clients.  The design approach we took was to create a set of aspx pages that talks to active directory via adsi.  Basically dot.net code that talks to Active Directory.  We created this password request system where end users can request 'i forgot my password' link.   The user receives this link via an email message.  This link has a hashed guid so it only works for their user account and is only valid for x number of hrs.  

    The functionality of these aspx pages is to allow end-users to assign thier initial password AND allow them to reset their password anytime and in case they forgot.   Since it is an aspx page we can then control things such as requiring complex passwords, comparing to list of known weak passwords, etc.


     
    Alex Fagundes - www.PowerObjects.com
    Tuesday, March 16, 2010 3:09 PM

All replies

  • Hi,

    1/ There is no way to send an email automatically from the CRM since the password is not known by the server. You need to continue using the actual procedure.

    2/ There is no standard mechanism but you can create a custom web page that allows users to update their passwords

    3/ Same as 2/

    Hope this helps
    My blog : http://mscrmtools.blogspot.com
    You will find:
    Bulk Delete Launcher(Delete data based on advanced find queries)
    Form Javascript Manager (export/import javascript from forms)
    ISV.Config Manager (graphical ISV.config edition - export/import)
    View Layout replicator (customize one view and replicate to others)
    And others (use tool tag on my blog)
    Tuesday, March 16, 2010 9:00 AM
    Moderator
  • This could be managed in CRTM but you'll need to write some custom process between AD and CRM.  Below are some ideas for consideration:

    1)      Upon creation of the users in Active Directory, they are given a user name and password by the system administrator  who then defines the user on CRM.  Once this is done, there is no mechanism currently to auto send the user name and password to the user, hence the admin needs to e-mail it or manually deliver it to the user.

    In your custom process, you can pass the username and password to the User's CRM record or a custom entity built in CRM to store the User Name and Password only.  I prefer the custom entity approach so that you don't need to give write access to the CRM user record.  You can then use a workflow to automatically send an e-mail to the user with the information when a new record is created in CRM.  You'll need to create two custom fields in CRM to store the information.  There are security implications that you'll need to consider with regard to storing passwords and sending them in an e-mail. 

    2)      The second part of the problem is once the user receives the user name and password, there is no mechanism for him/her to change it after wards, which means that he/she is stuck with whatever password the administrator has given.  It also means that the admin needs to be creative in creating passwords that cannot be easily guessed and unique to the user.

    You can accomplish this by requesting that the user update the password field on the custom entity and pass the updated password to AD.  In your customization between AD and CRM you'll want to include a process that updates the AD password with changes that the user makes to the password field in CRM. 

    3)      The third fold is if the user forgot his/her password, then the only way to get it back or to get a new one is by emailing the system admin.  You'll need to write a custom aspx page that allows the user to request the password.  You can have that page trigger a workflow that retrieves the user name and password from CRM and send it to the user.

    I realize you said you didn't want to write customization but since the communication between Active Directory and CRM is one-way, this will require some customization.  However, a savvy developer should be able to get this up and running fairly quickly by leveraging the CRM SDK and similar tools available for AD.

    You can also have a look at this tool to see if it will work for you as you don't really need to manage this in CRM.  You might be able to manage it directly with AD.

    Tuesday, March 16, 2010 1:23 PM
  • Hi Asim,

    Currently there is no such functionality out of the box.  However, the above can be done with a bit of custom code against active directory. 

    We encountered this same issues with many of our clients.  The design approach we took was to create a set of aspx pages that talks to active directory via adsi.  Basically dot.net code that talks to Active Directory.  We created this password request system where end users can request 'i forgot my password' link.   The user receives this link via an email message.  This link has a hashed guid so it only works for their user account and is only valid for x number of hrs.  

    The functionality of these aspx pages is to allow end-users to assign thier initial password AND allow them to reset their password anytime and in case they forgot.   Since it is an aspx page we can then control things such as requiring complex passwords, comparing to list of known weak passwords, etc.


     
    Alex Fagundes - www.PowerObjects.com
    Tuesday, March 16, 2010 3:09 PM
  • There are lots of Control Panel vendors who offer user management portals for Microsoft Exchange hosting providers, and several of these work with hosted CRM (i.e. CRM in IFD configuration), but generally they'll also expect you to be running the full HMC framework. If you're a commercial CRM hosting provider and also hosting Exchange or SharePoint, it's worth taking a look at these (search: HMC control panel).

    Otherwise, like Alex and Donna have suggested, it's fairly simple to write a couple of custom web pages to handle this. We had a junior developer write a simple user mamagement web app in a couple of days.

    Regards, Neil
    Thursday, March 18, 2010 11:22 AM
    Moderator