Anonymous_User Absent Member.
Absent Member.
232 views

Schema design CN attribute


I posted in the eDir forum regarding the choice of CN attribute for a
new identity vault.
Cross posting here as well to possibility reach a wider audience.

If you have any advice on the choice of CN for an IDV, please comment in
the thread linked below.

http://tinyurl.com/k2j5275


--
hscheff
------------------------------------------------------------------------
hscheff's Profile: https://forums.netiq.com/member.php?userid=7118
View this thread: https://forums.netiq.com/showthread.php?t=50385

Labels (1)
0 Likes
7 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute

The comments over there are valid. I'll post my response that you have
seen in other places here just for fun:

It may help to know a bit more about the objects that will be stored in
there. For example, faculty, staff, students, just while they work/attend
there or also for all alumni? Will you ever have a need to move objects
between containers (to alumni, to inactive, etc.) at some point in time,
and what will happen in connected systems at that time (do the same thing,
leave them alone, disable them, delete them, etc.)?

I'd never name an object the name of a person (#1)... duplicates become
painful immediately, plus some places have privacy issues that this can
make painful. Usernames are common, though what about when a person
changes names and now not only are you updating givenname/sn but you're
also renaming the object, perhaps needing to rename in other systems, etc.

Currently my personal preference, however impersonal it is, is some kind
of unique identifier that's a number. I'd probably always prefix it by a
letter, either chosen for everybody ('a') or to somehow indicate a type of
user ('f' = faculty, 's' = student, 'a' = alumni', x = 'IT administrator')
but with those you could still have a problem of renames as a person
changes roles, and what if they are in multiple roles (student and IT).
The number is often something that can be assigned and is memorable as the
official student number, employee ID, etc., so it is both known and,
fairly private (the number doesn't let somebody who stumbles onto it
immediately know who owns it), and doesn't require changes over time due
to life/role changes.

The only perceived benefit of #2 over #3 is that it's potentially easier
for somebody to know their RDN, which is usually a CN or UID attribute.
For an individual, that's nice, but it doesn't apply to others, like some
have said about the helpdesk being able to look up people. There is no
perfectly-reliable way for a username comprised of user data (first
initial + lastname, first name plus last initial, first initial, middle
initial, lastname, etc.) to have perfect correlation to a user since
you'll always end up with duplicates, and then you're in the same
situation needing to find interesting combinations of parts of names or
adding integers for uniqueness. For example, the helpesk cannot always
know that user 'John Smith' is always 'jsmith' because of the guy in the
organization named 'Joe', the other one named 'Jared', and that annoying
one named 'James'. Two letters of givenName and the surname do not help
much more, since in that example I just gave you have two jasmith and two
josmith users.

If possible, #3 means the least pain for IT administration, in my opinion,
an if you have well-written application authenticating using LDAP you can
often do something like set the UID to something that is more-easily
understood (the username from #2) but can then let the user request
changes if they really want to, since that's just an attribute change and
you can force uniqueness at any time. I've done work for customers in the
past that did just this and so if a user did not like their loginName
(which was NOT their CN, but was their UID) they could request a change to
a new value. If they changed names (for any reason) they could
automatically have that loginName (UID) updated. All the while the object
in eDirectory always stayed named a12345 so the pain with renames was
eliminated. The IT folks always knew which user was being discussed since
if it was a12345 they knew it was the RDN/CN, and if not they knew it was
the UID.

Just some thoughts,
AB

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute


AB, thanks for your thorough reply!
Much appreciated.

The vault will store ALL identities associated with the university, i.e.
staff, students, alumni etc.
We are still finalising the schema, but my idea is to have as flat as
practical structure in the vault.
The current proposal is to have separate containers for high level role
types i.e. students, staff, alumni etc.
So yes, moves will be required according to primary role (stored as
attribute).
What needs to happen in the connected systems will vary per system, but
for AD the objects will be moved there too (alumni are removed from
AD).

My personal preference is for CN = student / staff / person number (all
the same thing), with a separate attribute storing the username / login
id.
Glad that at least some on this forum agrees 🙂
In our case all persons are issued with a unique 8 digit number (from a
single range, irrespective of role) when their details are first
captured by the source system (HR, student enrolments or visitor
system).
There is no apparent reason why this system should change in future, but
strange things do happen...

The alternative is to introduce yet another unique number generated by
the vault when creating a new object.
This number will in practice be meaningless to all humans rendering CN
not very useful, but does have the advantage that it is not influenced
by any external change.


--
hscheff
------------------------------------------------------------------------
hscheff's Profile: https://forums.netiq.com/member.php?userid=7118
View this thread: https://forums.netiq.com/showthread.php?t=50385

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute

On Fri, 28 Mar 2014 15:14:01 +0000, hscheff wrote:

> The current proposal is to have separate containers for high level role
> types i.e. students, staff, alumni etc. So yes, moves will be required
> according to primary role (stored as attribute).


I wouldn't even do that, because then you have to solve the "what do I do
with Bob who is an employee AND a student AND and an alumni?" problem in
your vault.

Make a single "A1234567" user in your vault and tie organizational roles
like "student" and "employee" to it, which can be used downstream.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute

David Gersic wrote:

> On Fri, 28 Mar 2014 15:14:01 +0000, hscheff wrote:
>
> > The current proposal is to have separate containers for high level role
> > types i.e. students, staff, alumni etc. So yes, moves will be required
> > according to primary role (stored as attribute).

>
> I wouldn't even do that, because then you have to solve the "what do I do
> with Bob who is an employee AND a student AND and an alumni?" problem in
> your vault.


or a student who is also an assistant instructor. Or countless other permutations.


> Make a single "A1234567" user in your vault and tie organizational roles
> like "student" and "employee" to it, which can be used downstream.


Also, define a primary role for downstream systems that aren't capable of (or don't need) multiple roles.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute


We will be using CN = student / staff number for the vault.

At present we have approximately 650 000 identities (growing annually).
Would it be wise/practical to have all these objects in one big flat
structure in the vault?

The line between student and staff is often grey making it difficult to
determine which role is primary.
A flat structure with all objects in one container will solve this
problem.

We do have a primary role attribute in our vault schema, which could be
used to move objects between containers and for connected system that
only accept one role.

Perhaps only have a separate container for alumni (bulk of the
identities) ?
Alumni are de-provisioned from most of the connected systems in our
case.


--
hscheff
------------------------------------------------------------------------
hscheff's Profile: https://forums.netiq.com/member.php?userid=7118
View this thread: https://forums.netiq.com/showthread.php?t=50385

0 Likes
Knowledge Partner
Knowledge Partner

Re: Schema design CN attribute

hscheff wrote:

> At present we have approximately 650 000 identities (growing annually).
> Would it be wise/practical to have all these objects in one big flat
> structure in the vault?


I have not worked with that many objects in a single container yet, but you can
always use separate containers e.g. for all CNs starting with a certain digit
or even the first two or three digits, which will instantly get you 10/100/1000
containers to spread out the objects.

> The line between student and staff is often grey making it difficult to
> determine which role is primary.
> A flat structure with all objects in one container will solve this
> problem.


Containers should not be seen as solution to this "problem" in an ID Vault.
Actually this "problem" is solely an issue of human perception when looking at
the tree (which usually only admin do anyway), nothing that influences IDM
functionality or efficiency in most cases.

> We do have a primary role attribute in our vault schema, which could be
> used to move objects between containers


Do NOT move objects around as part of every-day processes like role changes.
Moving and renaming are the most expensive operations in Edirectory in terms of
performance and side-effects. If possible, do not move objects at all, ever.
A common compromise is to disable accounts e.g. for a year in place and only if
they did not get reactived that long, move them into a "retired" container (or
delete them). Moving objects around just because a role changes or a an
assigned office location or whatever you may fancy as sorting criteria is just
calling for trouble, especially with large environments like yours.
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Schema design CN attribute

On Tue, 01 Apr 2014 17:24:02 +0000, hscheff wrote:

> We will be using CN = student / staff number for the vault.
>
> At present we have approximately 650 000 identities (growing annually).
> Would it be wise/practical to have all these objects in one big flat
> structure in the vault?


eDirectory and IDM don't care how many objects you put in a container.
Some of the older management utilities may object because they'd try to
display all objects at once, but iManager pages its results so it works
fine.


> The line between student and staff is often grey making it difficult to
> determine which role is primary.


Right. And some of your alumni are also employees, which may also be
students at times. In my worst case, I had one person that was
simultaneously faculty, student, employee (staff), retiree, and alumni.


> A flat structure with all objects in one container will solve this
> problem.


Yup.


> We do have a primary role attribute in our vault schema, which could be
> used to move objects between containers and for connected system that
> only accept one role.


Use that to provision the connected systems with the correct account.


> Perhaps only have a separate container for alumni (bulk of the
> identities) ?
> Alumni are de-provisioned from most of the connected systems in our
> case.


You could. I wouldn't.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.