minor bugs and structure questions..

[Kevin Stefanik]

I'm using samba on Digital Unix 4.0D with domain security.  The PDC is an
actual running NT4.0SP3.

I've been modifying swat to pass requests for local password changes to the
PDC, and then use the unix syncing function to also change the local
password.   (As an aside, I had to link swat over to smbd/chgpasswd.o in
order to do this with minimal coding effort -- is this a _bad thing_?)

In the course of that I found two locations that were comparing the return
values of file opens to zero, instead of -1 or a defined constant.  DG-UX
seems to return zeroes for valid file handles.  (I thought that this was
standard behavior across most systems, but I can't make that statement with
much authority) Is there a preferred cross-platform mechanism?

in lib/username.c:
    83   f = sys_fopen(mapfile,"r");
    84    if (!f) {
    85      DEBUG(0,("can't open username map %s\n",mapfile));
    86      return False;
    87    }

in smbd/chgpasswd.c:
    66  #if defined(HAVE_GRANTPT)
    67    if ((master = sys_open("/dev/ptmx", O_RDWR, 0)) >= 1) {

I had to change both of these to >=0 comparisons to avoid errors.


My real questions, though, relate to the password change mechanism.  I
change the code in swat to redirect the password changes and sync the unix
password, but that leaves the password in plaintext over the network.  Is
there any effort underway to perform encryption on these passwords?  

I also looked at changing the behavior of local_password_change to
accomplish what I wanted, namely, redirecting local password request changes
to the PDC when security=domain while still syncing passwords.  In that
case, though, the password syncing would have to take place as root (as
indicated in the code comments) and various exchanges on the other samba
lists indicated that this wasn't working.  Is that still the case?  Would we
need an alternative passwd chat (root passwd chat) to deal with this
situation?

Finally, when a remote password change is accomplished through swat to a
PDC, the Windows clients who have security tokens based on the old password
don't seem to deal with the situation gracefully.  For instance, if I use
swat to change my NT password on the PDC and the unix password on the
samba/swat server, then I can no longer access shared samba drives on the
swat server until I force the Windows client to reauthenticate with the PDC.
Can anything be done about this?  I don't know enough about NT's
authentication mechanisms to even guess.

I suspect that the way that I have this set up is really only useful to our
situation, but if what I'm trying to accomplish can be done somewhere else
in a way that's useful to the project, let me know.  I've put in the effort
to understand how the mechanisms are structured, so I should be able to
implement that kind of change. Kudos to the samba team for keeping the code
readable (at least those portions that aren't  implementing MS obfuscation
and hashing).

Kevin Stefanik