[26189] in bugtraq
RE: New Paper: Microsoft SQL Server Passwords
daemon@ATHENA.MIT.EDU (John Tolmachofft)
Tue Jul 16 01:32:50 2002
Reply-To: <sflist-bugtraq@reliance.net>
From: "John Tolmachofft" <sflist-bugtraq@reliance.net>
To: "'NGSSoftware Insight Security Research'" <nisr@nextgenss.com>
Cc: <bugtraq@securityfocus.com>
Date: Mon, 15 Jul 2002 07:47:45 -0700
Message-ID: <012e01c22698$335e2e90$100aa8c0@reliancenpr.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-to: <004c01c2268c$547bc670$82e893c3@XU5UDGJMHXJ300>
>Microsoft's SQL best practices dictate that SQL logins should not be
used in
>favour of native Windows Authentication using an operating system
account,
>but we recognize that often consumers of SQL Server do not often want
to do
>this. (With a Windows account people have access to other operating
system
>services as well as SQL Server, but with just an SQL login they should
only
>be able to access the SQL Services. The latter is the 'more safe'
option in
>the author's opinion)
One way I have worked around the problem of those accounts having access
to other items on the server/OS/domain is when running a Windows 2000 AD
domain, I do the following:
All users are created at the domain level.
Global groups are created for each specific need, such as
SQL_Login_User.
The specific users are members of that group.
I set that group as the primary group for the user.
I can then remove that user from the "Domain Users" group.
That way, the only thing that that user would have access to would be
where Everyone or Authenticated Users have permission, which if we take
permissions on our servers correctly, that will be restricted.
Just a thought.
John Tolmachoff
IT Manager, Network Engineer
RelianceSoft, Inc.
Fullerton, CA 92835
www.reliancesoft.com
