Franz,
I've had a "light bulb" moment.
I remember someone coming to present to the lab (over 15 years ago) about security, and how Role based security was better than group based security, and how attribute based security was even better. At the time I thought this was just the same as groups, and nested groups.
I ve been thinking that using dynamic groups was better than static groups - and that's where I was coming from. Your comments made me think "Ahh perhaps static groups are the answer". This was the light bulb moment. So my question about attributes is irrelevant.
There is a lot of documentation about "how to do things" (eg set up groups,set up ACLs), but I could not find much about why.
- Why would you use static groups over dynamic groups (see your good answer above)
- Why would you use dynamic groups over static ( Hmm that's a hard one)
It was hard to find any good doc on setting up your LDAP for authentication and authorization. For example
way 1.
- You have a central team responsible for setting up the access controls.
- There is a group called HRTEST which can access HR resources in test
- The LDAP team add and remove people as requested by the manager.
- Once a year the LDAP team have to send out to each manager a list of groups they are responsible for. They then check the list and confirm all of the people. etc
- If the audit is not successful the LDAP person gets into trouble.
Way 2
- You set up a group called HRTEST which can access HR resources in test
- People authorised to manage members to this group are the manager of the HR team and the LDAP people.
- Once a year the LDAP people send an email reminding the manager to check his group. The manager is responsible for doing the audit. (And the manager gets into trouble if the audit is not done - not the LDAP administrator)
- Internally there is another group called LDAPTEST which uses nested groups of HRTEST, PAYROLLTEST etc. If a new resource is protected by the HRTEST group, all authorised people get access to it, by just one change.
___________
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.
regards
Colin
------------------------------
Colin Paice
------------------------------
Original Message:
Sent: Thu October 14, 2021 07:47 AM
From: Franz Wolfhagen
Subject: Is there an LDAP attribute for group or role?
No reason to go away :-) - I have a lot of patience as long as we are moving forward....
First - let me explain a way to decide....
The reason to use a dynamic groups is to use data you already have registered - e.g. people sitting in OU or similar. As I hear your requirement this is not the case and a simple (static) group called MQADMIN would be the standard choice and then put in the members directly to that group using e.g. webadmin tool.
Why is that the way ?
It is quite simple - if you need to change membership to a dynamic role this would mean lookup the user and then change the attribute value of that attribute (or remove it) - when you have a simple (static) group it is basically the same - you add/remover the member attribute of the group (adding7removing the RDN of the user) - but if you use the webadmin console there is standard support for doing so....
and you will map the group cn=MQADMIN, <insert you placement in you ldap here> to the MQADMIN security in MQ - that is as simple as that....
HTH
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Thu October 14, 2021 07:32 AM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
Franz,
One final try ... then I'll go away.
When getting a list of userid for access control, does IBM have any recommendation on the attribute people should use when using dynamic groups. I can then give a userid this attribute and specify a value (say MQADMIN), and so be able to use dynamic groups to return all the user records with this value.
I think every one is telling me I need to create my own attribute, because the standard attributes (ou, sn, etc) have other meanings.
I could create any non existing attribute name, mqlist, mqrole etc.
Colin
------------------------------
Colin Paice
Original Message:
Sent: Thu October 14, 2021 04:24 AM
From: Franz Wolfhagen
Subject: Is there an LDAP attribute for group or role?
It was only examples of what you can do.
Your problem I believe is that you do not understand how groups work in ldap - you have lots of different group objectclasses supplied from the ISDS server - I mentioned two with the groupOfNames objectclass as the most normal/generic.
Groups are nothing else than entities that contains other entities - in the groupOfNames objectclass example this is the member attribute - using this you get some builtin support from ISDS in the form of operational attributes as I tried to explain.
I suggest that get some professional service to help you out - I have tried to explain the concepts of how it works here - but you do not seem to get it - a group is NOT represented as an attribute - it is an entity on its own premises - you can use the dynamic role concept to include members into the group based on an attribute - or assign/remove any RDN (this would normally be a user if you implment RBAC) as a member statically..
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Thu October 14, 2021 03:56 AM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
Franz,
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 say
Go and talk to the LDAP admin team, and ask them to define the following
dn: 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 1.3.6.1.4.1.1466.115.121.1.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.
regards
Colin
------------------------------
Colin Paice
Original Message:
Sent: Thu October 14, 2021 02:43 AM
From: Franz Wolfhagen
Subject: 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 member
As 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 Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Wed October 13, 2021 01:20 PM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
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.
Colin
------------------------------
Colin Paice
Original Message:
Sent: Wed October 13, 2021 04:30 AM
From: Franz Wolfhagen
Subject: Is there an LDAP attribute for group or role?
Let me try to explain a little on the core concepts - I will let you have the chance to comment these before going into details....
When you have user in a registry (that is the generic name of an ldap swerver - could be Windows AD, a database or any ldap server) you have basically three ways to denote a role :
- static membership - this means that a user is made a member - this is not based on ANY attributes inside the registry. In the ldap case this is a static group membership.
- Nested membership - this is also know as "groups in groups" - basically this means you get the membership to a group through another group membership.
- dynamic membership - this means that the membership is derived dynamically due to some attribute - the far most normal usage of this is organizational placements (e.g. ou attribute) or a type of person (typically based on an objectclass - this can either be derived (structural) or amended per entity (auxiliary)).
Now - these three options can be mixed/matched according to your need - but there is some restriction that the z/OS ldap server does not support - IIRC this a way of answering the question of a specific membership for a specific user - you can get the group memberships or the members of the group - but not the combination....
Let me know if this clarifies something...
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Wed October 13, 2021 04:02 AM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
Hi Franz,
Thanks for your reply and pointers to the web sites. I have spent a lot of time understanding page Examples of querying group membership. I can get it to work. (I set up a z/OS LDAP server for MQ Certificates and CRLs when I worked for IBM, so I once knew more about LDAP than I do now).
The problem I have is not an LDAP problem as such. Imagine I am trying to persuade a group of MQ sysprogs to use LDAP, and they need to configure the ldif files.
I explain the terms CN=, C=, OU=, O= etc and they are happy with this it is pretty clear. I explain static groups, people are OK with this. I explain about dynamic groups, it takes a bit longer, but they understand it
dn: cn=g5,o=ibm objectclass: container objectclass: ibm-dynamicGroup cn: g5 memberURL: ldap:///o=ibm??sub?(|(cn=u3)(cn=u4)) aclEntry: group:cn=ANYBODY:normal:rsc:system:rsc aclEntry: access-id:cn=u3,o=ibm:normal:rsc:system:rsc:at.ibm-allMembers:deny:rs: at.ibm-allMembers:grant:c
This has search on (cn=u3)(cn=u4). This is a search for common name(CN)
They say "so if we want to specify the name of a group a userid is in you are telling us IBM recommends we have to specify "CN" , which you just said was the userid's Common Name - it is nothing to do with groups, roles or permissions. Why can't you use GROUP=?"
and that's my key question.
It is a bit like having information about cars. 'brand=skoda, passengers=4, colour of car=diesel' because there was no attribute called fuel type, so they used an existing attribute even though it is the wrong one.
Yes, I can use any attribute - (I used "state" for mine) but the obvious one of group or role are not in the schema by default.
Does this help explain the novice's perspective?
Colin
------------------------------
Colin Paice
Original Message:
Sent: Tue October 12, 2021 02:51 AM
From: Franz Wolfhagen
Subject: Is there an LDAP attribute for group or role?
I have been following your attempts to connect MQ to your (mainframe ?) ldap server using groups as authorization mechanism . I believe you need to study how ldap actually works - normally I recommend this site LDAP for Rocket Scientists. This site covers mainly the OpenLdap implementation (with some other ldap servers) but not the IBM Security Directory Server (ISDS).
One thing that is important to understand is that the ldap RFCs that defines the ldap protocol dos not cover all aspects of how groups ar implemented - that causes a lot of pain when comparing the different ldap servers. ISDS implements group memberships through an operational attribute (ibm-allGroups) as described here (for the z/OS version of the ISDS which is a little different from the distributed versions) Examples of querying group membership
I hope that example shows you how you can combine the ISDS standard groups with the ibm-allGroups to solve you authorization problem.
------------------------------
Franz Wolfhagen
IAM Technical Architect for Europe - Certified Consulting IT Specialist
IBM Security Expert Labs
Original Message:
Sent: Sun October 10, 2021 12:39 PM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
Jon,
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.
regards
Colin
------------------------------
Colin Paice
Original Message:
Sent: Fri October 08, 2021 06:19 AM
From: Jon Harry
Subject: Is there an LDAP attribute for group or role?
Hi Colin,
On the subject of OIDs, it is true that the officially correct way of creating a custom attribute is to use an OID registered with IANA. This prevents clashes if you were to merge records with data from another LDAP schema in the future.
In practice, I've mostly seen people simply set the "OID" for a custom attribute to be the same as the attribute name - i.e. not really an OID at all. IIRC, IBM Security Directory Server accepts any string in that field.
For the United Kingdom, I did come across this document (http://www.oid-info.com/get/1.2.826.0) which indicates that every registered company in UK has their own OID based on their registered company number. I couldn't find anything for other countries but perhaps something exists?
There's also this OID branch where you can just add a UUID: http://www.oid-info.com/get/2.25
Caveat: I'm not an expert in this space but came across this stuff with a bit of searching around.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
Original Message:
Sent: Thu October 07, 2021 12:08 PM
From: Colin Paice
Subject: Is there an LDAP attribute for group or role?
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-4
administrativeRole 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
------------------------------
Colin Paice
------------------------------