For the 1st issue: On each Unity server, create one subscriber account that has the COS that allows for Password resets only. Then run GrantUnityAccess on each Unity server, and associate the Windows/AD account of each user that will be doing the password resets with the subscriber account. See the "Granting Administrative Rights to Other Cisco Unity Servers" section for details:
Ok, I have tested GrantUnityAccess and have identified an issue. Yes this works in as much as a single ID can be used across all servers. Users are still presented with a screen pop for login credentials when moving between servers, however. Avoiding having to re-enter credentials was really the hope/goal in having a single login... although that may not have been clear from reading my post.
Are the users logged onto a Unity server when they access the SA? Or are the users logged onto their workstations? In my previous response I was thinking about being logged onto the Unity server itself.
If the users are logged onto their workstations, are the workstations in the same domain as the Unity servers? In IE on each user's workstation, is the security setting set to "Automatic logon..." for either the local Intranet or Trusted Site?
Also, I'm assuming that you're using Integrated Windows authentication because that's the default. In this case, it's not Unity asking for credentials, it's IIS. So it matters what computer the user is logged onto. And it matters how IE is configured for that user (the IE Internet Options are configured on a per-user basis).
If the user's workstation is in the same domain as the Unity servers, and IE is set to "Automatic logon..." then they shouldn't be getting prompted.
Here's more info about authentication methods used to access the SA:
To be clear, the users are logging in via IE from a separate and untrusted domain. I will review the authentication methods link but are you saying that if Unity Trusted the corporate domain would that resolve the issue?
OK, untrusted domains explains why the users are getting prompted for credentials. You'll need to create a two-way trust between the domains, and then run grantunityaccess to associate the users with a subscriber with the appropriate COS system-access setting.
After running grantunityaccess, you should be able to remove one of the trusts. You'll need to keep the trust where the Unity domain trusts the Corporate domain. The reason for the two-way trust when running grantunityaccess is due to the defect CSCsi68156. Following is the release note enclosure for it:
GrantUnityAccess.exe fails granting access between two domains in separate AD forest roots.
When a one way trust is established using the Cisco documented procedure between domains in two different forest roots, GrantUnityAccess.exe fails granting rights to the remote domain account as it is not able to get the SID for that remote account.
Establish a temporary two-way trust between the two domains in the different AD forest roots. GrantUnityAccess.exe will then be able to complete the GrantUnityAccess.exe process properly. Once the AD accounts are granted Unity access, the trust can be reverted back to the documented one-way trust to tighten security. If GrantUnityAccess.exe is going to be run again, the two-way trust will have to be re-established.
Further Problem Description:
Please note: If the one-way trust is established in the wrong direction, GrantUnityAccess.exe will succeed in associating the AD account to the Unity subscriber; however when using the remote domains AD credentials to access Unity resources the authentication will fail. This is important as it could be confusing when setting up the trust direction.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...