OK, we have a couple of MS SQL 2000 servers running in a Win2k AD domain.
Both machines are using mixed mode security, the issue appears to be this.
If I go into AD and change a groups name that has been granted access to
the SQL server, it doesn't seem to pick up on the name change.
I also can't add the new name to the SQL server, because of a conflict of a
SID.
So how do I get the MS SQL server to refresh the names of the native NT
groups that have been granted access, then have the names changed ??I think you need to drop the old name and add the new one. Why are you doing this? Experimenting?|||Its not uncommon to have a native AD Security group renamed to match
a changed "department" name lets say.
SQL 2000 doesn't seem to see the name change in AD, where is this info stored in
the SQL server ?? is there a SP to refresh the cache or this table ?|||I'd say changing a department name should result in a change of an OU, not a group. But that's just me.
Showing posts with label mixed. Show all posts
Showing posts with label mixed. Show all posts
Friday, March 9, 2012
Wednesday, March 7, 2012
Quick Question
I have a client that's insisting on deploying SQL Server 2000 as Windows Authntication mode only (not mixed mode). I've always done mixed mode in the past and I'm just looking for some input here. So, what's everyone think?Either form of authentication will do. If NT Authentication will do everything that the client needs, it is certainly a workable solution.
NT Authentication is more secure than SQL Authentication, but it means that you need better "digital plumbing" to make it work, especially over a WAN. You need more bandwidth, more complex router/link settings, a more capable firewall, etc. If you have these things, and can absolutely rely on them, then NT Authentication is simpler and safer than SQL Authentication from a SQL user/administrator perspective.
-PatP|||I suppose my assumption was that I'd issue access based on Windows Auth, but I had intended on leaving it in mixed mode for those times when sa has to step in. Should I ignore SQL Auth altogether, or leave sa as the only SQL Auth user as an "in case of emergency break glass" user?
Thanks in advance!|||As long as you have an NT Admin, you really don't need sa for much of anything. The only case I can see where you might want sa is if you need to dial in remotely, and can't support NT Authentication. That is a considerable stretch of the imagination, and if you have VPN access or an on-site administrator it isn't even relevant.
-PatP|||I have only one small problem with the Windows Authentication. Suppose you have a Web server that runs several websites. All of those websites would have to log into the SQL Server as a single account under Windows Authentication. Namely, the windows account that the web service runs under (at least, with my simple understanding of IIS). This has the rather unfortunate effect of making all of the databases only as secure as the least secure website. If you have a single page on a single one of these websites that allows SQL Injection, then all of the security on all of the other websites is quite simply cooked. Microsoft has a very unsettling attitude towards security on SQL Server. They keep banging the "Least Privilege" model drum, but put out applications like SMS and Sharepoint that blatantly break that model.
NT Authentication is more secure than SQL Authentication, but it means that you need better "digital plumbing" to make it work, especially over a WAN. You need more bandwidth, more complex router/link settings, a more capable firewall, etc. If you have these things, and can absolutely rely on them, then NT Authentication is simpler and safer than SQL Authentication from a SQL user/administrator perspective.
-PatP|||I suppose my assumption was that I'd issue access based on Windows Auth, but I had intended on leaving it in mixed mode for those times when sa has to step in. Should I ignore SQL Auth altogether, or leave sa as the only SQL Auth user as an "in case of emergency break glass" user?
Thanks in advance!|||As long as you have an NT Admin, you really don't need sa for much of anything. The only case I can see where you might want sa is if you need to dial in remotely, and can't support NT Authentication. That is a considerable stretch of the imagination, and if you have VPN access or an on-site administrator it isn't even relevant.
-PatP|||I have only one small problem with the Windows Authentication. Suppose you have a Web server that runs several websites. All of those websites would have to log into the SQL Server as a single account under Windows Authentication. Namely, the windows account that the web service runs under (at least, with my simple understanding of IIS). This has the rather unfortunate effect of making all of the databases only as secure as the least secure website. If you have a single page on a single one of these websites that allows SQL Injection, then all of the security on all of the other websites is quite simply cooked. Microsoft has a very unsettling attitude towards security on SQL Server. They keep banging the "Least Privilege" model drum, but put out applications like SMS and Sharepoint that blatantly break that model.
Subscribe to:
Posts (Atom)