You need to add Unique ID (UID) attributes for all users.
To have your UIDs all set up nicely based on the CN values, follow the steps below. These can, of course, be used to duplicate any attribute's values to any other attribute but this is semi-common in situations where UID is missing because of the use of older tools (NWAdmin) or LDAP for user creation. In this case, we're going to copy CNs directly to UIDs and focus specifically on the User class, because that will be the most common solution.
First we need an LDAP client of some sort. Something like LDAP Browser/Editor may work, but I'll be using the command-line in Linux (OES servers, SLED/SLES boxes will all work). These commands with minor modifications should work with the ldapsearch in the (by default)
c:\novell\consoleone\1.2\bini directory for those in Windows.
As another note for doing this to the least common denominator, it is possible that some LDAP Server or LDAP Group objects are set up to only allow secure connections, and this is definitely not a horrible idea. The command I'll be using should work with default installations, but some extra work may be required to actually bind to port 636. This is simple enough (export certificate, use it with -e parameter in Windows ... also, LDAP Browser/Editor can connect without a manually exported certificate). If you get an LDAP error 13 during any of this, Google with the following parameters to get on your way (without quotes): 'site:novell.com ldap confidentiality required 13'.
So, on with the work. First let's get an export of everybody lacking a UID who is a user. Also with the export we are ONLY going to get the CN attribute instead of all attributes (makes life easier).
1. Run this command:
ldapsearch -h ipAddressHere -p 389 -D cn=admin,dc=user,dc=system -x -ZZZ
- -W '(&(objectClass=User)(!(uid=*)))' cn
Windows users will need to take out the single-quotes when running from the command-line as, for some reason, the command prompt can't handle them.
This will give you tons of output to the screen with about two lines per object. The first line has the DN, and the second has the actual attribute's values. With this going to the screen, there's not much we can do at this point.
2. Redirect the output to a file by adding '>someFile.ldif' to the end of the previous command.
Note that if you do not see the prompt for the password (as you should have before) just type it in and press Enter. It will go to the file properly. Sample output follows:
Once this is done, we need to do some interesting stuff to get this ready to re-import. Some of it can be done with a lousy text editor like Notepad. For a better text editor, I enjoy JEdit - but I have also used UltraEdit and EditPlus, and I have coworkers who enjoy TextPad. JEdit is completely free and runs on all platforms; the others all have trials that don't expire, as I recall. gedit, kate, and vi are also great solutions.
First things first: at the end of your output file will be a couple lines that are NOT commented out (#), that talk about Search Results.
3. Delete those lines from the output file.
result: 0 Success
Part of the preparation to import the file is just changing 'cn:' to 'uid:' - which we will then import.
4. To do this in vi, type the following string after opening the file (vi someFile.ldif):
That's running a search/replace function throughout the file, replacing 'cn:' with 'uid:' when 'cn:' is at the beginning of the line. The same thing can be done with most editors by searching for 'cn:' and replacing with 'uid:'. However, be careful that 'cn:' isn't anywhere in the LDIF you don't want it (in a value, for instance) - but it really shouldn't be.
The next step may require something more than Notepad, because we need to actually work with new-line characters. This will be simple in a capable editor, and I'll show how it is done in vi as well as JEdit. For other options you may need to port the expressions on your own (sorry). I know OpenOffice can do Regular Expressions as well, so I'll include that (although the last time I used Microsoft Office it was not capable, so I can't help there). Either way, a regular text editor (not a document publication suite) is recommended for doing things like this, because there aren't little nuances like quotation marks that will foul up what we're doing. gedit (Linux) also does this type of searching and replacing by default with the same syntax as OpenOffice.
In our file we should now have the following:
5. Open this file with OpenOffice Writer.
6. Go to the Edit menu and choose Find & Replace.
7. In the 'Search for' field, type 'uid:' (without quotes).
8. In the 'Replace with' field type the following string:
changetype: modify\nadd: uid\nuid:
9. Click the More Options button at the bottom.
10. Check the 'Regular expressions' checkbox and click Replace All to actually do the replace. The new page should have the following (there may be a delay if you have tons of users):
This is our completed file at this point.
11. Save it back out as a plain text document (no special formatting at all; this is important).
Just to have a little fun this step, the previous search/replace can be combined by simply changing the value in 'Search for' to 'cn:'.
12. In vi the command would look like the following:
:%s/^uid:/changetype: modify\nadd: uid\nuid:/
This step and the previous could also be combined into the following:
:%s/^cn:/changetype: modify\nadd: uid\nuid:/
The output from this should match what was shown above.
13. Save the file and exit vi (:wq).
Lastly, JEdit works the same way via the 'Search' menu.
a. Click Find and then fill in the same Search and Replace strings used for OpenOffice and gedit.
b. Under the Settings column check the 'Regular expressions' checkbox.
c. Click Replace All' to apply what we have done so far. As mentioned before, these two search and replace functions can be combined (same as OO.o and gedit) if you want to be really efficient.
14. Save the output, regardless of the program in use.
So now we have a file formatted as shown above for all users. The next step is the import, which is just like the export but with ldapmodify (vs. ldapsearch), no filter to find users (we're not finding anymore), and a parameter to specify the file to import.
15. Run the following command:
ldapmodify -h ipAddressHere -p 389 -D cn=admin,dc=user,dc=system -x -ZZZ
- -W -f someFile.ldif
You will be prompted for a password again for the user specified. When that starts, you will see a number of lines like the following, one for each user:
modifying entry "cn=test0,ou=finance,o=novell,dc=org"
modifying entry "cn=test1,ou=finance,o=novell,dc=org"
If you run the original ldapsearch query again, you should not get any users back out unless they failed to be modified. So there you have it.
In about 3 main steps (export, modify file, import) we have "copied" all CN values to UID values. Some caveats in weird environments may deal with case sensitivity or multiple CN values. For instance, if you have multiple CNs, you will not have multiple UIDs. Also note that if you are using Linux User Management (LUM), the UID is used for the username on the Linux machines, and it IS case-sensitive for the username. For this reason, you may want to make all usernames (UIDs) lowercase before using them. However, that is entirely depending on your environment and in most cases something you can do later.
Another problem that could crop up revolves around Attribute Mappings. In eDirectory, UID is "mapped" (aliased) to uniqueid. If you get errors about an invalid attribute, check the LDAP Group object for the server you are accessing.