Contents
- What is LDAP?
- Setting up LDAP on z/OS
- Background to LDAP
- What do you want in a years time?
- Administration
- Controlling access
- What is going to use it?
- Using groups
- What fields do you want in the records
- What tools are there to help me?
- How do I backup/export the data
What is LDAP?
I found this a good introduction on LDAP; the structure of the data, searching and filters.
I’ve written up
- One Minute MVS: Getting started with LDAP on z/OS
- One Minute MVS: Defining resources on LDAP
- Using groups for access and authority checking is so last century
- Using LDAP with MQ multiplatform
Setting up LDAP on z/OS
I created a new LDAP instance on z/OS see getting started with LDAP on z/OS, and the definitions and JCL I used to create LDAP. I used the standard schema /usr/lpp/ldap/etc/schema.user.ldif and the IBM extensions /usr/lpp/ldap/etc/schema.IBM.ldif which give you the attributes for working with RACF etc.
Now what do I do?
It is much easier to set up your LDAP structure properly, before you start adding in lots of records, rather than try to change the structure it once you have populated it with all your data. You could be agile, develop your LDAP data, back up the data, and “just” recreate the LDAP repository once you know what you want. Where “just” means write Python or Rexx scripts to take the LDAP data and convert to the new format, for example adding additional information to every definition before adding it to the dictionary.
Because I did not fully understand how Access Control Lists work, I managed to make some of my data invisible to the end user requests, so it is easy to make mistakes when you do not know what you are doing. This blog should give you some hints about setting up your LDAP environment, and avoid some of the rework.
Background to LDAP
LDAP is a generalised directory with an application interface over IP.
The data is held in a hierarchical(upside down tree) form, for example the top of the tree may be called o=myorg. Where o stands for Organisation.
You configure this top of the tree in the LDAP config file for example
# this defines a file based database
database LDBM GLDBLD31/GLDBLD64
# this says it can use RACF for password checking
useNativeAuth all
#this is the top of the tree
suffix “o=myorg“
# this is the location on disk of the database
databaseDirectory /var/ldap/ldbm
The next levels down might be
- ou=users, o=myorg
- ou=groups,o=myorg
- ou=corporate data,o=myorg
The data for the first subtree could be stored in DB2, the data for the second subtree could be in files, and the data for the third subtree could be in another LDAP, somewhere else.
A “record” or leaf of the tree could be identified by
dn:cn=colin paice,c=GB,ou=users,o=myorg
Where
- cn= is the common name
- c= is the country name
- ou= is the organisational unit
- o= your organisation.
With each record you need one or more objectTypes. Object types have attributes. For example an objectType of person can have an attribute telephoneNumber. If you want to use telephoneNumber you need an objectType that supports it.
A typical entry might be
dn: cn=mq, o=Your Company
objectclass: top
objectclass: organizationalPerson
cn: mqadmin
telephoneNumber: 1234567
telephoneNumber: 987654321
sn: mqadmin
Logging on with z/OS userid and password.
I set up LDAP so I could logon to the Linux queue manager, and use my z/OS userid and password. For this I had
dn: cn=ibmuser, o=Your Company
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: ibm-nativeAuthentication
cn: ibmuser
sn: snibmuser
ibm-nativeId: IBMUSER
Where
- objectclass: ibm-nativeAuthentication is for the RACF authorisation
- ibm-nativeId: IBMUSER says use the RACF userid IBMUSER when cn=ibmuser, o=Your Company is used.
I also set up an Access Control List entry for this userid, so it can search, and read entries
dn: o=Your Company
changetype: modify
aclEntry : access-id:cn=ibmuser, o=Your Company:normal:grant:rscw
This says
- for the subtree under the distinguished name of o=Your Company. DNs of ou=groups,o=myorg, and ou=users,o=myorg would be more typical subtree names.
- the dn cn=ibmuser, o=Your Company, the dn of the user for this ACL. This would normally be a group rather than a userid. You can have multiple entries for each dn.
- has read, search and compare and write on normal fields. A social security number is “sensitive” field, and a password is a “critical” field. This ACL only gives access to normal fields.
What do you want in a year’s time?
It is much easier to set up your LDAP structure properly before you start, rather than try to change the structure it once you are using it.
For example you could have a flat tree with entries like
- dn:cn=colin paice,o=myorg for users
- dn:cn=mqadmin,o=myorg for groups
This will quickly become hard to manage. You may find the following are better.
- dn:cn=colin paice,ou=users,o=myorg for users
- dn:cn=mqadmin,ou=groups,o=myorg for groups
- dn:cn=testmqadmin,ou=groups,o=myorg for a different group with the department name in it.
or
- dn:cn=colin paice,c=gb,ou=users,o=myorg for users by country
- dn:cn=mqadmin,ou=test,ou=groups,o=myorg for test groups
Administration
You can give access to administer nodes in the tree, at the subtree level. For example for the sub node in the tree ou=test,ou=groups,o=myorg might have administrators.
- cn=hqadmin,ou=groups,o=myorg
- cn=colin paice,c=gb,ou=users,o=myorg
Having a structure like dn:cn=mqadmin,ou=test,ou=groups,o=myorg means you can give the test manager admin control to this test groups, but the test manager has no authority over the production groups. If you had a structure like dn:cn=mqadmin,ou=groups,o=myorg. It makes it much harder to separate the responsibilities.
For the top of the tree o=myorg, you could set up only the following group has administration.
- cn=hqadmin,ou=groups,o=myorg
From a performance perspective it will be cheaper and faster to access data in a subtree, rather than search the whole tree – bearing in mind you could have millions of entries in the tree.
Note: The adminDN userid in the LDAP config file has authority over every thing. The ACLs on the tree, or subtree, or record define who has administration authority.
Controlling access
You control access using Access Control Lists. An ACL looks like
dn: ou=users,o=myorg changetype: modify replace: aclEntry aclEntry : access-id:cn=ibmuser, o=Your Company: object:ad:normal:grant:rscw:sensitive:rscw: critical:rscw:restricted:rscw aclEntry: group:cn=authenticated:normal:rsc
This defines the access for the subtree ou=users,o=myorg
- cn=ibmuser, o=Your Company can add delete entries under the subtree; and use any of the fields including sensitive ( eg social security number) and critical (eg password).
- group: cn=authenticated any user who has authenticated can read, search and compare on normal fields. They cannot see or select on sensitive or critical fields.
- object:a|d is to add or delete objects in the subtree.
- normal:… sensitive… critical… these give access to the fields in the data ( so you can issue an ldap_search for example). You can specify <grant:|deny:> attributes, and so give access or remove access
- restricted: To update ACLs you must have read and write access.
- You can specify what access people have to individual fields, so you can give them access to most fields, but deny access to specific fields.
The userid defined in the LDAP configuration file under adminDN can change anything. When I messed up my data, I changed the config file to use adminDN cn=admin and password secret1, stopped and restarted the LDAP server, and fixed my problem. I undid the changes to the config file, stopped and restarted the server, to get back to normal operation.
You need to plan on what access you want, at which levels of the tree, and who has what access to which fields.
If is better to give access to groups, and add users to groups, than to give access to userids. For example, if you have many ACLs, if someone joins the team, changing the group to add the id is one change. If you have to change each ACL, and add the id, you may have many changes.
What is going to use it?
Programs using LDAP may have requirements on the data structure. For example MQ can use userid and group information in LDAP. It expects the data to be under a single subtree. You could specify groups are to be found under, ou=test,ou=groups,o=myorg. You cannot say under ou=test,ou=groups,o=myorg and ou=production,ou=groups,o=myorg. Similary, users would be under ou=users,o=myorg. If you specified the subtree c=gb,ou=users,o=myorg, then this limits users to having a GB userid, which may not be what you want.
Using groups
Although LDAP on z/OS can support static groups (with a list of members), nested groups containing groups, and dynamic groups ( where you can say those users with ou=production), the group of groups and dynamic groups cannot be used to check group membership.
You can query and display all users in all group types.
You can say give me the only the group names, where colinPaice is a member; when the group is a static group, not groups of groups, nor dynamic groups. This makes managing groups much harder, and you may need to have bigger groups than specific smaller groups.
You cannot exploit the flexibility of the nested and dynamics groups.
What fields do you want in the records.
If you have a definition like
dn: cn=ibmuser, o=Your Company
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: ibm-nativeAuthentication
cn: ibmuser
sn: snibmuser
ibm-nativeId: IBMUSER
If you want to use the ibm-nativeId field to give the RACF userid to use, then you need objectclass: ibm-nativeAuthentication.
If you have ibm-nativeAuthentication you must have ibm-nativeId, and may have other fields.
The “must” and “may” fields are defined in a schema.
The schema /usr/lpp/ldap/etc/schema.IBM.ldif has
objectclasses: ( NAME 'ibm-nativeAuthentication' DESC 'Indicates native security manager should be used during authentication.' SUP top AUXILIARY MUST ( ibm-nativeId ) )
The objectClass: person has
objectclasses: ( NAME 'person' DESC 'Defines entries that generically represent people.' MUST ( cn $ sn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
This means you must provide a cn and an sn entry, and you can provide other entries
The schema can give information about an attribute
attributetypes: ( NAME ( 'sn' 'surName' ) DESC 'This is the X.500 surname attribute, which contains the family name of a person.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch )
This shows that for ordering or comparing, it ignores the case of the data, so “colin paice” is the same as “COLIN PAICE”.
You need to decides what fields you want, and how you want the fields to be processed, for example case, and comparison.
You can write your own schema for fields that are unique to your organisation.
What you use the field for is up to you. For example “sn” could be surname, or”short name”. You just have to be consistent and document it.
What tools are there to help me?
You can use the tools provided with LDAP to administer LDAP. For example the ldap_modify command can be used to process a batch of definitions; whole records, or attributes within records.
Eclipse has a plugin Apache Directory Studio. It works well, and looks like it is highly recommended. This plugin allows you to browse and manage entries. I could not get it to display the schema.
How do I backup/export the data
You can use the ds2ldif command. It creates a file in ldif format which can be used to add back all the records (using the ldap_add or ldap_modify commands).
ColinPaice 