Solved

Options for testing Active Directory integraton - AD LDS?

  • 21 October 2019
  • 2 replies
  • 63 views

We are thinking of making a new application where part of the functionality will be creating and editing AD Users and groups. I am wondering what our best options would be for our DEV and TEST environments, since these all share the same AD environment as PROD.

 

Would AD LDS be a good option? And has anyone gotten AD LDS to work with the Account Management Service Instance? I was able to create a Account Management service that pointed to an AD LDS instance, but on executing Create User I always get an error message - "The LDAP server is unavailable".

 

For the Create User - Name property in AD LDS I've tried servername.fqnusername, servernameusername, servername username, and I always seem to get the same result.

 


13925iDDF5715967376A1E.png

icon

Best answer by ElvisJacob 29 October 2019, 10:44

View original

2 replies

Badge +10

Perhaps another approach is to set up Organizational Units in your production AD with  limited permissions   One for Dev and Test.  The account that is then doing the user and group management in K2 is only given permissions to create and modify within the particular OU (note you'll probably want to use the Run As feature for the AD events/steps instead of giving the K2 service account those AD permissions).  That way you can perform your development with K2 and it shouldn't have any wider impacts on AD outside of that OU.

Badge +9

Hi SReilly


 


for AD LDS to work with the Account Management


In order for the Active Directory event to perform the action that has been configured, the correct user permissions must be available to the action. There are two possible ways to provide these:


1) The K2 service account needs to have at least Account Operator permissions, i.e. be a part of the Account Operator group.


OR


2) The wizard needs to be configured with the 'Run As' rights of a user that has at least Account Operator permissions. See Run As - Runtime versus Design-time.


Important: Active Directory requires that the K2 service account or the account designated as the Run As account for the event has the appropriate permissions to update user information. AD contains granular permission levels as well as delegation that must be configured if the event is to successfully execute at runtime. For more information see the TechNet Magazine article Active Directory: Protect your Active Directory data.


Be aware that Account Operators can't manage the Administrator user account, the user accounts of administrators, or the group accounts Administrators, Server Operators, Account Operators, Backup Operators, and Print Operators. Account Operators also can't modify user rights.


If you need to use the wizard to perform any of these tasks, give the K2 service account administrator permission, or run the wizard as a user with administrator permissions (If a user's details are required to be edited via the Active Directory Event wizard, ensure that the user account (K2 Service or Custom) running the wizard has Administrator permissions or is part of the Administrators Group). However, it is advised that care be taken when adding users to this group (See http://technet.microsoft.com/en-us/library/bb726982.aspx for more information)



If the K2 service account does not have Account Operator permissions and you manually add them, the K2 Server must be restarted before the changes take effect due to the caching of the K2 service account credentials. for more information see the link attached: https://help.k2.com/onlinehelp/k2five/userguide/current/default.htm#LegacyDesigntools/Thick_Client_Wizards/Event_Wizards-General/ActiveDirectory/Active_Directory_Event.htm


 



https://community.k2.com/t5/K2-blackpearl-Articles/Account-Management-Service-LDAP-error-could-not-update-AD/ta-p/89444?nobounce


 


https://community.k2.com/t5/K2-blackpearl-Articles/An-error-occurred-trying-to-authenticate-the-user-gt-The-LDAP/ta-p/76798?nobounce=


 


Regards


Elvis

Reply