In my earlier post I talk about the new qvault command available with v12 of Domino. I wrote that post but then couldn’t publish it because when I tried to run “load qvault..” with any parameter I got the error
QVR - The local security feature is not supported for the database or server The local security feature is not supported for the database or server
I opened a support call and was told that the notes.ini setting IDV_Enable_Vault_Scan = 1 must be set on the server and the server restarted before the qvault command will work without error which I tested and confirmed.
As I posted last week, Domino 12 and Sametime 11.6 and Traveler 12 and Nomad Web 1.0 are all out and there’s lots of good news for admins, users and developers alike but since I’m an admin that’s what I’m going to talk about. Instead of a large dull blog listing all the things I think are most interesting useful, I’m going to do a series of short slightly-less-dull blogs focusing in on each one individually.
This isn’t where I tell you to deploy ID Vault - you’ve already done that right? ID Vault not only contains encrypted secured copies of all your IDs but it allows admins to do password resets against Notes IDs directly on the server and have that immediately take effect for the user. It also means never having to physically copy ids around to workstations and it can be set up in 10 mins so a lot to like but Domino 12 brings us some very welcome enhancements. If you already have an ID Vault then don’t forget to refresh its design from the v12 template called idvault.ntf on the server.
Manually Uploading An ID To The Vault
It’s now possible for both administrators and users to upload IDs to the Vault manually. Users can only upload their own IDs but anyone designated as a vault administrator can upload any user ID into the vault.
To do that as a User, open the server’s names.nsf in your Notes client, choose the People and Groups view and right mouse click (it will only let you upload your own ID). You will then be asked to upload the ID and confirm its password.
To do an ID update or multiple ID updates as an Administrator go to the People & Groups view in Domino Administrator and selectUpload ID into Vault from the Action menu. Note it is only available via the actions menu and not via right mouse click in the Admin client. You can then choose if you are uploading a single ID or multiple IDs. Since you are supplying the password the Vault will be able to unlock the ID and know what user it belongs to.
If you want to upload multiple IDs then you need to create a 2 column, comma separated CSV file where Column 1 = a path to the Notes ID relative to your client machine Column 2 = the password for each Notes ID
For background, a vault administrator is different from a server administrator and isn’t set by server security but by ID vault security.
New Query Vault Command if you have errors running this command such as “QVR - the local security feature is not supported” see my next blog and verify you have the notes.ini setting IDV_Enable_Vault_Scan = 1
Referenced in detail here but just to highlight two commands I will use a lot
“load qvault -x {vaultname} -u {username} -a (for archive) - this is for if (when) an ID stops syncing into the vault, this command archives the existing vaulted ID and that will tell the Notes client to sync its ID into the vault thinking there isn’t one there alreaady.
“Load qvault -x {vaultname} -u {username} -i OR -v (i for “inactivate” and v for “reactivate” an ID)
let’s break that down - what is your vaultname? To find that go to Domino Administrator and the “Configuration” tab and then on the left hand side choose ID Vault under Security. Your vault will show in the view to the right and the first column contains the Vault Name. What will display will have a “/” in front of it but in the actual name that is replaced by O= so in the screenshot below my vault name is O=DemoVault.
Of course you can also look at the document properties for the field “VaultName”
What is your username?. That is the canonical format of the first entry in the fullname field of the person document (the static text for that field is “User Name”). So for “Gabriella Davis/Turtle” that would be “CN=Gabriella Davis/O=Turtle” Don’t forget to use quote marks as there are spaces in the user name and the command line on the console won’t like that without quotes around it.
So now we have the command to inactivate user “Graham Hedley” **
or to archive Graham Hedley’s existing vaulted ID so the one being used by his client can be vaulted in its place
load qvault -x O=DemoVault -u “CN=Graham Hedley/O=Turtle” -a
The qvault command is used for maintenance of the ID Vault and can also archive IDs in the vault as well as cleanup already archived IDs. See here for full documentation.
Two new features related to groups I do really like and think I will use a lot.
Find Groups
Starting with the simplest - the ability to see what groups a person is in by selecting “Find Groups” from their person document. Yes we have had some of this before in the form of the “Manage Groups” dialog in the People and Groups view but this is more detailed, and most importantly printed on screen.
Open any person document and click “Find Groups”
The system will think for a moment then open up a new page with all of that user’s groups listed in it. The group names in the first column are clickable and will open the group document. The 2nd column shows what entry in the group grants that person access if it’s not their explicit name and the third column will show any nested groups that put them in the named group.
AutoPopulating Groups
I am betting the new custom autopopulate group feature is going to be heavily used. Certainly by me. We have had the ability to auto populate groups for a while but only by user’s home server never by anything else. Now in v12 we can have groups autopopulate according to any LDAP search we want. For example let’s say I wanted a group that kept itself updated with the names of all people in the Domino Directory having the last name “Davis” (just for giggles). So here I’ve created a group, set it to “Custom” auto populate and written an LDAP syntax that searches for any documents flagged as “person” that also have the last name of “Davis”. We are also able to add other members to the group who otherwise wouldn’t be in there such as Mike Smith and even exclude members.
After saving and closing the documents , I checked a few minutes later and my group now shows this, as you can see it has put two Davis’ in the group and added Mike Smith as an additional member. That group membership will continue to be maintained.
You do not need to be running the LDAP task on your server for this to work.
Now think about how useful that is. Groups of people all sharing an internet domain (&(ObjectClass=person)(mail=*.turtleweb.com)) or all at a particular location (&(ObjectClass=person)(Site)). This can be used for any kind of groups including security so if you want to restrict people’s access to an application by their department for instance you can build an autopopulating group that does that.
What if you don’t know how to construct LDAP search syntax? Well it’s not very hard you just need to know some basic rules. When I save the group document it will do a simple LDAP syntax check to make sure your brackets and ampersands look right but you might want to build your search criteria using an LDAP browser yourself first to make sure it’s giving you what you need. I’m a big fan of Softerra’s LDAP Browser which is both brilliant to use and entirely free https://www.ldapadministrator.com/softerra-ldap-browser.htm.
To help you build your syntax it’s good to understand how Domino fields map to LDAP attributes and that is defined in the schema.nsf on your Domino server. The schema.nsf is created or pulled by a server the first time LDAP is run as a task so if your server does not have a schema.nsf just “load ldap” then “tell ldap quit” a few minutes later and one will appear.
For the most part we never touch the schema.nsf but here is an example of its contents that would allow you to see the mappings between fields and attributes.
Lots of great updates for internet security in Domino 12 and for me some of the smallest changes will make the biggest impact to my daily work. For instance, Domino continues to support its proprietary kyr keyfile format but now also supports the PEM format which is commonly used by many web servers.
You can create a PEM file using any text editor and pasting the entire certificate chain into it in the order
Private Key
Server CA certificate
Intermedia certificate
Trusted root or chain certificate
Save the text file with a .pem extension and you’re NEARLY done.
NEARLY - Daniel Nashed has informed me that the process was changed at the last minute for GA and the only way to get the PEM key recognised by Domino is to import it once created using
load certmgr -importpem {filename}
Of course the new approach is to use certmgr for everything from creating the private key and csr through to importing the final PEM and I have another blog ready to go on that as there’s a lot more to certmgr that we need to discuss.
Such a simple thing that will again save me a lot of time. Open your server document and you now have an option to find and view any configuration document that server is assigned to. Click “Find Server Config”
and the dialog box will offer any configuration documents that server is assigned to. In this instance a configuration for Clouds/Turtle specifically as well as the default [All Servers] configuration which is where the LDAP settings are defined.
The Turtle Partnership Blog 