your mail

[Danny Braniss]

In message <Pine.LNX.3.96.980523092052.643B-200000 at regent.cb1.com>you write:
}> One Time Password - we have these cards that generate a otp, for
}> people that login from untrusted-sites, and will be giving them out to
}> student's so they can work in the open spaces.
}
}so that's unix-side only, yes?  for which you do not use "encrypt password
}= yes"?

no, we have a gina thinggy that asks for the otp first, and if that's
ok then the regular nt logon is used, still experimental, but seems to
be working ok.

}oh dear.  what happens when you store trust accounts?  those do not _have_
}a clear-text password: you only get a 16 byte NT hash.

are you refering to 'administrator' priviled accounts? if so, we don't
allow privilged accounts login via the net, in case of unix, you first
have to login as a regular user and then do a su. in case of nt, for
the time being, you have to go to the ws, insert a 'special floppy'
and then you can gain 'priviliges'. we also have a rsh for nt which
allows priviliges only from certain hosts.

 [...]
}> 
}> im not planing, at this stage to run a BDC - i am runing with 2
}> namesevers, one NIS server, and one authentication-server and things
}> are very stable -- FLW (Famous Last Words :-). I might need a BDC if I
}> go ahead and subnet/vlan the network.
}
}i'm thinking of other people who might say "hey, that authentication
}server's cool.  _i_ want to run it in my existing 150,000 NT user-base
}because NT just doesn't scale properly".
}
the other reason for my AS, is that campus has many departamental
computers, and users cross boundaries all the time. when a user from
some other department wishes to use our computers, we  open a new
account for him but rely on his department for authetication, so if
the 'guest' is no longer a member of that department, he can no longer
use our resources. makes for less administration hassles. (this is
not campus wide yet, but we are working on it :-).

Samba scales very nicely too. Im mainly fluent in Unix, NT im
still quiet ignoramus. Most modern Unixes allow for different
authentication methods - ie. pam - the login process is quiet heavy,
and usually unknown, so a hook is usualy provided. in my ignorance i
see the PDC as the equiv. of login on unix, the authentication part
could be relegated to some other process - as i have been doing here.

}> }you also need it for checking the old password, when changing passwords.
}> }
}> to change the password, the API sends both the old and new, if ok then
}> the change is made - to all hashes - unix,nt,ln.
}
}... via the clear-text password?  [danny, when i refer to passwords i...
}adjectivise it?  clarify it?  whatever... specify its type.  there are
}four different password types _alone_ that can be discussed here: one of
}them (the unix crypted password) can be stored in several types of
}standard unix password databases].

the AS has several authentication-methods, the client requests the
type it's interested to authenticate, Unix/NT/LN/OTP/etc.
}
}i think you will find that in order to support even just a PDC properly
}you will need a get/add/mod - even if it means at the first stage passing
}the hashes in the clear (and trusting your users) for at _least_ the 16
}byte LM and 16 byte NT hashes, as well as the rest of the account
}information.
}
i will have to think this one out, in the mean time, if from the NT
side one cannot add users, change password then my version of PDC
would work? (and ignore BPC for now)

}  
}ahh, it's only a few meg.
}

yeh, but slowwwwwww, anyway i now have it!

     danny