PR #s 25271, 25273, 25445 security=domain does not work onSolaris

2002-09-09 Thread Tim Allen

The first bug submission was rejected, as SPAM
The second was rejected, no reason given.
The third one is still incoming.

I have posted to this group in the past and been told that the behavior
I'm seeing is not correct. My main file server (Samba/Linux) does not
behave this way (similar smb.conf). Can anyone advise me what's wrong
with my bug submissions. I don't want to waste anyone's time but this is
either a program bug or a documentation bug (I've read the FAQs, docs,
and mailing list archives- did I miss something?). Does someone need to
sponsor my bug.

http://bugs.samba.org/?findid=25271  

http://bugs.samba.org/?findid=25273 

http://bugs.samba.org/?findid=25445




Re: PR #s 25271, 25273, 25445 security=domain does not work onSolaris

2002-09-09 Thread David Collier-Brown

Tim Allen wrote:
 I have posted to this group in the past and been told that the behavior
 I'm seeing is not correct. My main file server (Samba/Linux) does not
 behave this way (similar smb.conf). 

And the symptom was:
| I have posted to the user groups and think I have found a bug. Our
| RHL6.2 box running samba 2.0.6 is a member of our NT domain. An NT
user
| (say jbloggs) cannot browse the unix/samba box unless there is a
| corresponding unix user (jbloggs) on the unix box; this is the
expected
| (and correct??!) behavior. We have added samba 2.2.2 to one of our
Sun
| boxes (Solaris 8) and now we appear to have to add users to the
| smbusers file in addition to (or instead of) just having a
| corresponding unix user. I will supply further information
(smb.conf,
| log files, whatever) as requested.

You normally need a Unix user, but if you wish to use
the NT form of encrypted passwords, you also have
to have an entry for the user in the smbpasswd file.
As security=domain requires encrypted passwords,
I'm afraid you're stuck with it!

I run inside a firewall, and so don't use domains.


--dave (security = user) c-b
-- 
David Collier-Brown,   | Always do right. This will gratify 
Performance  Engineering  | some people and astonish the rest.
Americas Customer Engineering, |  -- Mark Twain
(905) 415-2849 | [EMAIL PROTECTED]



Re: PR #s 25271, 25273, 25445 security=domain does not work onSolaris

2002-09-09 Thread Eric Boehm

On Mon, Sep 09, 2002 at 11:36:51AM -0400, David Collier-Brown wrote:
 David == David Collier-Brown [EMAIL PROTECTED] writes:
 Tim == Tim Allen [EMAIL PROTECTED] writes:

Tim I have posted to this group in the past and been told that
Tim the behavior I'm seeing is not correct. My main file server
Tim (Samba/Linux) does not behave this way (similar smb.conf).

Tim And the symptom was: I have posted to the user groups and
Tim think I have found a bug. Our RHL6.2 box running samba 2.0.6
Tim is a member of our NT domain. An NT user (say jbloggs) cannot
Tim browse the unix/samba box unless there is a corresponding
Tim unix user (jbloggs) on the unix box; this is the expected
Tim (and correct??!) behavior. We have added samba 2.2.2 to one
Tim of our Sun boxes (Solaris 8) and now we appear to have to add
Tim users to the smbusers file in addition to (or instead of)
Tim just having a corresponding unix user. I will supply further
Tim information (smb.conf, log files, whatever) as requested.

David  You normally need a Unix user, but if you wish to use
David the NT form of encrypted passwords, you also have to have
David an entry for the user in the smbpasswd file.  As
David security=domain requires encrypted passwords, I'm afraid
David you're stuck with it!


Are you sure about this? I've been running 2.0.7 for a couple of years
with security = domain and I don't need to create an smbusers
file. The only time I run into problems is if the Windows user does
not have a UNIX account. As long as the userid exists in the Windows
domain and NIS domain, it works fine (with encrypted passwords).

I am also running 2.2.5 with the same configuration.

It might be worthwhile to see Tim's smb.conf or a level 3 or level 5
log of a failed access.

Here's the relevant portion of mine

workgroup  = AMERICASE
security   = domain
password server= ZRTPD01T ZRTPD0P0 NRTPDE11
# 
wins server= 47.156.160.179
encrypt passwords  = yes 

