Thursday, March 22, 2012

Error 15401: Windows NT group or group not found

I had an NT account in SQL Server named: gvv\molly...we then had to change her NT account to mring...so now 2 questions:

1. How can I tell SQL Server that gvv\molly is really gvv\mring..and have gvv\mring inherit all of molly's permissions ?

2. I deleted gvv\molly and tried re-adding gvv\mring...and it gave me my subject errror ?

What to do ?

Thank youHowdy,

Every user has a unique SUID in SQL Server - dont complicate your life -remove the original user & re-add the new user, then re-do all the security as required.

Be careful too - an NT login ( or even a SQL login ) is mapped to a unique username in each database. If your original NT username owned objects in a database, then you wont be able to remove the username from the database until all object ownerships have been transferred to sa or dbo. But this could cause problems with any application you are running, so if this is an issue, you may need to carefully work through it.

(By the way - its a big no-no to have a user owning objects - all objects in a database should be owned by dbo or sa and then you dont have a problem.)

Post back if problems.

Cheers

SG|||(By the way - its a big no-no to have a user owning objects - all objects in a database should be owned by dbo or sa and then you dont have a problem.)

I wouldnt recommend that SG !!!!
Having a single user owning all the objects (DBO) should be a big no - no . How do you take care of all the security problems then ????|||Howdy Enigma,

Part of the reasons for the questions I'm asking are to flesh out the actual problem, hence the comments about dbo & sa owning all objects.

In most situations, I would always have dbo or sa owning all objects. Good security setup in the database ( if professionally configured ) will always be secure. I dont tolerate people that leave sa blank nor should anyone else - good for a pink slip in my book.

In some cases e.g. an application during its operation or installation may create objects in the database, that would be valid case for non-dbo/sa ownership ( but still not a great state of affairs - especially if its an internet exposed app).

If there is a bonafide reason for it, I'm open to suggestion. But in most cases, not good practice.

Cheers,

SG.|||SQLguy,
you wrote: "dont complicate your life -remove the original user & re-add the new user, then re-do all the security as required."

I tried that, but it still gave me the same msg...is that because my previous NT login owned an object ?...Im pretty sure that she did not.

Also, I cannot add her new NT login on a complete new server, one that she was never configured on with old or new NT account name.

Could this have anything to do with DNS settings ?

Thank you for your feedback|||I agree with SQLGuy. users owning objects will lead to more problems than solutions. Consider if you have two users that create tables with the same name. Now there is no telling what results either user would get from queries that reference either table (unless they fully qualify the names in those queries/stored procs). Then there are all the problems around the fact that a user can now drop a table in your database. Or create 200 indexes on the table. It is too much of a potential problem.|||Howdy kohln5,

I am surprised you get the same issue with the new user.

Some suggestions as we work this out:

(1) Lets test whether you have a DNS probem - see if you can ping the domain controller by name and TCPIP address from the SQL box.

(2) If you can ping the domain controller by name, open a dos box & type: ipconfig /all and look for the WINS & DNS server entries. If you dont have any that will probably be the reason. Speak to your networking guys about that.

(3) If you can ping the domain controller & you have correct WINS & DNS entries under ipconfig /all try going to your NT security and try & add the user under NT security to the local Users group on the box. At this point if you cant do this, you have a general networking issue & will need to fix it before we can progress the problem.

Post back if probs

Cheers

SG.sql

No comments:

Post a Comment