Lars Appel wrote:

....

>   Samba takes some measures to overcome case-folding (upper/lower)
>   and also offers a username map file but this does not currently
>   help with the "userpass,acctpass" part.
>
After some initial problems with Samba/iX and WfWg clients there seem to
be no problems with upper/lower case at our site...

....

> - Samba/iX currently does allow every valid MPE user to connect as
>   "validated" user. If you have a [homes] section, every user can
>   connect to his home directory (home group) -- of course, he has
>   to be able to specify valid "userpass,acctpass" for this.
>
>   Is there a smb.conf directive to allow/disallow usernames?
>
The "valid users" and/or "invalid users" statements are appropriate for
this purpose. Maybe some additional adjustments can be done through
INETDSEC.NET.SYS (at least if Samba/iX runs under inetd), but I'm not
sure about it...

> - Samba/iX uses AIF calls to retrieve user and account passwords
>   during user validation. This will not work on systems using some
>   kind of encrypted passwords (i.e. HP Security Monitor).
>
We don't use encrypted passwords in our shop, nevertheless this is a
problem which needs to be resolved (and would be resolved) with the
suggested mapping of MPE-style logon to UNIX-style logon...

....
>
> The mapping should (preferably) use the textual forms of USER.ACCT
> and ACCT instead of numeric UID and GID. Otherwise the mapping might
> be accidentally "broken"/"corrupted" when a PURGEUSER or PURGEACCT
> is done without adjusting the passwd file (a newly created user or
> account might "reuse" the UID or GID values and become accessible by
> the "forgotten mapping").
>
The textual form would be more comfortable to use, too...

....

> PRO's:
>
> - Samba/iX would appear more like Unix/NT servers to the client side,
>   MPE-style USERNAME.ACCTNAME and userpass,acctpass no longer needed.
>
I wouldn't care about this in a shop that only runs MPE servers as all
users are familiar with the USER.ACCOUNT concept. It could even be
desirable to rely on MPE security features. Being not familiar with UNIX
I personally would prefer the MPE-style logon. On the other hand: In a
"mixed" environment I would appreciate a UNIX-style logon to Samba/iX.
How about to allow both ways to logon to Samba/iX (i.e. use MPE-style
logon in case of the absence of a /etc/passwd file, otherwise grant
UNIX-style logon)?

> - MANAGER.SYS can define the subset of users given Samba/iX access,
>   for example excluding potentially dangerous users like MGR.TELESUP
>   or MANAGER.SYS by not adding them to /xxx/passwd.
>
See above ("valid/invalid users")...

....
> CON's:
>
> - The /xxx/passwd file would be readable to everyone (just like in
>   the Unix world). The passwords are encrypted but as far as I know
>   there are ways to crack them, at least if simple passwords are
>   choosen (brute force crypt a whole spell-checker dictionary and
>   see of one of them matches).
>
> - The whole user validation no longer relies on the MPE password(s)
>   but uses only the /xxx/passwd password scheme.
>

That's just why someone could prefer the MPE-style logon...

> PS: Anybody using Samba with share-level security instead user-level?

Hmmm... In our environment we're only able to use share-level security.
Every connection attempt fails (including guest services) if using
"security=user" in smb.conf!

Andreas