-- 
Eric M. Boehm  /\  ASCII Ribbon Campaign
[EMAIL PROTECTED]   \ /  No HTML or RTF in mail
X   No proprietary word-processing
Respect Open Standards / \  files in mail



Re: PR #s 25271, 25273, 25445 security=domain does not work onSolaris

2002-09-09 Thread Richard Sharpe

On Mon, 9 Sep 2002, Eric Boehm wrote:

 On Mon, Sep 09, 2002 at 11:36:51AM -0400, David Collier-Brown wrote:
  David == David Collier-Brown [EMAIL PROTECTED] writes:
  Tim == Tim Allen [EMAIL PROTECTED] writes:
 
 DavidYou normally need a Unix user, but if you wish to use
 David the NT form of encrypted passwords, you also have to have
 David an entry for the user in the smbpasswd file.  As
 David security=domain requires encrypted passwords, I'm afraid
 David you're stuck with it!
 
 
 Are you sure about this? I've been running 2.0.7 for a couple of years
 with security = domain and I don't need to create an smbusers
 file. The only time I run into problems is if the Windows user does
 not have a UNIX account. As long as the userid exists in the Windows
 domain and NIS domain, it works fine (with encrypted passwords).

Well, its a fact that you need a UNIX user/account. In your case, the 
UID/account info is in NIS. Works great. If you are not using NIS, then 
you need a local account.

Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED]




RE: PR #s 25271, 25273, 25445 security=domain does not work onSolaris

2002-09-09 Thread Javid Abdul-AJAVID1

yes, i agree with Eric,
I havent had any issues as long as unix accunt exist in nis domain, and
samba is memeber server in nt domain
my setup, solaris6, samba 2 0 7 and  2 2 5, clients w2k

-Original Message-
From: Eric Boehm [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 09, 2002 12:24 PM
To: [EMAIL PROTECTED]
Cc: Tim Allen; [EMAIL PROTECTED]
Subject: Re: PR #s 25271, 25273, 25445 security=domain does not work
onSolaris


On Mon, Sep 09, 2002 at 11:36:51AM -0400, David Collier-Brown wrote:
 David == David Collier-Brown [EMAIL PROTECTED] writes:
 Tim == Tim Allen [EMAIL PROTECTED] writes:

Tim I have posted to this group in the past and been told that
Tim the behavior I'm seeing is not correct. My main file server
Tim (Samba/Linux) does not behave this way (similar smb.conf).

Tim And the symptom was: I have posted to the user groups and
Tim think I have found a bug. Our RHL6.2 box running samba 2.0.6
Tim is a member of our NT domain. An NT user (say jbloggs) cannot
Tim browse the unix/samba box unless there is a corresponding
Tim unix user (jbloggs) on the unix box; this is the expected
Tim (and correct??!) behavior. We have added samba 2.2.2 to one
Tim of our Sun boxes (Solaris 8) and now we appear to have to add
Tim users to the smbusers file in addition to (or instead of)
Tim just having a corresponding unix user. I will supply further
Tim information (smb.conf, log files, whatever) as requested.

David  You normally need a Unix user, but if you wish to use
David the NT form of encrypted passwords, you also have to have
David an entry for the user in the smbpasswd file.  As
David security=domain requires encrypted passwords, I'm afraid
David you're stuck with it!


Are you sure about this? I've been running 2.0.7 for a couple of years
with security = domain and I don't need to create an smbusers
file. The only time I run into problems is if the Windows user does
not have a UNIX account. As long as the userid exists in the Windows
domain and NIS domain, it works fine (with encrypted passwords).

I am also running 2.2.5 with the same configuration.

It might be worthwhile to see Tim's smb.conf or a level 3 or level 5
log of a failed access.

Here's the relevant portion of mine

workgroup  = AMERICASE
security   = domain
password server= ZRTPD01T ZRTPD0P0 NRTPDE11
# 
wins server= 47.156.160.179
encrypt passwords  = yes 

-- 
Eric M. Boehm  /\  ASCII Ribbon Campaign
[EMAIL PROTECTED]   \ /  No HTML or RTF in mail
X   No proprietary word-processing
Respect Open Standards / \  files in mail