openldap admin guide nodes

Admin Guide Overview:

Take 3 on the ldap research. Previous efforts were OBE as I started studying puppet. Now that I have a functioning CM tool, I’m bouncing back into the ldap arena. Need to get a handle on this.

First stop is reading the openldap admin guide for ver 2.4 which is the one available via the centos repos. URL is http://www.openldap.org/doc/admin24/

Other URLs of note:

Document Catalog	http://www.OpenLDAP.org/doc/
Frequently Asked Questions	http://www.OpenLDAP.org/faq/
Issue Tracking System	http://www.OpenLDAP.org/its/
Mailing Lists	http://www.OpenLDAP.org/lists/
Manual Pages	http://www.OpenLDAP.org/software/man.cgi
Software Pages	http://www.OpenLDAP.org/software/
Support Pages	http://www.OpenLDAP.org/support/

The goal is to read the admin guide then step back and install it. Once done, the following goals:

Goals:

• Configure UNIX authentication through ldap

  • Authentication information:

    • Groups

    • Users

    • ssh public keys

    • ssh private keys (particularly, if we can force ‘em to be passphrase protected and use a forced command.

    • sudo (see sets in ch 8.5)

  • Authentication restrictions:

    • Certain users on certain systems only

    • Password aging (overlay (chapter 12))

    • Password complexity (overlay (chapter 12))

    • tcpwrappers

• Configure sudo through ldap

• Create cmdb in ldap?

• Configure puppet ENC to use ldap

• Build/configure openldap from scratch for experience; however, primary goal is to use rpms for patching capability.

• Study/experiment w/ldap ACLs, including security strength factors (ssf)

• Configure pictures in the ldap directory. (can be base64 encoded ascii string)

• Study/experiment w/ access/audit logging, particularly for samba.

Lessons learned:

• Initial access to directory - something that’s confused the hell out of me:

  • Potentially via SASL

  • Potentially via this entry in chapter 8, acls.

Acronyms:

ldap:

lightweight directory access protocol.

DIT:

directory information tree.

LDIF:

LDAP directory interchange format.

SASL:

Simple Authentication and Security Layer.

Chapter 1: intro to openldap directory services:

Only taking notes on info I don’t already know or that should be reinforced.

Chapter 2: Quick start guide:

Challenge on this one is to not actually do it…

Chapter 3: Big picture - configuration choices:

Chpater 4: Building and installing openldap s/w:

Chapter 5: Configure slapd

Describes the new slad-config layout. Older slapd.conf model is described in chapter 6.

• slapd-config (new) stores configuration in text based ldif files. DON’T edit them. Use ldapadd/modify/delete.

• Config

  • module

  • schema

    • core

    • cosine

  • oldDatabase

• slapd-config uses {#} as a method of forcing order in the directory.

• Generally, a 1-1 correspondence between old style slapd.conf directives and their old${directive} counterpart.

• Interesting parameters:

  • olcLogLevel: values are additive

Level	Keyword	Description
-1	any	enable all debugging
0		no debugging
1	(0x1 trace)	trace function calls
2	(0x2 packets)	debug packet handling
4	(0x4 args)	heavy trace debugging
8	(0x8 conns)	connection management
16	(0x10 BER)	print out packets sent and received
32	(0x20 filter)	search filter processing
64	(0x40 config)	configuration processing
128	(0x80 ACL)	access control list processing
256	(0x100 stats)	stats log connections/operations/results
512	(0x200 stats2)	stats log entries sent
1024	(0x400 shell)	print communication with shell backends
2048	(0x800 parse)	print entry parsing debugging
16384	(0x4000 sync)	syncrepl consumer processing
32768	(0x8000 none)	only messages that get logged whatever log level is set

• oldModuleLoad: dynamically loadable module.

• odlMoudlePath: path to the dynamically loadable modules.

• Schema: holds all the schema definitions; values are generatedy by slapd so nothing needs to be in here. More of a place holder for the user-defined schmeas added underneath.

• Backend directives

Skimmed through the rest of the chapter. Some interesting parameters and some intriguing possibilities. I did see a statement where the suggestion is to eliminate the rootpw in favor of sasl authentication. Guess I’m going to have to look into that - chapter 17.

To convert a slapd.conf file to the new format:

slaptest -f ${slapd.config_file_loc} -F ${new_format_directory_loc}

Chapter 6: same thing for the slapd.conf file:

skipping

Chapter 7: running slapd:

• If both -f and -F are used, the slapd.conf file is read and converted to slapd.config format.

Chapter 8: access control:

• slapd.access(5) man page.

• access to <what>:

  • to *: All entries

  • to dn[.<basic-style]=<regex>

  • to dn.<scope-style>=<DN>: most common.

• scope is either

  • base: matches only the entry provided.

  • one: maches the entries whose parent isthe one provided.

  • subtree: matches all entries in the subtree root’ed by the provided DN

  • children: matches all entries under the DN, but not the DN itself.

• The example from the admin guide:

  0: o=suffix 1: cn=Manager,o=suffix 2: ou=people,o=suffix 3: uid=kdz,ou=people,o=suffix 4: cn=addresses,uid=kdz,ou=people,o=suffix 5: uid=hyc,ou=people,o=suffix

  dn.base=”ou=people,o=suffix” matches 2: dn.one=”ou=people,o=suffix” matches 3 and 5: dn.subtree=”ou=people,o=suffix” matches 2,3,4 and 5: dn.children=”ou=people,o=suffix” matches 3,4 nd 5:

• Access lists are evaluated in the order that they’re in the config file. Move from specific to general when writing them.

• Need to examine Security Strenght Factors (SSF)

• Implicit acces to * by * none. If there’s no access directive, the read-only one takes affect. If there is one, there’s an implicit access denial at the end of it. Probably shouldn’t rely on that, though…

• When updating access rules w/slapd.config, use the numeric index:

  changetype: modify delete: olcAccess olcAccess: {1} - add: olcAccess olcAccess: {1}to dn.children=”dn=example,dc=com” by * write -

• ACL examples:

  • First one was the basic allow users to update (but not see) their own password, anonymous to authenticate and no access to anyone else

  • anonymous = dn.exect=”” || dn.regex=”^$”

  • users = dn.regest”.+”

  • • You could specify the rootdn in ${config} (either0 w/o specifying rootpw. **Then, you have to add an actual directory entry with the same dn.*

      dn: cn=Manager,o=MyOrganization
      cn: Manager
      sn: Manager
      objectClass: person
      objectClass: top
      userPassword: {SSHA}someSSHAdata
      

    • Once that’s done, you can restrict access to it via ACLs. Below restricts authentication to localhost and 192.168.0.0/24:

      access to dn.base="cn=Manager, o=MyOrganization"
          by peername.regex=127\.0\.0\.1 auth
          by peername.regex=192\.168\.0\..* auth
          by users none
          by * none
      

Chapter 8’s going to require more studying…

Chapter 9: Limits:

• Per-database limits can be set by entity - the person making the request - so we can limit specific people more or less than others.

Chapter 10: database maintenance:

• Two methods:

  • online - using ldap commands/clients

  • offline - utilities provided w/slapd.

• Using ldap:

  • Apparently, we have to kickstart the database with a slapd.conf file (not the olc varinat). Set:

    • suffix “dc=olearycomputers,dc=com”

    • directory ${absolute_dir} to index files

    • rootdn “cn=admin,dc=olearycomputers,dc=com”

    • rootpw “my_secret_pwd”

    • index cn,sn,uid pres,eq,approx,sub

    • index objectClass eq

      Section literally say:

      This solves the chicken-and-egg problem of how to authenticate
      and add entries before any entries yet exist.
      

    • Add organization entry and organizational role:

      vi entries.ldif
      # Organization for OLeary Computers Corporation
      dn: dc=olearycomputers,dc=com
      objectClass: dcObject
      objectClass: organization
      dc: olearycomputers
      o: O'Leary Computers Inc
      description: OCI
      
      # Organizational Role for Directory Manager
      dn: cn=admin,dc=olearycomputers,dc=com
      objectClass: organizationalRole
      cn: admin
      description: Directory Manager
      # eof entries.ldif
      
      ldapadd -f entries.ldif -x \
      -D 'cn=admin,dc=olearycomputers,dc=com' -w secret
      

• Offline:

  • Same thing: kickstart the database w/appropriate entries in a slapd.conf file:

    • suffix “dc=olearycomputers,dc=com”

    • directory ${absolute_dir} to index files

    • rootdn “cn=admin,dc=olearycomputers,dc=com”

    • rootpw “my_secret_pwd”

    • index cn,sn,uid pres,eq,approx,sub

    • index objectClass eq

  • Create ldif file for the entries to be added, then run slapadd

• LDIF notes:

  • Iines may be continued by starting continuation line w/a s+

  • Interesting note: Trailing spaces are not trimmed from values in an LDIF file. Nor are multiple internal spaces compressed. If you don’t want them in your data, don’t put them there.

Chapter 11: Backends:

Apparently, it’s going to be hdb as that’s the current version of bdb. hdb = hierachical database. And, apparently, even that’s going away in favor of mdb.

Chapter 12: overlays:

Overlays are software components that provide hooks to functions analogous to those provided by backends, which can be stacked on top of the backend calls and as callbacks on top of backend responses to alter their behavior.

Huh?

Ah, I get it… some examples:

• Access logging - including samba logging (interesting)

• Audit logging - displays who changed what in the directory.

• Chaining - the directory server follows referals on behalf of the client.

• Constraints - basically, checks/triggers on updates. example was ensuring mail addresses follow specific format.

• Password policies - here we go.

Chapter 13: schema specifications:

Discusses how to build your own schemas. Not something I’m looking to do anytime soon.

Chapter 14: security considerations:

• network security:

  • Force server to listen on specific IPs/NICs only.

  • Use a firewall - (389/tcp and 636/tcp are defaults)

  • tcpwrappers:

    slapd: 10.0.0.0/255.0.0.0 127.0.0.1 ALLOW
    slapd: ALL : DENY
    

• Data integrity and confidentiality:

  • TLS supported via ldaps and StartTLS (standard track mechanism)

  • Brief discussion of security strength factors (ssf)

• Authentication methods:

  • simple:

    • operational modes:

      • anonymous

      • unauthenticated

      • user/password authenticated

    • Anonymous bind mechanism can be disabled by specifying disallow bind_anon in config file; that, however, does not prevent anonymous access to the directory. Use require authc to do that.

  • pass-through (sasl): Basically, using a separate mechanism, other than ldap, to authenticate to something other than ldap - like to a UNIX log in. Seems odd; not sure why this is useful.

Hrm; not as useful as I was hoping.

Chapter 15: Using SASL:

• Step 1: read Cyrus SASL for System Administrators at sysadmin.html ok; that’s done. cyrus-sasl is already installed on ldapsvr. I chkconfig’d on the daemon. Doesn’t seem to be a way to test it, though.

Yea; that was about as clear as mud. They immediately bounced into kerberos and I don’t have that installed or working just yet. That’s the next study option. So, in the mean time, looks like I’ll be doing TLS.

Chapter 16: TLS

Very basic approach to TLS. didn’t go over how to generate certs; just said I had to have valid ones. nice. Think I’ll start with the basic server, then, and move on to TLS and, hopefully, SASL.

Rest of hte chapters are for future reading once I get a server up and running. They’re basically talking about tuning, maintaining, and replicating. While all that’s important, it’s a bit like the flying part whereas I’m not even crawling yet.

Centos chapter 18: Directories:

Server utilities:

slapacl	Allows you to check the access to a list of attributes.
slapadd	Allows you to add entries from an LDIF file to an LDAP directory. always chown -R ldap:ldap /var/lib/ldap after use.
slapauth	Allows you to check a list of IDs for authentication and authorization permissions.
slapcat	Allows you to pull entries from an LDAP directory in the default format and save then in an LDIF file
slapdn	Allows you to check a list of Distinguished Names (DNs) based based available schema syntax.
slapindex	Allows you to re-index the slapd directory based on the current content. Run this utility whenever you change indexing options in the configuration file.
slappasswd	Allows you to create an encrypted user password to be used with the ldapmodify utility, or in the slapd configuration file.
slapschema	Allows you to check the compliance of a database with the corresponding schema.
slaptest	Allows you to check the LDAP server configuration.

Need to examine chapter 12 of the centos deployment guide for detailed instructions on how to use ldap for authentication.

The books and links supplied are way out of date. Unfortunately, so are the bookmarks in my ldap folder…