Privileges and usrmgr.exe

Jeremy Allison jra at samba.org
Mon Mar 6 18:16:14 GMT 2006


On Mon, Mar 06, 2006 at 01:13:54PM -0500, simo wrote:
> On Mon, 2006-03-06 at 11:44 -0600, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > simo wrote:
> > > I was testing usrmgr.exe (running it on an NT$ PDC against my test samba
> > > server), and it seems it does not like when there is an unknown SID in
> > > the privileges database. The traces shows that it ask for the lists of
> > > privileges and then tries to resolve the SIDs. If we fail to resolve a
> > > SID it just stamps me an Access Denied. We can probably cure this
> > > problem by changing the error message (investigating this right now),
> > > but I was thinking if we shouldn't be a bit more strict in what we let
> > > admins put inside the db and by deleting corresponding entries when we
> > > delete users or groups for our passdb.
> > 
> > Simo,
> > 
> > I think somewhere something has changed then.  I remember seeing
> > usrmgr.exe showing SIDs that wouldn't resolve in the user rights
> > dialog.  Can you verify what a Windows NT 4.0 DC does when you
> > assign a privilege to a user/group and then delete that account?
> > Thanks.
> 
> Actually, looking at the traces more closely seem we are failing to
> properly answer to an LsarEnumeratePrivilegesAccount request about the
> unknown SID.
> Ethereal shows me we return error 0x00001002 which is not an NT_STATUS
> error code, and just after that we return access denied to an
> LsarGetSystemAccessAccount.
> 
> I think these 2 answers are the problem, we should probably issue the
> proper error on the first and a different one on the second.
> Btw, I'm not sure yet how it happens that we return a non-NT_STATUS
> error, perhaps it is that we pass invalid data to the marshalling
> routines, still looking into it.

Can you send me the debug level 10 log of this ? I've been looking
at quite a few of these last week at Connectathon so might be able
to help track this down.

Jeremy.


More information about the samba-technical mailing list