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.)
|