I had to configure SSO on a MOSS farm with split
back-to-back topology with the Web Front Ends (WFEs) in the perimeter network belonging to one
domain and SQL Server in the internal network belonging to another domain
(there was a trust relationship defined between the two domains). All the
service accounts, farm accounts, and database access accounts being used came
from the internal domain.
When I tried to configure the SSO service (ssosrv.exe) to
use an account from the internal domain, I would get the following error:
A Single Sign-on
error has occurred. Please contact an administrator. Details: The
network path was not found.
There would also be a corresponding entry in the event log
like this:
User
internaldomain\internaluser failed to configure the single sign-on server. The
error returned was 0x80630005. Verify this account has sufficient permissions
and try again.
The account used absolutely had sufficient permissions. It
met all the criteria specified in http://technet.microsoft.com/en-us/library/cc262932.aspx
for the ssosrv.exe service account. I tried and re-tried with other accounts,
making the account a domain admin, giving it every SQL Server permission known
to man (jk) and it still didn’t work. I even manually created the SSO database
myself and ran the SSO schema script myself and manually added permissions to
it but I still couldn’t get SSO configured in Central Administration. Actually, I had ruled out
issues with SQL Server permissions earlier because when I checked the SQL
Server logs, there weren’t even any log entries for login failures. So I sort
of came to the conclusion that something else was happening on the WFE before
it even got to the database.
After struggling with the configuration for a while and
looking at many error log entries, I finally got it configured. Looking at the
ULS logs actually helped me resolve the issue because I noticed the following
entry:
Net{User|Group}GetInfo
said Account {internaluser} does not exist
What a strange error. Clearly, SSO configuration was attempting
to use the command-line command NET USER
internaluser to get information about
the account being used by ssosrv.exe. But issuing that command goes against the
current domain of the machine, which in this case was the domain of the perimeter
network and not the internal network domain where this account really came
from. By switching the account used by ssosrv.exe to an account that instead
came from the perimeter domain and adding that account to SQL Server (and making
sure it conformed to the criteria as outlined in the article above), I was able
to successfully configure the SSO.
Just another example where the error displayed hardly gets
you down the right path.
Subscribe