GetGIDsGroupListNumberOfGroupsOfWS: Error 
Customer has recently upgraded from OES 2 SP3 to OES 2015 SP1 and for the most part things have been stable, however; recently we've been seeing issues with the OESCommonProxy User accounts, either the accounts are getting locked out, or they are showing the local server address : at a high port number as the last intruder address for example: 10.24.45.75:43567
In addition in the /var/log/messages were seeing the following:
Jul 14 04:05:02 Dxx-Pxx-Nxxxx1 /usr/sbin/namcd: GetGIDsGroupListNumberOfGroupsOfWS: Error  in LDAP search while trying to find group FDNs with scope=base for cn=UNIX Workstation - Dxx-Pxx-Nxxxx1,ou=Dxx,ou=Nx,o=xxP
Jul 14 04:05:02 Dxx-Pxx-Nxxxx1 /usr/sbin/namcd: GetGIDsGroupListNumberOfGroupsOfWS: Error  in LDAP search while trying to find group FDNs with scope=base for cn=UNIX Workstation - Dxx-Pxx-Nxxxx1,ou=Dxx,ou=Nx,o=xP
There is a TID, https://support.microfocus.com/kb/doc.php?id=7011338 that is close, but I have checked the nam.conf and it appears to match the other systems.
I'd check with this one
first. All this can also be done manually (no witchcraft), but the fabulous script will do it a little faster. On my 2do before and after upgrades of any kind.
I'm very familiar with that script, as I have been also talking with the engineer that wrote that particular script. What's strange about the issue that is being seen, is that the common proxy account isn't showing as locked, nor is it a bad password, as I've used the /opt/novell/proxymgt/bin/cp_retrieve_proxy_cred password command to see what the password, and it appears to be conforming to the customer standards.
I found out that with using that script that it won't change the password if the account passes the authentication process, in one case to this point I have actually deleted/recreated the common proxy account, and to this point that has seemed to be successful. As I'm not seeing the higher port errors as previously. Yet still have a number of servers out there that are behaving strangely.
namuserlist -x t=treename
namgrouplist -x t=treename
give the desired results?
Also, while this likely doesn't apply here, i've seen instances where e.g. serverA's CP has also been defined on serverB. In these cases, if the CP's password was changed on serverB this obviously caused a lockout on serverA which was unaware of the change.
Both namuserlist -x t=treename and namgrouplist -x t=treename gave results, and it appears that this is working as expected. I did see a number of accounts, and information so it appears to be pulling what it is supposed to be grabbing.
To the second point, I sadly have to agree the CP for the server(s) matches the server, by that I mean CP A matches server A, and CP B matches server B
I have been continuing to monitor this, and so far this morning I haven't seen the same errors, in regard to the LDAP error 81. in the /var/log messages files. I will keep monitoring as we try to better understand this error.
Looking at you post dated July 14th. i've somehow missed this
"and it appears to be conforming to the customer standards"
passus. Do they have a "standard" offset with automatic password changes and the system-generated common-proxy password-policy?