All,
After adding Domain users to a database I get the situation where some
display in the "Users" section without a Login Name.
The users still function correctly, but some have Login Names and some
don't. Another note is that we have Production and Test servers on differen
t
boxes and a user can display different ways on each.
So, my question is, why does this happen? And more importantly, is there
some subtle problem behind the scenes that means I can't just ignore this
symptom?
Thanks,
Simon.
P.S. For example:
Name Login Name Database Access
---
User1 Domain\U1 Permit
User2 Permit
User3 Domain\U3 Permit
^- no login name for Domain\U2Simon wrote:
> Name Login Name Database Access
> ---
> User1 Domain\U1 Permit
> User2 Permit
> User3 Domain\U3 Permit
> ^- no login name for Domain\U2
Simon,
we are encountering the same effect, when I do a RESTORE from a Database Bac
kup
from a Server which is not in the Windows Domain. I suppose it has something
to
do with an orphaned User SID.
I suppose when you enter
use mydb
sp_helpuser
you get NULL in the Login column.
Suggestion: Use a script with 'sp_dropuser' resp. 'sp_revokedbaccess' and 'g
rantdbaccess' to delete and rebuild the
user(s).
If the DB owner user dbo is also void, use 'sp_changedbowner' to reassign it
.
Joachim|||Hi Joachim,
Yes, sp_helpuser does return null. However, we are using a script with the
mentioned sp's to add users to this database. Way the app works is by a use
r
entering details passed through to the script (sp). Some work, some don't.
We have two machines (Prod & Test) and the results can differ. UserA might
be fine on Prod but not on Test, UserB might befine on Test but not on Prod.
Repeatedly dropping and adding the user gets consistent results on each
machine, whether that be by script, Query Analyser, Enterprise Manager. I
can spot no common denominator, and have found no way to make a "nulling"
user not-null.
Only other thing that I can think worth mentioning: at the Security | Logins
level we have added "Domain\All Users" to grant all users server access.
Database access is granted on a user by user basis (via the script mentioned
earlier.)
Simon.
"Joachim Hofmann" wrote:
> Simon wrote:
>
> Simon,
> we are encountering the same effect, when I do a RESTORE from a Database B
ackup
> from a Server which is not in the Windows Domain. I suppose it has somethi
ng to
> do with an orphaned User SID.
> I suppose when you enter
> use mydb
> sp_helpuser
> you get NULL in the Login column.
> Suggestion: Use a script with 'sp_dropuser' resp. 'sp_revokedbaccess' and
'grantdbaccess' to delete and rebuild the
> user(s).
> If the DB owner user dbo is also void, use 'sp_changedbowner' to reassign
it.
>
> Joachim
>|||You can have null for the login name where there isn't a
matching record in the syslogins table in the master
database. The syslogins table and the sysusers table will be
joined on sid. If no matching record is found in syslogins
by sid, then the login name is null and nothing will display
for Login Name in Enterprise Manager.
-Sue
On Mon, 28 Feb 2005 14:53:03 -0800, "Simon"
<Simon@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Hi Joachim,
>Yes, sp_helpuser does return null. However, we are using a script with the
>mentioned sp's to add users to this database. Way the app works is by a us
er
>entering details passed through to the script (sp). Some work, some don't.
>We have two machines (Prod & Test) and the results can differ. UserA might
>be fine on Prod but not on Test, UserB might befine on Test but not on Prod
.
>Repeatedly dropping and adding the user gets consistent results on each
>machine, whether that be by script, Query Analyser, Enterprise Manager. I
>can spot no common denominator, and have found no way to make a "nulling"
>user not-null.
>Only other thing that I can think worth mentioning: at the Security | Login
s
>level we have added "Domain\All Users" to grant all users server access.
>Database access is granted on a user by user basis (via the script mentione
d
>earlier.)
>Simon.
>
>"Joachim Hofmann" wrote:
>
No comments:
Post a Comment