[Samba] Debugging Privilege and Samba 3.0.11
Thierry
I am striving to give out globally to our developers a way to debug
their C++ applications, but I do not want to give them Admin rights on
the individual workstations.
I thought I found the light when reading on MSDN that to debug users
need to be members of the "Debugger Users" group (according to VS.Net).
This group seems to be created with a random SID when installing VS.Net
on the computer.
I created the group on the Samba domain , even removed the Local group
on the computer where VS was installed, but any attempt to debug with a
"Domain User" account is moot : ends up with "permission refused" when I
want to attach to a process.
Now I think that maybe the real right to debug a process is bound to the
SeDebugPrivilege privilege on the Domain.
Unfortunately attempts to perform
net rpc rights grant 'LAB\Debugger Users' SeDebugPrivilege
ends up with NT_STATUS_NO_SUCH_PRIVILEGE .
I even tried to manually add the "Debugger Users" group to the Local
Security Policy of the computer to the "Debug" rights , but it doesn't
work either.
Can anybody shed some light on the way I can reach my simple goal : give
developers a way to debug, without giving away "Domain Admin" rights to
them?
(Yes, I know, this security is not perfect, but hey, I did not invent
the Windows security model either...)
Thank you for any help!
Cheers
Thierry
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
JLB
> Date: Fri, 25 Feb 2005 19:25:14 +0100
> From: Thierry <Thi...@echotech.ch>
> To: sa...@lists.samba.org
> Subject: [Samba] Debugging Privilege and Samba 3.0.11
>
> Hello,
>
> I am striving to give out globally to our developers a way to debug
> their C++ applications, but I do not want to give them Admin rights on
> the individual workstations.
You're foolish if you think anyone with local access to a workstation
can't get into the Admin account on their local machine.
Here is a boot disk suitable for changing or blanking the Administrator
password on any NT box:
http://home.eunet.no/~pnordahl/ntpasswd/
Here is a boot disk suitable for mounting Linux partitions and editing
/etc/passwd and/or /etc/shadow:
Here is a tool that lets you remove or alter BIOS passwords:
http://www.cgsecurity.org/index.html?cmospwd.html
Here is a provider of screwdrivers. Screwdrivers let you physically reset
BIOSes, remove or replace drives, install logging devices, etc.:
--
J. L. Blank, Systems Administrator, twu.net
Gerald (Jerry) Carter
Hash: SHA1
JLB wrote:
| On Fri, 25 Feb 2005, Thierry wrote:
|
|>Date: Fri, 25 Feb 2005 19:25:14 +0100
|>From: Thierry <Thi...@echotech.ch>
|>To: sa...@lists.samba.org
|>Subject: [Samba] Debugging Privilege and Samba 3.0.11
|>
|>Hello,
|>
|>I am striving to give out globally to our developers a way to debug
|>their C++ applications, but I do not want to give them Admin rights on
|>the individual workstations.
|
| You're foolish if you think anyone with local
| access to a workstation can't get into the
| Admin account on their local machine.
WoW! That was a really helpful response!
And while correct, doesn't do anything to help
the original poster.
If I have an employee and I'll them I'm not
going to give you admin access. And then the
hack the box using local physical access, i'll
just fire them. Problem solved. No more physical
access.
The answer is that you create a domain group on
the Samba server; add the users to that group,
the assign that SID the SeDebugPrivilege right
on the individual machines (not of the Samba DC).
user rights are local to the machine on which they
are assigned.
cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCH3SRIR7qMdg1EfYRAisqAJsGDuFLYHhOUy0V745eTtqAhs/qKACg2J0F
tZoLyWOlvj9P3RiiqIJcUNg=
=M3kc
-----END PGP SIGNATURE-----
Craig White
> On Fri, 25 Feb 2005, Thierry wrote:
>
> > Date: Fri, 25 Feb 2005 19:25:14 +0100
> > From: Thierry <Thi...@echotech.ch>
> > To: sa...@lists.samba.org
> > Subject: [Samba] Debugging Privilege and Samba 3.0.11
> >
> > Hello,
> >
> > I am striving to give out globally to our developers a way to debug
> > their C++ applications, but I do not want to give them Admin rights on
> > the individual workstations.
>
> You're foolish if you think anyone with local access to a workstation
> can't get into the Admin account on their local machine.
>
> Here is a boot disk suitable for changing or blanking the Administrator
> password on any NT box:
>
> http://home.eunet.no/~pnordahl/ntpasswd/
>
> Here is a boot disk suitable for mounting Linux partitions and editing
> /etc/passwd and/or /etc/shadow:
>
> http://www.toms.net/rb/
>
> Here is a tool that lets you remove or alter BIOS passwords:
> http://www.cgsecurity.org/index.html?cmospwd.html
>
> Here is a provider of screwdrivers. Screwdrivers let you physically reset
> BIOSes, remove or replace drives, install logging devices, etc.:
>
> http://www.homedepot.com/
>
enjoyed the post but I don't think that is what op meant. Generally, I
would think that if they were 'Power Users' members on local machines,
they could do C++ debugging. There's all sorts of reasons
(spyware/viruses) not to give more privileges than necessary and not
just to lock them out of their boxes.
Craig
Thierry
>On Fri, 25 Feb 2005, Thierry wrote:
>
>
>
>>Date: Fri, 25 Feb 2005 19:25:14 +0100
>>From: Thierry <Thi...@echotech.ch>
>>To: sa...@lists.samba.org
>>Subject: [Samba] Debugging Privilege and Samba 3.0.11
>>
>>Hello,
>>
>>I am striving to give out globally to our developers a way to debug
>>their C++ applications, but I do not want to give them Admin rights on
>>the individual workstations.
>>
>>
>
>You're foolish if you think anyone with local access to a workstation
>can't get into the Admin account on their local machine.
>
>
I don't think so. I know a good security policy does not end at the
bounds of the software.
Nevertheless, this has never been an excuse for not implementing a
little bit of security IMHO...
>Here is a boot disk suitable for changing or blanking the Administrator
>password on any NT box:
>
>http://home.eunet.no/~pnordahl/ntpasswd/
>
>
Oh, you still have floppy disk readers in your computers?
Or CDROM readers that happen to be not on your server as a share, with
server's room access only to the admin?
Ah, maybe your PCs boot from a non-fixed hard drive , or your bootloader
is not protected by a MD5 password?
>Here is a boot disk suitable for mounting Linux partitions and editing
>/etc/passwd and/or /etc/shadow:
>
>http://www.toms.net/rb/
>
>Here is a tool that lets you remove or alter BIOS passwords:
>http://www.cgsecurity.org/index.html?cmospwd.html
>
>
How are you going to run that on my Windows 2000 system without
Administrative rights?
>Here is a provider of screwdrivers. Screwdrivers let you physically reset
>BIOSes, remove or replace drives, install logging devices, etc.:
>
>http://www.homedepot.com/
>
>
>
The nicest thing about screwdriver is that they even allow you to kill
the officer sitting in the room or the guard at the entrance ;-)
I _know_ that giving out these silly "debug" rights is pretty much
giving out the ability to hack the box.
Still, hacking requires a will , while breaking the installation out of
ignorance because an ignorant sysadmin gave the user too many rights
does not.
Now, if you have an answer to my specific request I'd be glad to hear it
, no kidding :-)
Thierry
>I apologize for being so flippant and unhelpful (although in my defense,
>I posted the links to the various password tools in order to -be- helpful.
>They got me some major brownie points the other day when a client's
>"network administrator" (a Windows-only user) was unaware of the existence
>of either Snadboy's Revelation -or- the NT password-resetting boot disk
>thingee (both of which she found highly useful and time-saving). Tools
>like this are so handy!)
>
>
And they are , indeed! :-)
Thank you anyway - I could indeed have been one of those who believe
"security" is adding an anti-virus to their server... ;-)
and you had no way to know I guess :-)
Cheers
Thierry
JLB
I posted the links to the various password tools in order to -be- helpful.
They got me some major brownie points the other day when a client's
"network administrator" (a Windows-only user) was unaware of the existence
of either Snadboy's Revelation -or- the NT password-resetting boot disk
thingee (both of which she found highly useful and time-saving). Tools
like this are so handy!)
On Fri, 25 Feb 2005, Gerald (Jerry) Carter wrote:
> Date: Fri, 25 Feb 2005 12:55:13 -0600
> From: "Gerald (Jerry) Carter" <je...@samba.org>
> To: JLB <j...@twu.net>
> Cc: Thierry <Thi...@echotech.ch>, sa...@lists.samba.org
> Subject: Re: [Samba] Debugging Privilege and Samba 3.0.11
--
J. L. Blank, Systems Administrator, twu.net
Gerald (Jerry) Carter
Hash: SHA1
JLB wrote:
| I apologize for being so flippant and unhelpful
| (although in my defense, I posted the links to
| the various password tools in order to -be- helpful.
True. It was the most informative flippant response
I've seen in a while :-)
cheers, jerry
=====================================================================
Alleviating the pain of Windows(tm) ------- http://www.samba.org
GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc
"I never saved anything for the swim back." Ethan Hawk in Gattaca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCH4Q5IR7qMdg1EfYRAv7MAJ0bOFoRdaLY5SFEd/8fcdXeXF586ACg2bfb
Yj5jfvRVal0mOwMvFyHVewU=
=SAR5
-----END PGP SIGNATURE-----
Thierry
access.
>
>
> The answer is that you create a domain group on
> the Samba server; add the users to that group,
> the assign that SID the SeDebugPrivilege right
> on the individual machines (not of the Samba DC).
> user rights are local to the machine on which they
> are assigned.
>
>
-open MMC
-Add the "Group Policy" snap-in
-Browse to Local Computer Policy\Computer Configuration\Windows
Settings\Security Settings\Local Policies\User Rights Assignment
-Open "Debug programs" entry
-Add "LAB\Debugger Users"
Which I've done.
Unfortunately there is that annoying little box on the right saying
"Effective Policy Setting" which remains NON-checked :-(
(While "Local Policy Setting" is checked)
What am I missing that would actually grant these rights locally ?
Thanks for your help again!
Cheers
Thierry
Jean-Jacques Moulis
T> Isn't that pretty much :
T> -open MMC
T> -Add the "Group Policy" snap-in
T> -Browse to Local Computer Policy\Computer Configuration\Windows
T> Settings\Security Settings\Local Policies\User Rights Assignment
T> -Open "Debug programs" entry
T> -Add "LAB\Debugger Users"
T> Which I've done.
T> Unfortunately there is that annoying little box on the right saying
T> "Effective Policy Setting" which remains NON-checked :-(
T> (While "Local Policy Setting" is checked)
T>
T> What am I missing that would actually grant these rights locally ?
You probably need to reboot for the rights to be effective.
Anyway, you could (as we do) add the domain group "LAB\Debugger Users"
to the local group "Debugger Users" using:
Computer management ---> Local Users and groups ---> groups --->
Debugger Users ---> Add ....
The change is effective immediatly.
Our way to deal with the tools mentioned by JLB <j...@twu.net>
is to automatically reinstall the computer at every boot.
(the machines boot only from network).
for the screwdriver we have an alarm on the cabinet :-)
--
Jean-Jacques Moulis Tel: (013) 281684
ISY Fax: (013) 139282
Linköping University E-mail: j...@isy.liu.se
581 83 Linköping
Ilia Chipitsine
> | You're foolish if you think anyone with local
> | access to a workstation can't get into the
> | Admin account on their local machine.
>
> WoW! That was a really helpful response!
> And while correct, doesn't do anything to help
> the original poster.
>
> If I have an employee and I'll them I'm not
> going to give you admin access. And then the
> hack the box using local physical access, i'll
> just fire them. Problem solved. No more physical
> access.
It's almost impossible to fire people for that.
Due to statistics about one of hundred employee has
psychological deviations which cause him/here to "investigate"
something. In out company such an investigator pretty regularly
stays over the night in order to reinstall Windows just because
it's getting unusable after his actions once in a week.
People do not change and it's better to take them as they are than to fire
them.
>
>
> The answer is that you create a domain group on
> the Samba server; add the users to that group,
> the assign that SID the SeDebugPrivilege right
> on the individual machines (not of the Samba DC).
> user rights are local to the machine on which they
> are assigned.
another helpful information is to use SECEDIT for unattended installation
to automate such an operation. Samba domain doesn't support GPO theese
days, and assigning rights can be done either manually or by SECEDIT tool.