tag:blogger.com,1999:blog-3923359343089034996.post442727317034280300..comments2023-06-14T08:47:52.501-07:00Comments on Project 31-A: NEVER use NT Groups to control SQL Server PermissionsWayne Walter Berryhttp://www.blogger.com/profile/07116744675621334568noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-3923359343089034996.post-67087638093775592672014-03-20T09:10:05.651-07:002014-03-20T09:10:05.651-07:00*The author should soon revise its proclamation. W...*The author should soon revise its proclamation. Whoever does not read the comments is lost with false information!*Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-4088024822378732692012-10-15T10:02:58.822-07:002012-10-15T10:02:58.822-07:00Not to pile on....but this is important. Anonymous...Not to pile on....but this is important. Anonymous from Feb 13, 2012 is correct.<br />Logoff and login is needed and all is ok.<br /><br />THE PREMISE OF THIS ARTICLE IS INCORRECT<br /><br />The BUG here is actually in the "Microsoft official Site" the author uses to support his incorrect hypothesis (It has to do with SMS installation, not Directly from SQL Server documentation). The SMS installation page he references is incomplete. It does say that changing users is not dynamic...but should also say "Unless the user reconnects to the database".....that's where the error is in that SMS doc .... and I can see why the Author of this article was mis-lead by it.<br /><br />AS for his further criticism of complex AD collections/heirarchies and walking permissions through them...well that depends on if your AD is spaghetti or logical. Using Domain Groups to manage permissions within SQL Server is not lazy as implied by a different Anonymous (March 15, 2010). It is a perfectly viable why to logically control data access according to logical AD setup.<br /><br />Hope you read this far and din't jump thru SQL permissioning hoops you didn't have to.JSHhttps://www.blogger.com/profile/17022126646459497379noreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-91808579633019156202012-02-13T04:40:25.147-08:002012-02-13T04:40:25.147-08:00Hi,
After hours of investigations, I thing I found...Hi,<br />After hours of investigations, I thing I found the {obtuse} cause : Using NT Security groups in SQL works very well (adding/removing users to group produce a correct behavior in SQL Server)... HOWEVER : User have to logoff/logon again in Windows to make new membership effective (as for NTFS permissions)...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-30143133555456815382011-02-04T08:23:20.965-08:002011-02-04T08:23:20.965-08:00Nobody mentioned this, so I thought I'd point ...Nobody mentioned this, so I thought I'd point it out. A user that is removed from a group continues to have that permission until they log out of Windows and back in.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-85947835707046063642011-02-03T14:38:45.347-08:002011-02-03T14:38:45.347-08:00Since it seems that it alleged that it works some ...Since it seems that it alleged that it works some times and documented as not working other times I suspect that there is some {obtuse} configuration issue involved between SQL Server and the domain.<br /><br />If you plan on using groups, you may wish to verify that it actually works (especially when a user is removed from a group that is contained in another group -- the permission cascade problem) and then make a point of re-verifying it periodically -- in case the {obtuse} configuration issue is changed.Ken Lassesenhttp://lassesen.comnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-73476802680363144862010-09-01T17:22:40.791-07:002010-09-01T17:22:40.791-07:00140+ servers here with SQL2005\2008 and Windows200...140+ servers here with SQL2005\2008 and Windows2000\2003\2008 and using NT groups with no problems at all. I can add and remove users at will from domain groups and access is immediately granted or denied.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-34196839149009022542010-03-31T15:33:48.273-07:002010-03-31T15:33:48.273-07:00SQL 2005 and Windows Server 2003 with users in a s...SQL 2005 and Windows Server 2003 with users in a security group. No problem at all.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-19384790227864324602010-03-15T09:47:44.551-07:002010-03-15T09:47:44.551-07:00wow - i agree with Scott - i was also in the proce...wow - i agree with Scott - i was also in the process of testing using NT user groups. Thanks for saving me a bunch of time and headaches.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3923359343089034996.post-44874093010645723812010-02-26T09:30:16.900-08:002010-02-26T09:30:16.900-08:00THANK YOU! I was in the process of testing using N...THANK YOU! I was in the process of testing using NT user groups as an alternative to maintaining custom database roles or individual login permissions. I turned up this post in an internet search I did while trying to figure out why it wasn't working as expected. Now I know ... Time to go delete those test group IDs from the database.<br /><br />And here I thought I could hand off some of my work to the Windows network admins. Teach me to be lazy! :)Scott Christian Simmonshttps://www.blogger.com/profile/13617497676831940377noreply@blogger.com