{"id":2570,"date":"2021-06-07T08:00:47","date_gmt":"2021-06-07T06:00:47","guid":{"rendered":"https:\/\/possiblelossofprecision.net\/?p=2570"},"modified":"2021-05-15T11:46:36","modified_gmt":"2021-05-15T09:46:36","slug":"ldap-server-with-389ds-part-3-acls","status":"publish","type":"post","link":"https:\/\/possiblelossofprecision.net\/?p=2570","title":{"rendered":"LDAP server with 389ds: Part 3 \u2013 ACLs"},"content":{"rendered":"

Now that we’ve set up an instance of the 389 Directory Server in part 1<\/a> and configured essential plugins in part 2<\/a>, it’s time to take a closer look at access-control list<\/a> (ACLs). After all, regular users of the directory shouldn’t be able to change data that they’re not supposed to or have universal read access in most use cases.<\/p>\n

<\/p>\n

4. ACLs<\/h2>\n

The directory server grants or denies access to objects in the DIT based on what’s called Access Control Instructions (ACI). These are multi-valued (operational) attributes that are added to the directory entry in question. There are eight operations<\/a> that the server can allow or deny access for: read<\/em>, write<\/em>, add<\/em>, delete<\/em>, search<\/em>, compare<\/em>, selfwrite<\/em> and proxy<\/em>.
\nThe syntax of an ACI attributes<\/a> looks like this:<\/p>\n

\r\n(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)\r\n<\/pre>\n
4.1. 389 Directory Server sample ACIs<\/h3>\n
Or course, this can get rather complex really quickly and is heavily dependent on the environment and use case. But to get started, there’s a set of sample ACIs that were installed during the setup of our 389ds instance in part 1<\/a>. Since we’ve set the sample_entries<\/code> option to yes<\/code> we can take advantage of those:<\/p>\n
\r\n[general]\r\nfull_machine_name = ldap.example.com\r\nstart = True\r\nstrict_host_checking = False\r\n\r\n[slapd]\r\ninstance_name = localhost\r\nroot_password = mysecret\r\nport = 389\r\nsecure_port = 636\r\nself_sign_cert = False\r\n\r\n[backend-userroot]\r\nsample_entries = yes\r\nsuffix = dc=example,dc=com\r\n<\/pre>\n
This does a couple of things<\/a>: It sets up the organizational units (OU) groups<\/em> and people<\/em> where future users and groups can be stored and creates a demo user and group within these OUs. But it also creates the OU permissions<\/em> that contains a bunch of groups:<\/p>\n