UniqueID in eDirectory is meant to handle a case for LDAP that does not map 100% to the eDirectory model. In eDirectory, you can have the same CN=myName anywhere you like, as long as there is no naming collision within the same container. This is a great feature, but it can also be a problem - for example, where Active Directory can only reuse names like that in different domains. An Organizational Unit (OU) is not enough to allow the reuse, since each Domain is basically a flat namespace in AD.
LDAP applications, however, usually assume a more Sun/LDAP-style model, where there truly is a Unique identifier. That is what UniqueID is used for.
If you do an LDAP search for a "uid=something", and it returns two or more values, that is in itself an error, since it is supposed to be unique, by definition. If the numerical number used for UniqeID is truly unique, you are ok. But if the LDAP app is searching for it, then the user needs to log in with that numerical number to identify himself.
Novell apps are using LDAP for authentication more and more. This is especially true of the web-based apps, such as NetStorage, iFolder, and iPrint - they all use LDAP for authentication.
There are tricks you can use to make an LDAP app that MUST use the UID to search to instead use the CN.
For example, you can use the Attribute mapping table in the LDAP object for the specific eDirectory server and have it set the LDAP UID to return the eDirectory attribute CN. This is server specific, so it may end up that for some specific LDAP app you need a replica just
for that app. Still, it is nice that eDirectory is flexible enough to do this.
Even better, with eDirectory 8.8 and higher you can run multiple instances on one box (alas, NetWare can only have one instance per box). That way, you could have a second replica just for this app on an existing server, listening on a second IP address if needed.