I'm working with LDAP (ApacheDS) in Java, I was wondering if it's possible to impersonate a user using the system account.
More specifically, I have different groups in LDAP directory, and I need to allow users to modify entries under a group, but only the group this particular user belongs to. For example, if there is a following group:
o=acme
And an administrator of that group:
cn=admin,o=acme
I want to impersonate the admin user using the system account credentials, and allow them to only make changes in acme group.
I will elaborate since the above is not clear enough:
Lets say user A logs in. He is an administrator of ou=Group A. If, some time after logging in, he performs an action that require a connection to LDAP, it means that his credentials should be stored in session to allow him to connect. I want to avoid that, and impersonate user A using the system/some other admin account without needing user A password.
Thank you in advance.
Why? Just create your own admin-app account for use by the application, with the same privileges as the user admin account. Don't use the system account, that's for use by LDAP itself.
Related
I want to know if it's possible to create an Active Directory user account that confers no access or privileges to that user.. simply to authenticate a set of credentials..
As we are hybridised AD/Azure organisation, I want this 'account' to replicate to Azure through the connector.
The reason for this is that:
We manage all our users through AD so I don't want some accounts managed only in Azure.. it would be very confusing. Centralised managemnent and support is good!
The account would ONLY be used for authenticating users into Zoom via SAML2, or any another cloud service for that matter that can use Azure as an authentication service.
No capacity to access anything within our firewall.
Your ideas would be greatly appreciated.
Gus
It depends how you define "access". By default, the Authenticated Users group is able to read everything in AD, but not write. If you're ok with that, then you're done. Just create a user and don't add any access to it.
If you don't want it to read anything on the domain, then you'll have trouble. The Authenticated Users group is described as:
A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
Since there is no way to not have a user be part of Authenticated Users, then you would have to modify the permissions on your domain to exclude Authenticated Users. But that may cause other issues for other users.
As far as I know, the most basic permissions that any user is created can also view other users or groups in AAD. If you want to turn off this basic permission, just set Restrict access to Azure AD administration portal to Yes, then the user will not have any access rights.
Go to azure portal->click Azure Active Direcotory->User settings
I see in https://developers.google.com/+/api/latest/people#resource
that we get the domain name. But I don't see any indication of the user role. I would like to know if the user is a domain administrator so that I can give them more rights within our application.
You must use the Directory API to get that info. Note that you will need an OAuth token with admins rights to use this API.
We use Jenkins with LDAP authentication. My question: is it possible to implement this rights scenario?
if not logged-in (anonymous) ==> read all
if logged in (via LDAP) but not a "special" user ==> full access to specified jobs only
if logged in (via LDAP) and also a "special" user ==> full admin access
My goal is to avoid having to manage large numbers of users explicitly.
There's a plugin "Role Strategy Plugin" that supports permissions for specified jobs, but it doesn't distinguish between anonymous and logged-in (via LDAP) users. It seems that the only way to grant access to specified jobs is to grant it user by user...which I want to avoid.
Can you use Active Directory? If so:
you can use groups for authentication, and therefore assign rights to the entire group.
you can use a project-based matrix, so specified jobs will only be visible to specific groups
If you cannot (only LDAP):
I think you can still do the above, but I think your LDAP configuration will require more work for groups. I am not sure of group support in the Jenkins LDAP API.
We have a requirement to get information from specific users on an LDAP directory based on a Smartcard being presented. The application is already running under an AD user account, but using that users access to LDAP will not have sufficient access to the specific users data.
We have stumbled through a few parts of LDAP APIs and not had much luck finding info on how to make an LDAP bind call without username/password and more specifically with auth from a smartcard. Some of the MS LDAP appears to allow the option of using the current user token.
The best we have come up with is to use the SC to login then while impersonating the user create the ldap connecton using the current user token. Similar in idea to this MDSN blog .
Is there a better way?
The problem we are having with the impersonation is that the logged in user has to have certain rights for logging on other users to do the impersonation. Also while impersonating we need to limit other interactions, accessing the file system or registry as the alternate user is not desirable.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)