Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a network where several users are using Office Accounting 2009 in multi-user client/server mode. OA is built on SQL Server. One PC acts as the 'server' and has the SQl Server instance, the others have only the application installed and no SQL instance, all of the apps connect remotely to the SQL instance on the 'server'.

I'm using the term 'server' loosely here, it is just a normal workstation that happens to be designated as the server and runs the SQL instance. There is no NT domain, all user accounts are local accounts.

The way that OA works in multi-user mode is that each user is required to have a local account with the same username and password on both the client and 'server' PCs. This has been working well, no along comes Windows 8. I use my 'Microsoft Account' aka LiveID to log into Windows 8.

Office Accounting runs fine and attempts to connect to the database, but fails, 'you do not have permission to perform this operation'.

In the SQL logs, I get this error:

2012-10-28 17:54:01.32 Logon       Error: 18456, Severity: 14, State: 11.
2012-10-28 17:54:01.32 Logon       Login failed for user 'SERVER\Guest'. Reason: Token-based server access validation failed with an infrastructure 

SERVER is the hostname of the server. So it seems to be authenticating as 'Guest'??

To verify this, I enabled the Guest account on the 'server' PC and then added Guest as an allowed user within Office Accounting (this simply creates the user in SQL and gives it an appropriate database role).

Sure enough, My Windows 8 PC was then able to connect to the database when using Office Accounting.

Clearly, having users authenticate as 'Guest' stinks from a security and auditing standpoint. So what I need are some ideas for how to work around this. I've tried switching the Windows 8 PC to a 'local account' and that works too, but requires giving up significant functionality on the Windows 8 PC. What I really need is a way to force the Windows 8 PC to use a specific set of credentials when connecting to the remote SQL instance. Office Accounting takes the logged in username, which is my LiveID and doesn't correspond to any Windows user name.

Anyone solved this issue?

share|improve this question

3 Answers 3

Removing Office Accounting from the equation, you may want to test this by logging on to your Windows 8 computer with the local username and password, and connect to a share on the target computer. Typically Windows will attempt to connect with the current credentials. If that doesn't work, it would seem to be a Windows issue, not related to SQL or Office Accounting. Probably a lot easier to test and localize.

Next step would be to try to establish a connection first, such as net use x: \\targetcomputer\sharename , and then run Office Accounting.

share|improve this answer
up vote 1 down vote accepted

Although Office Accounting will not allow this via its user interface, I found that manually adding my full LiveID (the full email address format) as a database login (with appropriate mappings and user roles on the OA database) enables me to successfully authenticate with the database server. The login was added using SQL Server authentication and the same password as used to sign in with the LiveID.

Why I never thought of this before, I'm not sure - maybe because it just looks odd having email addresses as SQL logins.

share|improve this answer

it seems that you have succeeded to open company file from Windows 8 by being logged in with a Windows LiveID account. However, According to your propose I followed it and created the new login account within Microsoft SQL Server Management Studio. Unfortunately, I have not been able yet to set the things up and running.

Here is the record from SQL server logs. "Login failed for user ''. The user is not associated with a trusted SQL Server connection. [CLIENT: 192.168.1.102]"

Well, if I change Windows 8 user account to the local one, and create the same account on the server, which runs on Windows XP, then everything works fine.

Help on that issue would be more than welcome.

Best Regards, Sas

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.