I am considering the use of the unique organisational unit to replace the OU element of user names for new accounts and am interested in any experience in the use of this option.For example are there any implications\considerations for moving to a flat naming convention
e.g. from John Smith/Manchester(OU)/Company(O) to
John Smith/StaffNumber(unique OU)/Company(O)
We do not use the geographical OU element of a users name to manage access to db’s etc and the OU is now less meaningful for a lot of users as it is out of date. The advantage in use of the unique OU appears to be use of a single cert ID to register accounts (0), unique name based on staff number and no overhead in renames at OU level.
Any advice or suggestions on reading material in this area appreciated, thanks.
Org Units are handy if you wish to delineate groups of users that may have similar access. For example, you can use wild cards such */Accounts/Acme to provide bulk access to a subset of users in your org with that cert. However, if you no longer have logical OU’s or your OU’s are no longer fit for this purpose then you might as well get rid of them. Moving from many certifier ids to just one will make user admin tasks easier. I’ve always thought of flat names as Joe Bloggs@NotesDomain. These are not advisable becuase they are not very secure at all. However, I don’t see any security risks in what you are suggesting; as long as you keep the O unit then your naming system will still be hierarchical. Note that you are potentially talking about moving all users to a new certifier and that is a significant undertaking in a large organisation.
Regarding your plan for adding optional OU based on employee id; I can’t see the attraction here. Adding an optional OU for each user is going to mean an individual rename for every user in your company and this seems like a whole lot of time and effort to me. I would never do it. What benefits would be gained? The only time I ever use optional OU’s is for ambiguous usernames (eg. you might have 2 John Smiths in your company) and I always favour this method over middle initial. In cases of ambiguous names, the best method is to use department or job title as the optional ou because it helps other users distinguish between the two when they are resolving the ambiguous name during mail addressing.
John Smith/Accounts/Acme
John Smith/IT/Acme
In my org, using something like employee number would not help our users pick the correct recipient because most of our employees don;t even know their own emp number, nevermind anyone elses!
Thanks for taking the time to respond. The idea behind this approach is two fold a) to help to automate the Notes account creation process by programmatically feeding in a users staff number (known value) as the unique OU element in place of the existing geographical OU element (variable) and use a single O certifier to register accounts and b) replace the outdated OU element with a value that is meaningful, unique and does not change. Was considering just implementing this for new starters as appreciate a global user rename exercise is not to be undertaken lightly though a standard naming convention for all is preferred - hadn’t considered losing the OU altogether though I guess that the admin overhead to remove the OU is the same as removing both the OU and adding a unique OU. Staff are familiar with staff numbers in this organisation which would add some value to users if faced with name conflicts - middle initials are currently in use which are not particularly helpful and not always available. Queried the use of unique OU in place of the OU with IBM and made the mistake of using the term ‘flat’ which confused the question and led to an initial response that true flat names are not supported. Thanks again for thinking this through, re assuring to hear that there are no hidden gotchas other than the admin overhead if renaming, cheers.
You said: “I guess that the admin overhead to remove the OU is the same as removing both the OU and adding a unique OU”
It depends how your geographical OU’s have been applied.
ie.
An optinal qualifying OU after someones common name eg. CN=Joe Bloggs/OU=London certifed under the O=Acme certifier…
…is not quite the same as…
A proper OU that is part of the certifier eg.
CN=Joe Bloggs certified under the OU=London/O=Acme certifier
The certificates view in the nab will indicate exactly what proper certifiers exist in your domain.
If yr geo OUs are inherited from proper certifiers (as in the second example above) then it’s possible to move a whole bunch of users to a new O level cert as a batch and the job is done (pending adminp etc). Changing common name would not be required.
But if they are optional OU’s that have been introduced ad hoc per user then you may be looking at renames per user to get rid of them, and that’s in addition to the cert move too. I’m not 100% on this point. The question is: when you move someone to a new cert, do any optional qualifying OU’s drop off or are they retained? My guess is that they are retained (leaving you alot of work to do) but I think you might want to test this first, if you find that you are using lots of optional qual OUs.
OU’s are inherited from O certifier - will test renaming a sub set of users before weighing up effort\risk\value in renaming all users or just new starters, thanks again.
Have discovered that flat names are not supported from R7 onwards.
I will now work on the basis that at least one OU is a minimum requirement though the unique organisational unit can be used in conjunction with an OU and test if adding a unique organisational unit forms part of the standard renaming steps.
so you want to create a unique OU for every user based on their staff number? That would be a nightmare to manage and I don’t recommend it. Keep it simple when it comes to the use of OUs.