We are on Keycloak 3.4.2 using OpenLDAP 2.4.40. We have implemented ppolicy overlay on the server side to deny authenticated binds when someone's password has expired but we have custom attributes like loginDisabled that also dictates if someone should be granted access. Thanks, - Trey -- Trey Dockendorf HPC Systems Engineer Ohio Supercomputer Center On 4/9/18, 3:17 PM, "Marek Posolda" <mposolda(a)redhat.com&gt; wrote: What is your Keycloak version? And what is your LDAP vendor? Is it MSAD? For MSAD, we have builtin support with the MSAD mapper as long as you use "userAccountControl" attribute to track if user is enabled/disabled (which is standard for MSAD environments AFAIK). Marek Dne 6.4.2018 v 14:38 Dockendorf, Trey napsal(a):

With either approach it sounds like what your describing is getting the loginDisabled attribute into Keycloak. Once that attribute is stored, how would I go about telling Keycloak to disallow access based on the attribute's value? Below is an example of LDAP record where login should be disabled. Thanks, - Trey dn: cn=<username>,ou=People,<base DN> displayName: first last employeeType: REGULAR gecos: first last ou: OSC Operations cn: <username> employeeStatus: ACTIVE gidNumber: 103 company: Ohio Supercomputer Center uid: <username> mail: <email> homeDirectory: /users/<username> title: Employee uidNumber: 20821 sn: lastname objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: posixAccount objectClass: oscUser objectClass: shadowAccount givenName: firstname jobCode: FALSE loginDisabled: TRUE loginShell: /bin/bash -- Trey Dockendorf HPC Systems Engineer Ohio Supercomputer Center On 4/10/18, 10:42 AM, "Marek Posolda" <mposolda(a)redhat.com&gt; wrote: I think you would either need to use User Attribute LDAP Mapper, but not sure if it's possible. I am not 100% sure about your LDAP structure. Or you need to implement custom LDAP Storage mapper then. Marek Dne 10.4.2018 v 15:30 Dockendorf, Trey napsal(a):

We've taking the approach of using OpenLDAP ACLs. If anyone comes across this thread and wonders how we did this: ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to attrs=userPassword filter="(!(loginDisabled=TRUE))" by self read by anonymous auth by * break olcAccess: {2}to attrs=userPassword by dn="cn=ldap-admin, <BASE>" write by dn="cn=idm-admin,ou=Admin, <BASE>" write by dn="cn=syncuser,ou=Admin, <BASE>" read by * none olcAccess: {3}to * by dn="cn=ldap-admin,<BASE> " write by dn="cn=idm-admin,ou=Admin,<BASE>" write by dn="cn=syncuser,ou=Admin,<BASE>" read by * read EOF -- Trey Dockendorf HPC Systems Engineer Ohio Supercomputer Center On 4/11/18, 3:47 AM, "Michael Ströder" <michael(a)stroeder.com&gt; wrote: Dockendorf, Trey wrote: With OpenLDAP's ACLs you should grant auth access to 'userPassword' for anonymous based on value of your custom loginDisabled attribute. With such an ACL keycloak does not have to know about that attribute at all. And all LDAP-enabled applications will behave the same without reconfiguration. OpenLDAP details are off-topic here. You could ask for ACL details on the openldap-technical mailing list. Ciao, Michael.