I want to set up user records, and have an attribute like role: or group:, so I can implement virtual groups.
I looked in the /usr/lpp/ldap/etc/schema.user.ldif and the /usr/lpp/ldap/etc/schema.IBM.ldif schema, but nothing seemed to fit the requirement.I looked in https://www.iana.org/assignments/ldap-parameters/ldap-parameters.xhtml#ldap-parameters-4administrativeRole which has organizationalRole, and pcelsrole, which feel wrong.I created a bit of schema to provide this attribute, but the IBM doc says I need a uid from IANA for my personal use. This feels the wrong way of doing it for a general purpose attribute.This feels like a common problem, am I missing something obvious, or do I have to hijack attributes like use "st".Is there a general purpose "free" oid which people can use as they wish instead of getting one allocated to them?Colin
Thanks again for helping me. I think I'll follow the"add a UUID: http://www.oid-info.com/get/2.25" route. and blog how to set up a role and or group in LDAP.
I've written a set of blog posts about using LDAP on z/OS ( and MQ with LDAP) under I've started LDAP, now what do I do?, So I'll blog here.I'll try to get LDAP working with MQ using TLS. Once it works I'll blog that as well.regardsColin
Hi Franz,I've had all those working. I'm looking at dynamic membership. Looking at what you suggested.
I think any example of ou would be ou=test|development; An example of "type of person" would be manager. What attribute would be good for "role" or "access group" - I could not find one.See my reply to Aki below.
I do not have a "isManager" attribute, or an objectclass=consultant.. What I keep hearing is that I need to change the schema to define the attributes I want to use, because there are non suitable in the default schemas. There is no convenient attribute I can use.Instead of giving instructions to the MQ admin people.For members of the MQ Admin team, add an entry "mqgroup: MQADMIN" to each person.Define a dynamic group with mqgroup=MQADMIN.Once these have been done, you can use the dynamic group name in mq.I have to sayGo and talk to the LDAP admin team, and ask them to define the followingdn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3..... NAME 'mqpgroup' DESC 'Colins group for MQ' SUP name EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 18.104.22.168.4.1.1422.214.171.124.15 USAGE userApplications ) ibmattributetypes: ( 1.3.6..... ACCESS-CLASS sensitive) Once they have done this, you can add the mqgroup attribute to the users in the MQADMIN group.Define a dynamic group with mqgroup=MQADMIN.Once these have been done, you can use the dynamic group name in mq.I had hoped that there would have been a "group" or "role" attribute provided in the base schema which people could have used without having to ask a schema change, especially after the "Role Based Access Control" I've been reading about.I've worked with customers, where making small changes can be done immediately, but changing the configuration ( the schema in this case) can take a week, as it has to go through the change review process.regardsColin
------------------------------Colin PaiceOriginal Message:Sent: Thu October 14, 2021 02:43 AMFrom: Franz WolfhagenSubject: Is there an LDAP attribute for group or role?You are mixing concepts here - when I am speaking of "type of person" the distinction is on the attributes that are available to describe the person.Example : you want to have different attributes for an internal/employee and a external/consultant. In most cases you would add the custom attributes as an auxiliary objectclass to the inetorgPerson or create a new structural class inheriting from inetOrgPerson - it depends on your usecase and need for flexibility.Now let's assume you haver users in ou=users,dc=com and groups in ou=groups,dc=com in you ldap tree. you have created a group cn=managers in ou=groups,dc=com as objectclass groupOfNames and added ibm-dynamicGroup as auxiliary class (or using the structural class groupOfURLs) .When creating the group (and here you need to give it a cn as name - that is how the objectclass is defined - you can create you own objectclass for group objects - but there is really no reason to do that) - you will also need to add the first member (this is somewhat irritating as you may want to have groups with zero members - this is a simple change of objectclass to make the member optional instead of required) - the member can be ANY RDN in your tree - this is JUST a grouping of objects/entities..... That will give a group with a static memberAs you have added the objectclass ibm-dynamicGroup you can also add members dynamically usin the memberUrl attribute of the group. Assuming that a manager has a boolean attribute "isManager" and you want to include those automatically you should enter a value of "ldap:///ou=users,dc=com??sub?isManager=true" (I have here used subtree searchscope) - similar if you want to have consultants (by objectclass) you can use the memberUrl "ldap:///ou=user,dc=com??sub?objectclass=consultant" assuming you have an objectclass named like that..Does this make the group creating more clear ?Now - the application will normally match one group as an access entitlement e.g. cn=admins,ou=groups,dc=com as Administrators - this is basically a group to security mapping - each mapped entitlement should have at least one group mapped.When the application is looking at the user (mapped to a unique attribute under ou=users,dc=com in the example - e.g. uid (advice - do not use cn - it should be the fullname of the user - it is multivalue attribute and is probably not unique) it must retrieve all the group memberships the user possesses - this mapping can then be done using the operational attribute ibm-allGroups - this will retrieve any direct/dynamic/nested membership in ISDS - if you were using e.g. Windows AD you would have to use another way (it has some special ways of retrieving dynamic/nested groups in different ways depending on your needs)I hope this clarifies the things...------------------------------Franz WolfhagenIAM Technical Architect for Europe - Certified Consulting IT SpecialistIBM Security Expert LabsOriginal Message:Sent: Wed October 13, 2021 01:20 PMFrom: Colin PaiceSubject: Is there an LDAP attribute for group or role?
___________Way 2 seems a much better solution. I was not able to find any guidance on how to set these up - does this guidance exist? It is easy to make mistakes (I put an ACL on a record, and it "disappeared" from MQ - because MQ was not authorised to see it)The LDAP red book is a "how to implement" ... not a "why you should" or "planning an LDAP configuration- before you set your configuration in concrete"I wrote "I've started LDAP - now what do I do" to help people get started - especially people on midrange using MQ.__________________
Is there any official doc to help with these sorts of upfront decisions.regardsColin