[Samba] Proper sysvol replication solution...

[Rowland Penny]

On 22/08/14 14:30, Ryan Ashley wrote:
> I know it is, on purpose. Copying the ACLs from one DC to another is 
> bad because for some reason each DC may have a different ID for the 
> built-in accounts. In fact I believe it was Rowland who was saying 
> something about copying the "idmap.tdb" file over if you sync the 
> ACLs. My method only copies over the files and directories so no ACLs 
> get screwy. Maybe Rowland can reiterate what he said on the other thread.

The problem with 'idmap.tdb' is, there is no way to ensure that they 
match, other than to copy the one on the first DC to any other DC's.

I will give you an example:

the stanza for 'Authenticated Users' , SID: S-1-5-11, on the first DC is:

dn: CN=S-1-5-11
cn: S-1-5-11
objectClass: sidMap
objectSid: S-1-5-11
type: ID_TYPE_BOTH
xidNumber: 3000003
distinguishedName: CN=S-1-5-11

But on the second DC:

dn: CN=S-1-5-11
cn: S-1-5-11
objectClass: sidMap
objectSid: S-1-5-11
type: ID_TYPE_BOTH
xidNumber: 3000013
distinguishedName: CN=S-1-5-11

Notice that everything matches except the xidNumber.

So to get everything to match, you need to copy one idmap.ldb to the 
other machine and then keep them in sync somehow.

I must also point out that (as far as I am aware) it was Steve that 
first noticed this problem.

Of course, if the devs could come up with a way (that was satisfactory 
to everybody) to give the windows well know RID's a fixed ID number, 
idmap.ldb would not be required, there was some talk about this, but it 
did not get anywhere.

Rowland
>
> I actually did use rsync for a while and then realized I was messing 
> up after several machines stopped being able to access the sysvol 
> share on the second DC. When I ran "samba-tool ntacl sysvolcheck" it 
> would crash. I ran a reset and all was good, until the next rsync. I 
> finally figured it out and removed rsync and the rsync cron job.
>
> So tell me, why are you using rsync and unison? I am also trying to 
> figure out how your script figures out which way to use rsync 
> (DC1->DC2 or DC2->DC1) based on what changes are on each DC. In other 
> words, would your script work if a directory and file was created on 
> DC1 AND a directory was removed on DC2? Would the new stuff get copied 
> to DC2 and would the directory be removed on DC1? Forgive me, but I am 
> not a bash scripting god. I know the basics and can get my work done, 
> but I am not understanding how your script does two-way stuff via the 
> rsync portion.
>
> On 08/22/2014 02:21 AM, L.P.H. van Belle wrote:
>> ah you didnt see my script...
>>
>> https://secure.bazuin.nl/scripts/3-setup-sysvol-bidirectional.sh
>>
>> You way is missing the ACL.. you need rsync with unison.
>> its all in my script.
>>
>>
>> Greetz,
>>
>> Louis
>>
>>
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: ryana at reachtechfp.com
>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>>> Verzonden: vrijdag 22 augustus 2014 0:14
>>> Aan: samba at lists.samba.org
>>> Onderwerp: [Samba] Proper sysvol replication solution...
>>>
>>> I see the Samba guide suggests using rsync to keep sysvols in
>>> sync, but
>>> this poses a problem with ID's and it is only one-way. I have been
>>> hesitant to suggest anything because of the flak I have been getting,
>>> but I do believe I have a much better solution that transfers
>>> files via
>>> SSH, is bi-directional (no more only editing group policy on one
>>> server), and does NOT set UID/GID information. In other words, it is
>>> PERFECT for sysvol replication, and has been working on several of my
>>> domains for around a year and a half without a hitch. The
>>> solution I am
>>> proposing is to use unison, which also works on Windows and (I
>>> think) Mac.
>>>
>>> The way I have unison working on my systems is to install
>>> unison on all
>>> DC's, which is required. You also need an SSH server and client on all
>>> DC's, but I assume most of you do anyway. Once they're
>>> installed, it is
>>> as simple as the command below. This will synchronizes changes
>>> BOTH WAYS
>>> without touching your UID/GID setup. If you're paranoid, you could
>>> always do a sysvolreset when done though.
>>>
>>> unison -batch "/path/to/sysvol" "ssh://dc02.domain.lan//path/to/sysvol"
>>>
>>> If you do this at a command-line, it will prompt you for your password
>>> on the remote machine. This would prevent a cron job, but I overcame
>>> that as well. You can create an SSH key that does not require
>>> a password
>>> for the systems to use. This means you can now create a cron job to
>>> handle the replication every fifteen minutes or so. You could also use
>>> something like "incrond" to monitor for changes in the sysvol
>>> and launch
>>> unison as well, but I don't personally modify the sysvol often, so
>>> replication every fifteen minutes works for me.
>>>
>>> To create an SSH key to allow password-less replication via unison, do
>>> the following.
>>>
>>> ssh-keygen -t dsa
>>>
>>> When it prompts for a file to save the key in, it should be your home
>>> directory in a ".ssh" directory. I run as root, so this is
>>> "/root/.ssh/id_dsa" for me. It will then prompt for a password. Ignore
>>> this and just press enter. It will ask you to verify the
>>> password. Press
>>> enter again. If you enter a password here, it cannot run
>>> without user input!
>>>
>>> Next, you need to copy the key to your other domain
>>> controllers. You can
>>> do so as follows. Note that my example is run as root. Substitute your
>>> user's path if needed.
>>>
>>> ssh-copy-id -i /root/.ssh/id_dsa.pub root at dc02.domain.lan
>>>
>>> Once that is done, login to the domain controller you copied
>>> the key to
>>> (in the example, dc02) and check "/root/.ssh/authorized_keys"
>>> to verify
>>> that the key was added and nothing unexpected is there. You
>>> can do this
>>> with "cat /root/.ssh/authorized_keys". You should see a key on
>>> a single
>>> line followed by the hostname of your primary domain controller. If it
>>> is there, they may now connect via SSH without a password!
>>>
>>> You may now copy the key to any other domain controllers in
>>> your domain
>>> so they trust the primary DC as well. After that, all that is left is
>>> the synchronization. I urge you to run the first synchronization
>>> manually, like below.
>>>
>>> unison "/path/to/sysvol" "ssh://dc02.domain.lan//path/to/sysvol"
>>>
>>> Make sure everything looks good, synchronize it, then repeat
>>> for each DC
>>> on your domain. Once done, you can create cron jobs to sync
>>> each server,
>>> or use a script like mine below. This script is on my primary DC. I
>>> actually only have two DC's, but I added more as an example here.
>>>
>>> #!/bin/bash
>>> SERVERLIST="dc02.domain.lan dc03.domain.lan dc04.domain.lan"
>>> SVPATH="/path/to/sysvol"
>>>
>>> # Synchronize all of the domain controllers
>>> for sLoop in ${SERVERLIST}
>>> do
>>>    unison -batch "${SVPATH}" "ssh://${sLoop}/${SVPATH}"
>>> done
>>>
>>> exit 0
>>>
>>> Now set that script to run in a cron job and you're golden. You could
>>> also setup "incrond" on all of your DC's and have it call
>>> unison to sync
>>> the other DC's whenever a write happens in your sysvol, but I do not
>>> need such a thing and have not personally tried it, though I have a
>>> fellow IT lead who has and likes it. My crontab job entry is
>>> listed below.
>>>
>>> 15 * * * * /root/sysvolsync.sh &> /dev/null
>>>
>>> I hope this helps somebody and if you see something wrong,
>>> feel free to
>>> let me know.
>>> -- 
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>
>>>
>