INF: Using GUEST Account on LAN Manager to Access SQL Server

Last reviewed: April 28, 1997
Article ID: Q89078

The information in this article applies to:

  - Microsoft SQL Server version 4.2 for OS/2

SUMMARY

When Microsoft SQL Server for OS/2 is running on a Microsoft LAN Manager server with user-level security, a user can access SQL Server even if the user is not validated by the server or the domain controller. This is done through the GUEST account in LAN Manager, but the permissions on named pipes have to be appropriately granted to the GUEST account. Sometimes, it looks like the permissions are granted properly but the user still can't access SQL Server. This article explains how to grant named pipe permissions to the GUEST account.

MORE INFORMATION

For a nonvalidated user to access SQL Server through the GUEST account in LAN Manager, the GUEST account must be granted the permission to use named pipes. However, simply granting the permission to an account named GUEST or the group *GUESTS does not guarantee that the permissions are granted properly. If it seems that the GUEST account is properly granted the named pipes permission, but a guest still can't access SQL Server, do the following to check the permission:

  1. Make sure that the named pipes permissions are granted on the server where SQL Server resides, not the domain controller (if the SQL server is on a member server or backup server).

  2. In the [server] section of the LANMAN.INI file, note the name in the guestacct= entry. (The default is GUEST.)

  3. Using NET ADMIN, make sure there is a user account named GUEST (or the name that is specified in the guestacct= entry) in the user account database. Also make sure that this account is a member of the group called *GUESTS.

  4. Make sure that either the account GUEST or the group *GUESTS is granted the named pipes permission. It is not necessary to grant this permission to both.

In summary, to grant the named pipes permission to guest accounts, the permission must be granted to the guest account (named GUEST by default) that has been assigned a guest status (which makes it a member of the *GUESTS group automatically) and whose name matches the name in the guestacct= entry.

A common mistake is that the permission is granted to the group *GUESTS, but none of the members in the group matches the name in the guestacct= entry. To grant permissions to both GUEST and *GUESTS does not guarantee that the permissions are granted properly, because there may be a case where the guestacct= entry is not GUEST, or guestacct=GUEST but GUEST is assigned an account status other than GUEST.


Additional query words: Setup
Keywords : kbsetup SSrvInst
Version : 4.2
Platform : OS/2


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: April 28, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.