February 14, 2003 at 9:57 am
Under NT 4.0 it probably has more to do with the fact that I only have two levels of hierarchy:
Global Group
Local Group
Of course with AD in Native Mode I can nest a whole lot deeper, so it might be legacy.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley
February 14, 2003 at 9:35 pm
I'm trying to remember when I used to work in a SQL Server 6.5 environment. It's been soooo long, but I remember the SQL Security Manager tool that was used to map Windows Groups/logins to SQL Server. However I can't remember if it was a requirement to use local NT groups or if it was possible to add Global groups directly to SQL Server??
Can anyone remember that?
February 14, 2003 at 10:08 pm
In SQL6.5, both local and global groups could be used.
Ideally, the rule of NT (pre-AD) was:
AGLP (Account -> Global Group -> Local Group -> Permission)
The thought was that by assigning permissions to local groups, granting or revoking permissions to a resource was as easy as adding or removing members (users or global groups) from the local groups.
February 16, 2003 at 9:14 am
Yes, now that you mention it, I recall AGLP from one of my early 6.5 training courses.
February 17, 2003 at 8:53 am
quote:
By using global groups, security simply moves with the database. If you used local groups the SIDs would all have to be fixed every time you restored a database to a different server.
Of course, this is a moot point if you are using Active Directory, where the "local" groups (domain local groups) are still stored in AD. The problem with changing group SIDs vaporizes.
Regards,
Chris
___________________________________
Chris Leonard, The Database Guy
Brainbench MVP for Oracle Admin
MCSE, MCDBA, OCP, CIW
___________________________________
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply