 |
Vitalnix |
: User Management Suite |
| |
manual |
v1.0.21.7 |
Name 
accdb_mig - The Migration service back-end
Description
The Migration service back-end eases the transition between
two databases in that it reads users from all specified back-end modules, and
only writes them to the destination back-end, deleting the old user in the old
database. Consider these scenarios:
Scenario I
1. Current state: Every password is transmitted as
plaintext by Windows 98, so that SAMBA can encrypt it at the server side using
DES (or any other), to check it against /etc/shadow.
2. Migration: Windows 98 will still transmit passwords
as plaintext. SAMBA will query Vitalnix for that user, receiving an entry with
a DES password. SAMBA will then encrypt the password with the DES method to
compare it.
If authentication succeeds, the plaintext password is
reencrypted using the NTLM method, the user entry in /etc/shadow is
deleted, and a new account is instantiated on the LDAP server, with same UID,
GID, and password.
3. Finalization: When most of the users have a NTLM
password (best-case: all users), encryption can be turned on on the Windows 98
side. SAMBA will receive a NTLM password from W98, and comapre it against what
is stored in Vitalnix. (And to round this up: Windows 2000 only "works" when
using encrypted passwords.)
The trick: SAMBA does not know where it reads from or
writes to. It merely knows that it changes the password (or, the encryption
scheme of the password). Now, it does not need to be LDAP, but just the fact
that writing to Vitalnix changes underlying databases!
Scenario II
Let's put the transmission of plaintext passwords over the
network aside and face this: your /etc/shadow still contains
weak DES passwords? Even though they are encrypted with a one-way
cipher, SAMBA (or vlogin, for example) gets the plaintext passwords, and can
convert them to more secure Blowfish passwords upon successful
authentication.
Compare: how many people have access to your private network
for packet sniffing? At home, only your friends. At work, only personnel
(mostly). How many intruders can get into your server shell due to a root
exploit and catch /etc/shadow? Everyone.
And about the plaintext issue, see Scenario I, however NTLM
encryption is even weaker than DES despite it is more recent.
Configuration file
Currently, two options are recognized in
libaccdb/mig.
RD_LIST is a comma separated value of back-ends to
read users from.
WD_LIST is a comma separated value of back-ends to
write users to. Note that the first WD back-end is also queried for users, but
all other WD back-ends are only mirros for the first. That is, if you query a
user with Vitalnix, the search order is WD0, RD0,
RD1, etc. When you write a user, the q_usermod() (or similar)
command is executed for all WD back-ends, to synchronize them.
Please note that WD back-ends do not auto-synchronize, that
is, they do not detect if WD0 has a user that WD2 is
missing. You usually only need multiple WD back-ends for backup, and if that is
the case, you can simply copy WD0 over by hand. (I assume there are specialed
tools for that back-end.)
|