On Wed, 2016-11-16 at 13:30 +0000, Mehdi Sarmadi wrote: Is this just "who is allowed to access appX" or is it "while logged into A you cannot login to B?" Anyway, my advice is use groups and memberof if it's the first case. Add the users to groups IE: objectClass: groupOfNames member: uid=user,ou=People,dc=.... Then if you have the memberOf plugin enabled, you want to run the fixup task initially. Once done, you should see: dn: uid=william,ou=People,dc=... uid: william objectClass: inetUser <<-- Your users MUST have this objectClass to accept the memberof attr. memberOf: cn=network_admins,ou=Groups,dc=... Now you can filter in your application config based on: ldap_auth_filter = '(memberOf=cn=network_admins,ou=Groups,dc=...)' Hope that helps. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane

On Thu, 2016-11-17 at 07:15 +0000, msarmadi(a)arissystem.com wrote: Sorry, I do not understand the question. Can you describe the scenario in more detail, who the users are, some applications and what you want the behaviour to be? -- Sincerely, William Brown Software Engineer Red Hat, Brisbane

On Sat, 2016-11-19 at 08:29 +0000, msarmadi(a)arissystem.com wrote: Okay, I believe I understand now. Based on some "attribute", you wish to allow a user to authenticate to some application A, but not to application B depending on the attribute state. I want to break this down. Directory Server is used for providing Authentication and Authorisation. Authentication is the process of saying "are you really who you claim to be". This is the process of saying "is your password correct" for example. Authorisation is the process of saying "do you have the permission to use some resource?" What you are confusing here is you are trying to solve an *authorisation* problem by disallowing *authentication* from an IP address. This is not the right way to approach this in my experience. My former email is in fact the solution, You want a user who can *always* authenticate. But then based on memberShip of a group, you can deny the *authorisation* to the application. For example: uid=user1,ou=People,dc=... is a member of cn=Application-A but is NOT a member of cn=Application-B Most applications support a "filter" on their LDAP settings. In that filter, you would provide something like: Application A: '(&(uid=%s)(memberOf=cn=Application-A,...))' Application B: '(&(uid=%s)(memberOf=cn=Application-B,...))' When user1, who is a memberOf cn=Application-A went to authenticate to Application A, the filter is run. Because the object would be matched by this filter, the application has now *authorised* that this user can *authenticate* to the application. When user1, who is NOT a memberOf cn=Application-B went to authenticate to Application B, the filter is run. Because user1 would not match the filter, not object is returned. The application knows the user is *not* authorised for this, and fails to allow the user to login, no matter if their password is correct or not. This is exactly the behaviour you want! Another benefit of this, is that there is *no way* to do secure delegation of an attribute on the user for application permissions. You would have to allow a manager to change *all* authorisation permissions, or none. A benefit of users and groups is that the managers can be through ACI's only allowed to edit groups they are responsible for. For example, the finance manager could add users to the finance application group, but could not add users to the linux system administration group! You can read more about secure group delegation here: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10... https://fy.blackhats.net.au/blog/html/2016/05/25/acis_for_group_creation_... PS: I'm copying this text to the ticket also. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane

We accomplish for some applications by assigning a different proxy to each and then control in LDAP who the proxy can see. This should work when you can't control the logic used by the application itself. Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu -----Original Message----- From: msarmadi(a)arissystem.com [mailto:msarmadi@arissystem.com] Sent: Monday, November 21, 2016 4:20 AM To: 389-users(a)lists.fedoraproject.org Subject: [389-users] Re: How to Restrict user authentication per application? Thank you, You are right about one problem. However, I believe what you are proposing is not a solution to the problem I'm talking about. Just because, in the problem I'm addressing, I can't and it is not possible to use your method. As I said, the applications we are using are not all of them supporting search or group check. So for those which does not support your method, I posted this problem. Your solution is not addressing this problem and is for the case which application supports those things. - Additionally, to support my idea of ACI on Bind, I think having ACI on Bind operation just like others(read,write,...) has many advantages. I could talk about many things like improve security. For example think of an environment which you want to protect your directory from unwanted access, even "bind", based on a policy, time or ip for example. Please mention that this mechanism is available in some other products, and also some vendors have developed policy aware directory or a proxy which adds those to the simple directory. (e.g. netiq edirectory or ldap proxy) I mean this need / requirement is actual and natural. _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

msarmadi(a)arissystem.com wrote: I'm also thinking about this stuff for quite a while: The problem with a BIND request is that it's not yet authenticated. It's anonymous. Therefore the only (weakly) authenticated data you have is the IP address of the LDAP client. You would have to provide a relation in the LDAP entries expressing that a certain bind-DN is allowed to be sent from a certain IP address and in this case grant auth access to userPassword (or other attributes used during processing the BIND request). Note that you're lost anyway if you're only using one account per person if you have a partially compromised infrastructure. Ciao, Michael.

Already, We are using all of what are suggesting. The problem is: - Some application are not using filters along with bind, to control user login - for some reasons (e.g. not having the capability, are not designed to get user list, or they do not have need to keep things about Users, or you can't count on applications be reliable in accessing the directory correctly but you need control things centrally) - LDAP Should be able to protect itself, and have more mature policies in Access Control, even for bind operation. For example; Think of an environment which a system or application is compromised, or has malware, or something like those. In that situation we should be able to protect directory with at least bind operation ACL, and if possible with more mature access policies. Would you please let us know how? So, do you think of any other methods?