We just upgraded our Polycom CMA 4000 from 5.5.0 to 6.0.0, following the polycom doc.
Then we imported the CMA settings but we were unable to have Enterprise Directory integration working with same accounts as before.
We had this weird error “@0@” when trying to search for users.
We also get “Access Denied” when we want to set the password for machine account (delegated authentication to entreprise directory server).
We cannot logon with the LDAP account which should have administrator role (login successful but no role).
We can logon with enterprise directory account that were configured before the update but we cannot see them in the user list.
We just tried to upgrade to 6.0.2, and to reimport CMA settings…same things…
Any tips are more than welcome.
Solved! Go to Solution.
V6 has changed the way the LDAP service account works. Now you have to log in via the Admin account and set the roles you want for the Enterprise users, including the LDAP account if any. In previous vresions, this account was given full admin role by default.
I can't visualize the users, including the local users, so I can't set the role for the user.s
When I try search or visualize a user by tab "user" via account admin, I receive error attached.
Many customers are seeing the ‘@0@’ error after upgrading a CMA to V6.0 from V5.x. This ‘@0@’ is usually seen when trying to access the CMA Sites, Site Topology, Site Links, or Rooms. It prevents you from doing anything in those areas.
Polycom is aware of the issues, and we are looking at a way to prevent this from happening in the future as well as a better way of recovering than what they are having us do now, which is described below. We think the problem is a corrupted Certificate Store on the CMA. It is important to note that although you get the ‘@0@’ and similar symptoms, this process may not resolve your issue if it is not caused by the corrupt certificate store.
If you have a CMA in the above condition, then you can try to force the CMA to reconstruct and then use the default Self-signed certificate (or apply your own valid certificate.)
The process basically goes like this.
From the CMA, request a CSR to a CA.
Process the request on your CA.
Apply the new certificate to the CMA.
Delete the newly applied certificate.
Tell the CMA to use the default certificate.
Thank you very much.
I forced the CMA to reconstruct and then use the default Self-signed certificate, as you said.
Now,I haven't the ‘@0@’ error, and CMA is working normally.
Thank you again,
By The Way, we wanted to put a certificate from our internal PKI infrastructure but i saw in the operation guide that CRL has to be updated manually (Operation guide 6.0.0 p.445 & 448).
Our PKI certificate authority renew the CRL each 3 days, so it is just not possible to handle that by hand !!
Normally this process is fully automatic with the CRL distribution point taken into the certificate properties.
Any clue on that ?
Thanks in advance
Yes - we have wanting the CMA to at least support the Online Certificate Status Protocol (OCSP) like some of out other products do. OCSPis an alternative to the CRL method for maintaining revocation status that automatically updates itself and does not require manual intervention
In my limited testing, the CMA does not pull the CRL distrubtion point from the either the certificate or the root CA. This makes updating the CRL a manual process which is not very ideal to most administrators.
This observation matches the text given here - Pg. 448 User guide CMA 6.0
Upload a Certificate Revocation List
This section describes how to install a certificate revocation list (CRL) provided by a certificate authority.
The CMA system requires a CRL for each CA or sub-CA in the certificate chain. The CMA system also requires that you upload a new CRL at regular intervals. This interval can be as short as a few days in higher security environments or a few months in environments with lower security requirements.
If more people complain about this feature, maybe we can get the CMA to at least automatically renew the CRL when needed.
I cannot believe what is being said here....
We must complain to get things to work with standard behavior...what a crappy solution !!
CRL distribution points are always used and all systems should be able to work with when dealing with PKI and certificates checking !
Tnak in advance !
is the CRL update still a manual process? in our case we have applied godaddy certificate that requires update every week. manual update is an issue which we have not faced with any PKI environment.