I see that that LDAP sync is deprecated from v 11.2 for Conjur enterprise integration but only LDAP authentication is enabled. Wouldn’t this this be administrative overhead managing conjur as the same LDAP user would need to be created through policy rather than depending on LDAP. Any suggestions on LDAP integration on latest conjur versions would be helpfull
1 Like
@sjohnkennedy, the way the DAP LDAP integration works is as follows:
- Setup the ldap sync integration
- Using the LDAP sync, generate a policy with users/groups defined
- Load the policy
- Enable authn-ldap to then authenticate with ldap username/password
Management of users still requires you to load policy. Additionally, since the users must be loaded into root you have some decisions to make with regards to policy management practices. You must also maintain the user in the DAP database, as depending on how you handle policy management, you might be in a situation where you have to load delete policies to remove users. Finally, the CorePAS LDAP integration is far more feature rich, supporting multiple types of MFA, automatically removing users when they are removed from LDAP, automatically adding users when they log in, PSM and PSMP workflows, check-out/check-in workflows, etc. In short, for your interactive user sessions you are much better served leveraging the CorePAS features.
Finally, to clarify @boazmichaely’s comment, the Vault Conjur Synchronizer does not currently bring over any policy or safe ACL information from CorePAS. This is built on the DAP side independently. The Synchronizer does build a policy structure in DAP that allows you to easily delegate policy management to application teams who can define DAP hosts that can fetch secrets. Any secrets management work required by the app team should still be done on the CorePAS side though and rely on the Synchronizer to replicate those changes to DAP (e.g. secrets on boarding and rotation, new safe creation, etc.)
Regards,
Nate
@nathan.whipple I am trying to setup LDAP and getting error message while trying to connect to LDAP using the SSL. I have port 636 open on the master container and connection is successful from master container to AD server over 636. I have provided the screenshots below, please let me know your thoughts as I am not sure what is causing this.
screenshot that LDAP over 636 is sucessful
@sjohnkennedy, the LDAP sync service is normally down and won’t start. If it doesn’t start, you’ll get a 502 error like you are seeing. You need to remove the down file for the service, then use sv start to start the service up. https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/ldap/ldap-sync-config.htm?Highlight=ldap%20sync#Enableandstarttheservice
I’ll state again though, we do not recommend using this feature in DAP and plan to deprecate it in the future. Is there a particular reason you’re trying to get it working? I might be able to offer advice on alternative ways to accomplish the same goal.
Regards,
Nathan
@nathan.whipple I am looking at options to manage large groups of developers having access to DAP. I thought it will be easier to use the LDAP. What would be best approach to handle this scenario with limitation in the LDAP sycn. Do we need to create these users in root every time we need a user we might need to load policy and share the API keys with them manually.
@nathan.whipple @boazmichaely checking in to see if you had any thoughts on this. Appreciate your response
@sjohnkennedy, thank you for your patience, and my apologies for the delayed response.
The first question I’d ask is what is the reason the developers need interactive access to DAP for? Management (updating password values, rotation, etc) of the credentials used by their applications should be done in CorePAS. DAP policy management should be done through a SCM repo and automation (e.g. Jenkins or similar pipeline that loads policy after it’s been approved/merged in the SCM repo). These are the patterns we advise customers to follow, and the net result of this approach is that interactive access to DAP has been unneeded.
To accomplish the above, I create a policy branch off of root that represents the application. This policy branch is owned by a service account host. The credentials and details to work with the policy branch are then provided to the application team/owner/developer. They would use the service account credentials to setup their pipeline for loading policy. The contents of the policy they would load would primarily be focused on the creation of hosts that represent the machines and services in their application that need to fetch credentials.
This is a sample of the policy that I would load into the root branch to create the application policy namespace:
# AppTeam Policy Template where policy namespace = EPV safe name
# Replace my_app with the name of the safe synchronizeed from EPV
# Note: The final grant assumes that VCS has already created the policy namespace.
#======================
- !host
id: my_app_svc
restricted_to: 172.17.0.3 ##This is optional and would be used to restrict this host so it could only be used from your Jenkins address space
- !policy
id: my_app
owner: !host my_app_svc
body:
- !group readonly
- !grant #Enable the `readonly` group members to use the `lab` IAM authenticator
role: !group conjur/authn-iam/lab/iam_clients_lab
members: !group my_app/readonly
- !grant #Enable `readonly` group members to use the `lab` k8s authenticator
role: !group conjur/authn-k8s/lab/consumers
members: !group my_app/readonly
- !grant #Enable the `readonly` group members to retrieve secrets synced from the `my_app` safe in CorePAS
role: !group lab-vault/lab-lob/my_app/delegation/consumers
members: !group readonly
This policy creates a branch named my_app with host that owns it named my_app_svc. The app team that owns my_app would have access to a safe in CorePAS wherein we’d put the API key created for this host. There is also a readonly group that is created. This group is a member of the various groups that can use the IAM authenticator, k8s authenticator, and access the secrets that were synchronized from CorePAS. The app team would then create hosts by loading a policy with the service account into the my_app policy branch and making those hosts a member of the readonly group.
- &my-hosts #YAML anchor so we don't have to list the hosts again in the grant
!host 33098445777234/IAM-Role #Host that uses IAM role to auth
!host ocp_ns/service_account/sa #Host that uses OCP namespace and service account to auth
!host my_host #Host that uses API key to auth
- !grant
role: !group readonly
member: *my-hosts
This is a pretty challenging topic to cover in this setting, and while I tried to hit the important bits without writing a novel this has ended up being longer than I hoped and necessitated making a few assumptions. That said, let me know if there is anything I can clarify further and I’ll do my best to close those gaps.
Regards,
Nathan