Difference in security between R5 and R6

OK, bit of an odd one this, and probably not a situation too many people have come up against, but I thought I’d throw this out to you lot to see if anyone has any idea…

Quick backstory: for various reasons I won’t go into, we’ve recently had to change the domain name of various users in the NAB. In order to allow easy updating of these people, I wrote a quick agent that scans through all the groups and converts from ‘Firstname Lastname/Domain’ to simply ‘Firstname Lastname’ - thus stripping off the domain bit. This now means I can mess around with the domain to my heart’s content, but user access to DBs remains the same throughout without having to modify groups every time.

Anyway, in Notes 5, this works absolutely perfectly - in Notes 6 however, it is denying user’s access to databases simply because the group doc contains only their name without the domain part stuck on the end.

So, I have a DB that replicates between an R5 and an R6 server. The ACL is identical on both. On the R5 box, the database and access control works perfectly. On the R6 box (which shares the same NAB), access is denied. Giving explicit access to ‘Firstname Lastname/Certifier’ resolves the issue, so it’s certainly the case that the R6 box is simply being more stringent on how specifically the user is named in groups.

In short, is there any way I can make the R6 box behave like the R5 one?

Subject: Difference in security between R5 and R6

Hello,

First of all, the domain is not included into the fully hierachical name of the user. The Domain can be found into the Domain field into the person document. So this is the OU or the O (Organizational Unit or Organization) certifiers that you do not have anymore.

So, why didn’t you just perform a ‘Move to hierarchy’ via teh admin process? This process will change the original OU/O to the new one and perform the change on every entry (Domino Directory, ACLs, Groups,…). The Admin Process is working well in both releases !

Here below follows an extract from the ND6 Admin Help. For more info, have a look at the admin help and search for “Moving a user name in the name hierarchy”.

When you move a user to a different Organizational Unit, the certifier changes, thus the user’s name hierarchy changes. Since the name hierarchy in Domino Notes is part of the user’s name, when you move a user to a different certifier you have essentially changed the user’s name. You can use the Administration Process to move a user name to a different location (Organizational Unit) in the organization’s hierarchical name scheme or to move a name to a different Organization altogether.

For example, if Alice Brown/Marketing/Acme leaves a job in the Marketing department for a job in Sales, you can certify her user ID with the /Sales/Acme certifier, which, in effect, moves her to that Organizational Unit. Her full hierarchical name then becomes Alice Brown/Sales/Acme.

You can also move a user to another Organization, however to do so, your Domino Directory must contain cross-certificates between the Organizations involved. So, for example, if Alice Brown/Marketing/Acme leaves a job at Acme to work for the Acme subsidiary AcmeSub that has its own Organization Certifier, you can certify her ID with the /AcmeSub certifier so that her name becomes Alice Brown/AcmeSub. Using this example, the Domino Directory must have cross-certificates between /Acme and /AcmeSub.

There are two parts to moving a user name:

  1. Request the move using the originating certifier.

  2. Complete the move by using the target (new) certifier to approve the request and issue the new certificate.

For information on using an agent to notify a user of changes to private design elements during a name change, see Notifying users of changes to private design elements during a name change.

HTH

Subject: This might be helpful …

In R5, if you don’t use an “O” in the name, Notes will assume it’s the same as the one of the server.Example: if “John Smith/Company” accesses the database on server “Europe/Servers” and the ACL contains (a group containing) the entry “John Smith”, his full name will not match “John Smith/Servers” and he will not be authorized.

Maybe this mechanism was changed in ND6 because of the problems it caused.

Subject: RE: Difference in security between R5 and R6

Thanks for that, it’s very useful, but the actual reasoning behind what we’ve done is a long and drawn out affair!

Ignoring the practicalities of the way we’ve gone about this; is there any reason that a group consisting of simply ‘Firstname Lastname’ users will work fine for access control in R5, but not in R6 (where it requires the O-unit of the user’s Notes ID)?