3.0a21: scripting with smbpasswd - bug or feature
I noticed that on samba 2.x, as root we can do "smbpasswd -a -s user passwd" without being prompt of anything. This is not working on 3.0a21. I will need to type in the password twice using the above command. Is this a feature to not allow passwords to be seen, or a bug that should be fixed? Chere
how to call smbpasswd from setuid program?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I'm developing a samba frontend which is called "Take a Joint" (Project page: http://www.linux-fuer-alle.de/mr/taj/). To allow users to share directories which should be protected by a password I need to call smbpasswd from my installed setuid program. Unfortunately I'm getting "smbpasswd must *NOT* be setuid root." because you don't test smbpasswd's setuid flags, but the effective user id. How could I add temporary users to smbpasswd file within my setuid program? Bye, Martin - -- http://www.linux-fuer-alle.de/mr/taj/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+T8aGRqiZxpiH/1ERAtKTAJ9BsZXpnQOjQlq20eauE+zuMI8csgCfYiy/ cRfqgNAMSaxDSiwhF2odB8c= =Uyoc -END PGP SIGNATURE-
SMBPASSWD 2.2.7a doesnt fallback to using port 139 (Solaris)
I'm trying to register my Samba box on the domain but smbpasswd doesn't seem to want to use port 139. It attempts a connect via port 445 but never tries on port 139. It just goes back to the command prompt: ./smbpasswd -D 9000 -r PDC -j DOMAIN Initialising global parameters params.c:pm_process() - Processing configuration file "/usr/local/samba/lib/smb.conf" . . . resolve_hosts: Attempting host lookup for name PDC<0x20> 1 addresses returned internal_resolve_name: returning 1 addresses: 172.31.1.1 Connecting to 172.31.1.1 at port 445 >/usr/local/samba/bin>echo $? >141 Mark
Re: Adding a couple of simple functions to smbpasswd for Samba 2.2.8
I like the idea. I think this needs to be in 2.2.8 so we can really make this the last 2.2 release. :-) Richard Sharpe wrote: > > Hi, > > If a user changes the NetBIOS name of their Samba PDC, or the DNS name, > when they have not set a NetBIOS name, their SID will change, and > workstations that have joined the domain will not be able to log on. > > This is because Samba uses the NetBIOS/DNS name to determine if it should > generate a SID. There is a small discussion of this up on > www.richardsharpe.com. > > Between Volker Lendeke and I, we have added support to Samba Head and > 3.0.0 that allows you to retrieve the old SID, which is still in the > secrets.tdb file, and place the SID into the correct entry in the > secrets.tdb if you ever get into that problem. > > Now, I was thinking of doing something similar for Samba 2.2.8. This will > involve modifying smbpasswd. For reasons of code simplicity, I have > abandoned my earlier thoughs of using 'smbpasswd -L -S ' to retrieve > the old SID and something similar to set the SID. > > Instead, I propose: > > smbpasswd -X > > to eXtract the old SID > > and > > msbpasswd -W S-1-5-21-x-y-z > > to Write the new SID as the domain SID for the current domain into the > secrets.tdb file. > > These are not a lot of coding, should not destabalize any existing code, > and will save at least some people some pain. > > Are there any comments? > > Regards > - > Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, > sharpe[at]ethereal.com, http://www.richardsharpe.com -- == Herb Lewis Silicon Graphics Networking Engineer 1600 Amphitheatre Pkwy MS-510 Strategic Software Organization Mountain View, CA 94043-1351 [EMAIL PROTECTED] Tel: 650-933-2177 http://www.sgi.com Fax: 650-932-2177 PGP Key: 0x8408D65D ==
Adding a couple of simple functions to smbpasswd for Samba 2.2.8
Hi, If a user changes the NetBIOS name of their Samba PDC, or the DNS name, when they have not set a NetBIOS name, their SID will change, and workstations that have joined the domain will not be able to log on. This is because Samba uses the NetBIOS/DNS name to determine if it should generate a SID. There is a small discussion of this up on www.richardsharpe.com. Between Volker Lendeke and I, we have added support to Samba Head and 3.0.0 that allows you to retrieve the old SID, which is still in the secrets.tdb file, and place the SID into the correct entry in the secrets.tdb if you ever get into that problem. Now, I was thinking of doing something similar for Samba 2.2.8. This will involve modifying smbpasswd. For reasons of code simplicity, I have abandoned my earlier thoughs of using 'smbpasswd -L -S ' to retrieve the old SID and something similar to set the SID. Instead, I propose: smbpasswd -X to eXtract the old SID and msbpasswd -W S-1-5-21-x-y-z to Write the new SID as the domain SID for the current domain into the secrets.tdb file. These are not a lot of coding, should not destabalize any existing code, and will save at least some people some pain. Are there any comments? Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
RE: smbpasswd and euid detection
> -Original Message- > From: Steve Langasek [mailto:[EMAIL PROTECTED]] > > Most people who understand how to bless suid powers on an executable > > are familiar with the ramifications of doing so. > > Are you hiring? Wherever you got this idea is somewhere I > think I'd like to be. ;) Wouldn't we all? ;)
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 03:56:39PM -0700, Craig Kelley wrote: > On Thu, 2 Jan 2003, Steve Langasek wrote: > > On Thu, Jan 02, 2003 at 02:23:09PM -0700, Craig Kelley wrote: > > > > I consider confusing smbpasswd with the Unix passwd command a sign that > > > > one doesn't really have that much knowledge, at least where smbpasswd > > > > itself is concerned. It's easy to jump to the conclusion that smbpasswd > > > > needs root privs to make changes to the smbpasswd file -- it does not -- > > > > and the program has *not* been audited for use as an suid program, so > > > > it's dangerous to treat it the same as passwd. > > > > So if someone can run smbpasswd indirectly from an suid wrapper, there's > > > > still a high potential for security problems, the same as if smbpasswd is > > > > suid itself. If you need to let users call smbpasswd in an suid root > > > > context, your wrapper should do its own vetting of the user input and > > > > then assume full root privileges. > > > Then let's add suid checking to every program. > > Most programs don't have the problem of people assuming they're analogous > > to other suid programs. > Most people who understand how to bless suid powers on an executable > are familiar with the ramifications of doing so. Are you hiring? Wherever you got this idea is somewhere I think I'd like to be. ;) Cheers, -- Steve Langasek postmodern programmer msg05167/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, 2 Jan 2003, Steve Langasek wrote: > On Thu, Jan 02, 2003 at 02:23:09PM -0700, Craig Kelley wrote: > > > > I consider confusing smbpasswd with the Unix passwd command a sign that > > > one doesn't really have that much knowledge, at least where smbpasswd > > > itself is concerned. It's easy to jump to the conclusion that smbpasswd > > > needs root privs to make changes to the smbpasswd file -- it does not -- > > > and the program has *not* been audited for use as an suid program, so > > > it's dangerous to treat it the same as passwd. > > > > So if someone can run smbpasswd indirectly from an suid wrapper, there's > > > still a high potential for security problems, the same as if smbpasswd is > > > suid itself. If you need to let users call smbpasswd in an suid root > > > context, your wrapper should do its own vetting of the user input and > > > then assume full root privileges. > > > Then let's add suid checking to every program. > > Most programs don't have the problem of people assuming they're analogous > to other suid programs. Most people who understand how to bless suid powers on an executable are familiar with the ramifications of doing so. Having to write wrappers to deal with it could be even more dangerous (who knows...?) > > They can all be abused, and the same argument should apply. > > > Regardless, the patch I presented actually does what the the warning > > message claims it's doing. It stat()'s the actual binary of smbpasswd to > > see if it's suid or not. It doesn't add any dependencies, and it should > > work on all systems capable of handling geteuid(), which smbpasswd already > > uses. > > But if you're going to concede that the check is there for a reason > (which you seem to be doing by not asking for the check to be removed > altogether), then that reasoning applies whether or not smbpasswd itself > is the program carrying the suid bit as explained above. 'tis but a gift horse of a patch. Ignore it if you wish; at a minimum the warning should be changed to something more accurate and less heart-attack-inducing than "smbpasswd must *NOT* be setuid root" (because, most likely, it *isn't*); perhaps something like "smbpasswd will not run with root privileges if euid is not the same as uid because we believe in security through obscurity" ;) -- Craig Kelley -- [EMAIL PROTECTED] Turn In Your Neighbor Today! http://www.bsa.org/usa/report/report.php http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 02:23:09PM -0700, Craig Kelley wrote: > > I consider confusing smbpasswd with the Unix passwd command a sign that > > one doesn't really have that much knowledge, at least where smbpasswd > > itself is concerned. It's easy to jump to the conclusion that smbpasswd > > needs root privs to make changes to the smbpasswd file -- it does not -- > > and the program has *not* been audited for use as an suid program, so > > it's dangerous to treat it the same as passwd. > > So if someone can run smbpasswd indirectly from an suid wrapper, there's > > still a high potential for security problems, the same as if smbpasswd is > > suid itself. If you need to let users call smbpasswd in an suid root > > context, your wrapper should do its own vetting of the user input and > > then assume full root privileges. > Then let's add suid checking to every program. Most programs don't have the problem of people assuming they're analogous to other suid programs. > They can all be abused, and the same argument should apply. > Regardless, the patch I presented actually does what the the warning > message claims it's doing. It stat()'s the actual binary of smbpasswd to > see if it's suid or not. It doesn't add any dependencies, and it should > work on all systems capable of handling geteuid(), which smbpasswd already > uses. But if you're going to concede that the check is there for a reason (which you seem to be doing by not asking for the check to be removed altogether), then that reasoning applies whether or not smbpasswd itself is the program carrying the suid bit as explained above. -- Steve Langasek postmodern programmer msg05165/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, 2 Jan 2003, Steve Langasek wrote: > On Thu, Jan 02, 2003 at 01:27:01PM -0700, Craig Kelley wrote: > > On Thu, 2 Jan 2003, Steve Langasek wrote: > > > > On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: > > > > For some time now, I've been patching smbpasswd to get rid of the > > > > effective UID "detection" that it does. In 2.2.7a it simply tests if the > > > > effective UID differs from the real UID, and if the effective UID is > > > > 'root' then it bails: > > > > >/* Check the effective uid - make sure we are not setuid */ > > > >if ((geteuid() == (uid_t)0) && (getuid() != (uid_t)0)) > > > > > This test will bail out if smbpasswd isn't suid 0, but the process that > > > > calls it is (eg, a utility agent for changing passwords and such). I've > > > > made a preliminary diff to actually stat() the executable to determine if > > > > it is suid 0: > > > > Why does your suid application not either assume full root privileges, or > > > drop all such privileges, before exec()ing smbpasswd? > > > I've considered that, but thought of it more as treating the symptom > > instead of the cause. A better question may be, why even check for suid? > > Why should smbpasswd even care if it's running with effective privileges? > > The naive may confuse it with the UNIX passwd program, which is suid root > > on some systems, but those with that much knowledge surely understand the > > ramifications of giving superuser privileges to an executable. > > I consider confusing smbpasswd with the Unix passwd command a sign that > one doesn't really have that much knowledge, at least where smbpasswd > itself is concerned. It's easy to jump to the conclusion that smbpasswd > needs root privs to make changes to the smbpasswd file -- it does not -- > and the program has *not* been audited for use as an suid program, so > it's dangerous to treat it the same as passwd. > > So if someone can run smbpasswd indirectly from an suid wrapper, there's > still a high potential for security problems, the same as if smbpasswd is > suid itself. If you need to let users call smbpasswd in an suid root > context, your wrapper should do its own vetting of the user input and > then assume full root privileges. Then let's add suid checking to every program. They can all be abused, and the same argument should apply. Regardless, the patch I presented actually does what the the warning message claims it's doing. It stat()'s the actual binary of smbpasswd to see if it's suid or not. It doesn't add any dependencies, and it should work on all systems capable of handling geteuid(), which smbpasswd already uses. -- Craig Kelley -- [EMAIL PROTECTED] Turn In Your Neighbor Today! http://www.bsa.org/usa/report/report.php http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 01:27:01PM -0700, Craig Kelley wrote: > On Thu, 2 Jan 2003, Steve Langasek wrote: > > On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: > > > For some time now, I've been patching smbpasswd to get rid of the > > > effective UID "detection" that it does. In 2.2.7a it simply tests if the > > > effective UID differs from the real UID, and if the effective UID is > > > 'root' then it bails: > > >/* Check the effective uid - make sure we are not setuid */ > > >if ((geteuid() == (uid_t)0) && (getuid() != (uid_t)0)) > > > This test will bail out if smbpasswd isn't suid 0, but the process that > > > calls it is (eg, a utility agent for changing passwords and such). I've > > > made a preliminary diff to actually stat() the executable to determine if > > > it is suid 0: > > Why does your suid application not either assume full root privileges, or > > drop all such privileges, before exec()ing smbpasswd? > I've considered that, but thought of it more as treating the symptom > instead of the cause. A better question may be, why even check for suid? > Why should smbpasswd even care if it's running with effective privileges? > The naive may confuse it with the UNIX passwd program, which is suid root > on some systems, but those with that much knowledge surely understand the > ramifications of giving superuser privileges to an executable. I consider confusing smbpasswd with the Unix passwd command a sign that one doesn't really have that much knowledge, at least where smbpasswd itself is concerned. It's easy to jump to the conclusion that smbpasswd needs root privs to make changes to the smbpasswd file -- it does not -- and the program has *not* been audited for use as an suid program, so it's dangerous to treat it the same as passwd. So if someone can run smbpasswd indirectly from an suid wrapper, there's still a high potential for security problems, the same as if smbpasswd is suid itself. If you need to let users call smbpasswd in an suid root context, your wrapper should do its own vetting of the user input and then assume full root privileges. -- Steve Langasek postmodern programmer msg05159/pgp0.pgp Description: PGP signature
Re: smbpasswd and euid detection
On Thu, 2 Jan 2003, Steve Langasek wrote: > On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: > > For some time now, I've been patching smbpasswd to get rid of the > > effective UID "detection" that it does. In 2.2.7a it simply tests if the > > effective UID differs from the real UID, and if the effective UID is > > 'root' then it bails: > > >/* Check the effective uid - make sure we are not setuid */ > >if ((geteuid() == (uid_t)0) && (getuid() != (uid_t)0)) > > > This test will bail out if smbpasswd isn't suid 0, but the process that > > calls it is (eg, a utility agent for changing passwords and such). I've > > made a preliminary diff to actually stat() the executable to determine if > > it is suid 0: > > Why does your suid application not either assume full root privileges, or > drop all such privileges, before exec()ing smbpasswd? Hi Steve, I've considered that, but thought of it more as treating the symptom instead of the cause. A better question may be, why even check for suid? Why should smbpasswd even care if it's running with effective privileges? The naive may confuse it with the UNIX passwd program, which is suid root on some systems, but those with that much knowledge surely understand the ramifications of giving superuser privileges to an executable. I can't recall any other userland tool that I've used checking for effective = real root privileges (well, I suppose perl is able to, but that behavior can be disabled). I know that in the 1.x days, it didn't check until a certain version in which it was turned on; probably for security reasons (?) -- Craig Kelley -- [EMAIL PROTECTED] Turn In Your Neighbor Today! http://www.bsa.org/usa/report/report.php http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
Re: smbpasswd and euid detection
On Thu, Jan 02, 2003 at 10:47:32AM -0700, Craig Kelley wrote: > For some time now, I've been patching smbpasswd to get rid of the > effective UID "detection" that it does. In 2.2.7a it simply tests if the > effective UID differs from the real UID, and if the effective UID is > 'root' then it bails: >/* Check the effective uid - make sure we are not setuid */ >if ((geteuid() == (uid_t)0) && (getuid() != (uid_t)0)) > This test will bail out if smbpasswd isn't suid 0, but the process that > calls it is (eg, a utility agent for changing passwords and such). I've > made a preliminary diff to actually stat() the executable to determine if > it is suid 0: Why does your suid application not either assume full root privileges, or drop all such privileges, before exec()ing smbpasswd? -- Steve Langasek postmodern programmer msg05154/pgp0.pgp Description: PGP signature
smbpasswd and euid detection
Hello Samba folks; For some time now, I've been patching smbpasswd to get rid of the effective UID "detection" that it does. In 2.2.7a it simply tests if the effective UID differs from the real UID, and if the effective UID is 'root' then it bails: /* Check the effective uid - make sure we are not setuid */ if ((geteuid() == (uid_t)0) && (getuid() != (uid_t)0)) This test will bail out if smbpasswd isn't suid 0, but the process that calls it is (eg, a utility agent for changing passwords and such). I've made a preliminary diff to actually stat() the executable to determine if it is suid 0: http://otc.isu.edu/smbpasswd-euid.diff -- Craig Kelley -- [EMAIL PROTECTED] Turn In Your Neighbor Today! http://www.bsa.org/usa/report/report.php http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
Re: smbpasswd replication
richard wrote: > > Can't see how Steve? Unless you mean sharing usernames across multiple > pcs in different offices. To clarify: > our network consists of 4 offices linked by vpns through the internet. > At present we auth to an Nt4 pdc in main office which works fine until > "telstra" our isp goes down...hence my need for a "bdc" type of backup > authentication. > For us the chance of the same user/password being modified on two > different servers at the same time is negligible. and if we only > replicate the individual user/passwords that change the whole database > should remain in a consistent stateunless I've missed something? > Richard. So why don't you use a real BDC setup (either NT->NT or Samba->Samba)? Authenticaion works fine while the PDC is unreachable, and involves no link traffic. Only changes go from PDC -> BDC, and you can use a proven setup like LDAP to do it. Clients 'know' to contact the PDC when they want to chase somthing. You *really* don't want changes on the indiviual servers. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: smbpasswd replication
Can't see how Steve? Unless you mean sharing usernames across multiple pcs in different offices. To clarify: our network consists of 4 offices linked by vpns through the internet. At present we auth to an Nt4 pdc in main office which works fine until "telstra" our isp goes down...hence my need for a "bdc" type of backup authentication. For us the chance of the same user/password being modified on two different servers at the same time is negligible. and if we only replicate the individual user/passwords that change the whole database should remain in a consistent stateunless I've missed something? Richard. On Fri, 2002-10-11 at 14:31, Steve Langasek wrote: > On Fri, Oct 11, 2002 at 02:18:48PM +1000, richard wrote: > > my first thoughts too. but to synchronise the data to and from 6 samba > > servers I need to real careful...example: > > rsync -au local_file 1.2.3.4:remote_file > > will sync the entire contents of the file. If another user happens to > > changing their password on the destination pc at this moment they get > > overwritten, we have a replicated mess. I think by replicating single > > user changes only at one time there is much reduced chance of trouble. > > Hopefully a simple reliable system without the complication of ldap > > etc.. I don't know if anyone has already tried this? > > Richard. > > Such a system would be neither simple, nor reliable; it would still be > possible for changes to be made on two machines to one account in the > same rsync window, resulting in one set of changes being lost. It is > much simpler to designate a "master" server (a PDC) that all update > requests are sent to, then use rsync to propogate the master file out to > other servers. > > Steve Langasek > postmodern programmer
Re: smbpasswd replication
On Fri, Oct 11, 2002 at 02:18:48PM +1000, richard wrote: > my first thoughts too. but to synchronise the data to and from 6 samba > servers I need to real careful...example: > rsync -au local_file 1.2.3.4:remote_file > will sync the entire contents of the file. If another user happens to > changing their password on the destination pc at this moment they get > overwritten, we have a replicated mess. I think by replicating single > user changes only at one time there is much reduced chance of trouble. > Hopefully a simple reliable system without the complication of ldap > etc.. I don't know if anyone has already tried this? > Richard. Such a system would be neither simple, nor reliable; it would still be possible for changes to be made on two machines to one account in the same rsync window, resulting in one set of changes being lost. It is much simpler to designate a "master" server (a PDC) that all update requests are sent to, then use rsync to propogate the master file out to other servers. Steve Langasek postmodern programmer msg03657/pgp0.pgp Description: PGP signature
Re: smbpasswd replication
my first thoughts too. but to synchronise the data to and from 6 samba servers I need to real careful...example: rsync -au local_file 1.2.3.4:remote_file will sync the entire contents of the file. If another user happens to changing their password on the destination pc at this moment they get overwritten, we have a replicated mess. I think by replicating single user changes only at one time there is much reduced chance of trouble. Hopefully a simple reliable system without the complication of ldap etc.. I don't know if anyone has already tried this? Richard. On Fri, 2002-10-11 at 13:04, Andrew Morgan wrote: > > > On 11 Oct 2002, richard wrote: > > > > > is it possible to configure/modify smbpasswd to save individual > > user_smbpasswd files instead of one large file? Then it would be easy to > > use rsync to replicate changed only files through the domain. > > Please reply to this email as I am not subscribed to this list. > > R Coates. > > It was my understanding that the rsync protocol only sent the differences > in a file across the link, so I would expect that rsync'ing the single > smbpasswd file would be nearly as efficient. > > Andy >
Re: smbpasswd replication
On 11 Oct 2002, richard wrote: > > is it possible to configure/modify smbpasswd to save individual > user_smbpasswd files instead of one large file? Then it would be easy to > use rsync to replicate changed only files through the domain. > Please reply to this email as I am not subscribed to this list. > R Coates. It was my understanding that the rsync protocol only sent the differences in a file across the link, so I would expect that rsync'ing the single smbpasswd file would be nearly as efficient. Andy
smbpasswd replication
is it possible to configure/modify smbpasswd to save individual user_smbpasswd files instead of one large file? Then it would be easy to use rsync to replicate changed only files through the domain. Please reply to this email as I am not subscribed to this list. R Coates.
Re: Importing smbpasswd with pdbedit -i
This is probably a 2.2-problem. The 2.2 pdbedit --import option works different than the one in HEAD. The 2.2 --import is a special function that tries to read smbpasswd like files while the HEAD --import option uses the code from whatever backend you specify to it. Jelmer > I do not what's wrong in pdbedit, works fine for me (I use HEAD). > On Mon, 2002-07-08 at 11:58, [EMAIL PROTECTED] wrote: > > Hi, > > I used pdbedit -i to import my old /etc/smbpasswd into a NIS+ table. > > pdbedit generated for Workstationaccounts entries like this: > > degpd060w147$:1064:3128:502:2005:[U ]:C39B59E02D... > > well, the workstation can log into the domain and works quite well, but > > when you throw away the old installation on the client and then want to > > join the workstation (with the same name) again, Samba is unable to delete > > the workstation account and create a new one. > > I worte a little script to fix up all Workstation Accounts to be like > > this: > > degpd060w147$:1064:3128:502:2005:[W ]:C39B59E02D... > > Is it possible to correct the behavior of pdbedit? > > Yes, I'm using Samba 2.2.5 > > regards Thomas > > -- > > German Parcel > > Thomas Mieslinger > > German-Parcel-Str. 1-7 fon: +49 6677 17 463 > > 36286 Neuensteinfax: +49 6677 17 111 > > Germany eMail: [EMAIL PROTECTED] > -- > Simo Sorce - [EMAIL PROTECTED] > Xsec s.r.l. > via Durando 10 Ed. G - 20158 - Milano > tel. +39 02 2399 7130 - fax: +39 02 700 442 399 -- Jelmer Vernooij <[EMAIL PROTECTED]> - http://nl.linux.org/~jelmer/ Development And Underdevelopment: http://library.thinkquest.org/C0110231/ Listening to Error: The server (moosicd) doesn't seem to be running. 20:42:44 up 19:07, 5 users, load average: 2.49, 5.34, 5.88
Re: Importing smbpasswd with pdbedit -i
I do not what's wrong in pdbedit, works fine for me (I use HEAD). Simo. On Mon, 2002-07-08 at 11:58, [EMAIL PROTECTED] wrote: > Hi, > > I used pdbedit -i to import my old /etc/smbpasswd into a NIS+ table. > pdbedit generated for Workstationaccounts entries like this: > degpd060w147$:1064:3128:502:2005:[U ]:C39B59E02D... > > well, the workstation can log into the domain and works quite well, but > when you throw away the old installation on the client and then want to > join the workstation (with the same name) again, Samba is unable to delete > the workstation account and create a new one. > > I worte a little script to fix up all Workstation Accounts to be like > this: > degpd060w147$:1064:3128:502:2005:[W ]:C39B59E02D... > > Is it possible to correct the behavior of pdbedit? > > Yes, I'm using Samba 2.2.5 > > regards Thomas > -- > German Parcel > Thomas Mieslinger > German-Parcel-Str. 1-7 fon: +49 6677 17 463 > 36286 Neuensteinfax: +49 6677 17 111 > Germany eMail: [EMAIL PROTECTED] > -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: smbpasswd->passwd how to{smbpasswd database is corrupt. usernamenot in unix passwd database}
On Thu, 1 Aug 2002, san wrote: > Dear Samba Users > > I tried pwdump to extract username from win2k, later when i replaced it > smbpasswd directly, > > now when i am trying to login thru windows 2000 pro workstation, i am > getting the following error > > " > > [2002/08/01 19:40:03, 0] smbd/reply.c:reply_sesssetup_and_X(890) > restrict anonymous is True and anonymous connection attempted. Denying > access. > [2002/08/01 19:40:04, 0] smbd/reply.c:reply_sesssetup_and_X(890) > restrict anonymous is True and anonymous connection attempted. Denying > access. > [2002/08/01 19:40:06, 0] smbd/reply.c:reply_sesssetup_and_X(890) > restrict anonymous is True and anonymous connection attempted. Denying > access. > [2002/08/01 20:08:03, 0] passdb/pdb_smbpasswd.c:build_sam_account(1192) > build_sam_account: smbpasswd database is corrupt! username GUEST$ not in > unix > passwd database! > [2002/08/01 20:08:03, 0] rpc_server/srv_netlog_nt.c:get_md4pw(176) > get_md4pw: Workstation guest$: no account in domain > > " > > how do i solve >From Samba 101. All windows accesses or logons need a local UID! In this case you need an account called guest$ in the passwd database. The Samba PDC FAQ also points this out. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
smbpasswd->passwd how to{smbpasswd database is corrupt. username not in unix passwd database}
Dear Samba Users I tried pwdump to extract username from win2k, later when i replaced it smbpasswd directly, now when i am trying to login thru windows 2000 pro workstation, i am getting the following error " [2002/08/01 19:40:03, 0] smbd/reply.c:reply_sesssetup_and_X(890) restrict anonymous is True and anonymous connection attempted. Denying access. [2002/08/01 19:40:04, 0] smbd/reply.c:reply_sesssetup_and_X(890) restrict anonymous is True and anonymous connection attempted. Denying access. [2002/08/01 19:40:06, 0] smbd/reply.c:reply_sesssetup_and_X(890) restrict anonymous is True and anonymous connection attempted. Denying access. [2002/08/01 20:08:03, 0] passdb/pdb_smbpasswd.c:build_sam_account(1192) build_sam_account: smbpasswd database is corrupt! username GUEST$ not in unix passwd database! [2002/08/01 20:08:03, 0] rpc_server/srv_netlog_nt.c:get_md4pw(176) get_md4pw: Workstation guest$: no account in domain " how do i solve
rpcclient & smbpasswd to test samba
Hi there, I am new to this list and enter with couple of questions. This is my first one. Version: 2.2.3a I want to enhance rpcclient code to view user details at level 18(SAM_USER_INFO_12). Server checks whether user, who is asking info logged in as root and through ntlmssp. I started looking at the possibilities to use ntlm authentication by rpcclient. I made a quick hack in the code. This may look agly but i wanted to make it quickly [I would appreciate, if i get a quick elegant solution]. The following is the inserted code in rpcclient/cmd_samr.c:cmd_samr_query_user slprintf (server, sizeof(fstring)-1, "%s", cli->desthost); strupper (server); /* Set NTLM flags */ cli_nt_set_ntlmssp_flgs(cli, NTLMSSP_NEGOTIATE_UNICODE | NTLMSSP_NEGOTIATE_OEM | NTLMSSP_NEGOTIATE_SIGN | NTLMSSP_NEGOTIATE_SEAL | NTLMSSP_NEGOTIATE_LM_KEY | NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_ALWAYS_SIGN | NTLMSSP_NEGOTIATE_1000 | NTLMSSP_NEGOTIATE_2000); /* Open SAMR Session. Negotiate credentials */ cli->nt_pipe_fnum = 0; /* To make the following function happy */ cli_nt_session_open(cli, PIPE_SAMR); result = cli_samr_connect(cli, mem_ctx, MAXIMUM_ALLOWED_ACCESS, &connect_pol); - This is what i got in the server. --- [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(500) 0022 stub_type_len: 08 [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(500) 0023 padding : 00 [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(558) 0024 unknown : 0001 [2002/07/17 18:06:05, 5] rpc_server/srv_pipe.c:(1073) api_pipe_auth_process: auth 44 [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(60) 28 smb_io_rpc_auth_ntlmssp_chk auth_sign [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(558) 0028 ver : 0001 [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(558) 002c reserved: [2002/07/17 18:06:05, 5] rpc_parse/parse_prs.c:(558) 0030 crc32 : 3c63076f [2002/07/17 18:06:05, 0] rpc_parse/parse_prs.c:(452) prs_mem_get: reading data of size 4 would overrun buffer. [2002/07/17 18:06:05, 0] rpc_server/srv_pipe.c:(1087) api_pipe_auth_process: failed to unmarshall RPC_AUTH_NTLMSSP_CHK. [2002/07/17 18:06:05, 0] rpc_server/srv_pipe_hnd.c:(482) process_request_pdu: failed to do auth processing. [2002/07/17 18:06:05, 10] rpc_server/srv_pipe_hnd.c:(283) set_incoming_fault: Setting fault state on pipe samr : pnum = 0x752d [2002/07/17 18:06:05, 3] rpc_server/srv_pipe_hnd.c:(646) process_complete_pdu: DCE/RPC fault sent on pipe lsass [2002/07/17 18:06:05, 10] rpc_server/srv_pipe_hnd.c:(283) set_incoming_fault: Setting fault state on pipe samr : pnum = 0x752d --- Any ideas? or any suggestions? Please ask me, if information is not enough. I will give you more. 2. Does "smbpasswd -r remotemachine -U remoteuser" work properly? Here is my error. machine remotemachine rejected the password change: Error was : RAP86: The specified password is invalid. Failed to modify password entry for user remoteuser. Here is server log. [2002/07/17 19:29:58, 3] smbd/sec_ctx.c:(420) pop_sec_ctx (101, 101) - sec_ctx_stack_ndx = 0 [2002/07/17 19:29:58, 0] smbd/chgpasswd.c:(817) check_oem_password: incorrect password length (-730175364). [2002/07/17 19:29:58, 5] smbd/ipc.c:(62) copy_trans_params_and_data: params[0..2] data[0..0] If i asked redundant questions, kindly give me a pointer. Thanks a lot, GV visolve.com __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Importing smbpasswd with pdbedit -i
Hi, I used pdbedit -i to import my old /etc/smbpasswd into a NIS+ table. pdbedit generated for Workstationaccounts entries like this: degpd060w147$:1064:3128:502:2005:[U ]:C39B59E02D... well, the workstation can log into the domain and works quite well, but when you throw away the old installation on the client and then want to join the workstation (with the same name) again, Samba is unable to delete the workstation account and create a new one. I worte a little script to fix up all Workstation Accounts to be like this: degpd060w147$:1064:3128:502:2005:[W ]:C39B59E02D... Is it possible to correct the behavior of pdbedit? Yes, I'm using Samba 2.2.5 regards Thomas -- German Parcel Thomas Mieslinger German-Parcel-Str. 1-7 fon: +49 6677 17 463 36286 Neuensteinfax: +49 6677 17 111 Germany eMail: [EMAIL PROTECTED]
Re: Smbpasswd
Have you transfered also the (/etc[/samba/]/)smbpasswd file? Is it a domain? In this case have you copied over MACHINE.SID / secrets.tdb files? On Mon, 2002-07-01 at 14:04, kelvin wrote: > Hi, > > I am in the process of tranfering my samba users(around 150) from a > Redhat6.1 server to a new Redhat7.3 server. I have successfully tranfered > the smbusers file to the new 7.3 server.I have also tranfered over the > passwd file,group file and shadow file over successfully.Now, my users are > not able to access their 'home' drive from their pcs. In the previous 6.1 > server, I have synchronize all of their password together with > smbpassword.Can you help? > Thanks. > > Kelvin > > -- Simo Sorce -- Una scelta di liberta': Software Libero. A choice of freedom: Free Software. http://www.softwarelibero.it
Smbpasswd
Hi, I am in the process of tranfering my samba users(around 150) from a Redhat6.1 server to a new Redhat7.3 server. I have successfully tranfered the smbusers file to the new 7.3 server.I have also tranfered over the passwd file,group file and shadow file over successfully.Now, my users are not able to access their 'home' drive from their pcs. In the previous 6.1 server, I have synchronize all of their password together with smbpassword.Can you help? Thanks. Kelvin
Re: problem with smbpasswd -a with ldap in HEAD
On Thu, May 02, 2002 at 08:31:38PM -0400, Bradley W. Langhorst wrote: > I'm not able to add a new user to LDAP using > smbpasswd -a because it does not seem to set the > required RID field. I'm assuming you are using Samba 3.0/HEAD. You have to have the unix user setup first, or be running with the 'non unix account' feature. If you don't have either of these, you can't add the user. Andrew Bartlett
problem with smbpasswd -a with ldap in HEAD
I'm not able to add a new user to LDAP using smbpasswd -a because it does not seem to set the required RID field. here's the -D 10 output New SMB password: Retype new SMB password: Trying to load: ldapsam Attempting to find an passdb backend to match ldapsam (ldapsam) Found pdb backend ldapsam (at pos 4) pdb backend ldapsam has a valid init ldapsam_open_connection: ldap://localhost ldap_open_connection: connection opened ldap_connect_system: Binding to ldap server as "cn=ldapadmin,dc=bitc,dc=unh,dc=edu" ldap_connect_system: successful connection to the LDAP server ldapsam_search_one_user: searching for:[(&(uid=testuser)(objectclass=sambaAccount))] We didn't find the user [testuser] count=0 pdb_set_username: setting username testuser, was tdb(unnamed): tdb_brlock failed (fd=5) at offset 4 rw_type=1 lck_type=13 account_policy_get: maximum password age:1814400 ldapsam_open_connection: ldap://localhost ldap_open_connection: connection opened ldap_connect_system: Binding to ldap server as "cn=ldapadmin,dc=bitc,dc=unh,dc=edu" ldap_connect_system: successful connection to the LDAP server ldapsam_search_one_user: searching for:[(&(uid=testuser)(objectclass=sambaAccount))] ldapsam_search_one_user: searching for:[uid=testuser] Adding new user Setting entry for user: testuser NO user RID specified on account testuser, cannot store! ldapsam_add_sam_account: init_ldap_from_sam failed! Failed to add entry for user testuser. Failed to modify password entry for user testuser I'll probably hack on this tomorrow unless somebody advises otherwise brad
Changing domain passwords with smbpasswd
Hello all, I'm trying to use smbpasswd to change the password for a user who's a member of an Active Directory domain (running in NT domain compatibility mode). The purpose of this is to have a web interface to allow users to change their passwords and keep track of various things like that. I had this working previously with a -really- old version of rpcclient that still had the 'ntpass' command. I believe that rpcclient might have even been from an early samba-tng. That broke when we went to AD, so I'm trying to use a newer version of Samba, 2.2.3a. Anyway, so I'm figuring that smbpasswd is what I want to change a user's password on a remote machine. However, I've been trying with no luck to find the magic combination of arguments to get that to work. What I tried first was: smbpasswd -U Admin%password -r DC user pass ... interpreting the -U and -r flags to mean the account to use to change the password and the server to connect to, respectively. That just displays the help page as if I have an invalid argument. I've also tried various combinations of those using the username of the account I want to change in the -U argument. None of the combinations I tried would allow smbpasswd to connect to the remote server and try to change the password. What am I missing? All I need is to be able to connect to a remote DC and change the password for a user, preferably having the permissions of another user (administrator rights) so that a user can change their password even if 'user cannot change password' is set in the user's policy. Thanks, James Willard [EMAIL PROTECTED]
