[Samba] Proper sysvol replication solution...

[Achim Gottinger]

Am 23.08.2014 00:40, schrieb steve:
> On Fri, 2014-08-22 at 23:48 +0200, Achim Gottinger wrote:
>> Am 22.08.2014 23:26, schrieb Rowland Penny:
>>> On 22/08/14 22:12, Achim Gottinger wrote:
>>>> Am 22.08.2014 22:58, schrieb Rowland Penny:
>>>>> On 22/08/14 21:46, Achim Gottinger wrote:
>>>>>> Am 22.08.2014 22:28, schrieb Rowland Penny:
>>>>>>> On 22/08/14 20:57, Achim Gottinger wrote:
>>>>>>>> Am 22.08.2014 21:16, schrieb Rowland Penny:
>>>>>>>>> On 22/08/14 19:51, Achim Gottinger wrote:
>>>>>>>>>> Am 22.08.2014 20:31, schrieb Rowland Penny:
>>>>>>>>>>> On 22/08/14 18:40, Achim Gottinger wrote:
>>>>>>>>>>>> Am 22.08.2014 17:09, schrieb Rowland Penny:
>>>>>>>>>>>>> On 22/08/14 16:03, L.P.H. van Belle wrote:
>>>>>>>>>>>>>> when i look on my sysvol and subfolders
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> getfacl /home/samba/sysvol/internal.domain.tld/
>>>>>>>>>>>>>> the on both servers is the same.
>>>>>>>>>>>>>> and when i look from within windows both shares are exacly
>>>>>>>>>>>>>> the same with rights.
>>>>>>>>>>>>>> share files and folders.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> maybe im lucky ;-)
>>>>>>>>>>>>> Lucky ?? that's nearly impossible, I bet you win everything
>>>>>>>>>>>>> you enter ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> no, i dont need these mappings imo since i dont have any
>>>>>>>>>>>>>> linux/unix user to the sysvol share.
>>>>>>>>>>>>>> makes life lot easier..
>>>>>>>>>>>>> Yes but it doesn't just affect sysvol, it can affect any share.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Rowland
>>>>>>>>>>>>>> Louis
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Oorspronkelijk bericht-----
>>>>>>>>>>>>>>> Van: ryana at reachtechfp.com
>>>>>>>>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>>>>>>>>>>>>>>> Verzonden: vrijdag 22 augustus 2014 16:47
>>>>>>>>>>>>>>> Aan: samba at lists.samba.org
>>>>>>>>>>>>>>> Onderwerp: Re: [Samba] Proper sysvol replication solution...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Domain users don't enter the equation here though. We're
>>>>>>>>>>>>>>> talking the
>>>>>>>>>>>>>>> "well-known" RID's like Rowland just mentioned. In other
>>>>>>>>>>>>>>> words, if my
>>>>>>>>>>>>>>> "Authenticated Users" is XID 30001 on DC1 but it is 30009
>>>>>>>>>>>>>>> on DC2, I
>>>>>>>>>>>>>>> would not want to clone the UID/GID info from DC1 to DC2,
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> the files
>>>>>>>>>>>>>>> and directories. That where the "idmap.ldb" file comes
>>>>>>>>>>>>>>> into play.
>>>>>>>>>>>>>>> Apparently it is created with random XID's when Samba is
>>>>>>>>>>>>>>> configured and
>>>>>>>>>>>>>>> ran for the first time on each machine. Does your script
>>>>>>>>>>>>>>> copy those
>>>>>>>>>>>>>>> UID/GID numbers over? If so, I was under the impression
>>>>>>>>>>>>>>> that such a
>>>>>>>>>>>>>>> thing was bad.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am currently setting up two virtual machines
>>>>>>>>>>>>>>> (VirtualBox) to
>>>>>>>>>>>>>>> play with
>>>>>>>>>>>>>>> your script. I want to understand how it works and this
>>>>>>>>>>>>>>> way I am not
>>>>>>>>>>>>>>> worried about destroying a client's domain while I am
>>>>>>>>>>>>>>> toying around.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 08/22/2014 10:34 AM, L.P.H. van Belle wrote:
>>>>>>>>>>>>>>>>> -----Oorspronkelijk bericht-----
>>>>>>>>>>>>>>>>> Van: ryana at reachtechfp.com
>>>>>>>>>>>>>>>>> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>>>>>>>>>>>>>>>>> Verzonden: vrijdag 22 augustus 2014 15:30
>>>>>>>>>>>>>>>>> Aan: samba at lists.samba.org
>>>>>>>>>>>>>>>>> Onderwerp: Re: [Samba] Proper sysvol replication
>>>>>>>>>>>>>>>>> solution...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, your right, it can be different if you dont keep de the
>>>>>>>>>>>>>>> default settings.
>>>>>>>>>>>>>>>> Which should be ok. I dont have any reason to change the
>>>>>>>>>>>>>>> acls on sysvol.
>>>>>>>>>>>>>>>> And i only use my ADDC as DC and not as file server so i
>>>>>>>>>>>>>>> dont have any idmap problems.
>>>>>>>>>>>>>>>> And i only use windows users to access these shares.
>>>>>>>>>>>>>>>> No linux users or what have access to these machines. only
>>>>>>>>>>>>>>> me as linux user and windows user.
>>>>>>>>>>>>>>>> and that are 2 different accounts. my linux user is only use
>>>>>>>>>>>>>>> to maintain the system.
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>> Well normal questions.. so
>>>>>>>>>>>>>>>> If a file is remove from sysvol on DC1 it removes it also
>>>>>>>>>>>>>>>> from DC2.
>>>>>>>>>>>>>>>> If at the same time a folder or file was remove from DC2
>>>>>>>>>>>>>>> then it does the same with it on DC1.
>>>>>>>>>>>>>>>> just test it.. you see.
>>>>>>>>>>>>>>>> And best tip of the day.. make a backup of your sysvol
>>>>>>>>>>>>>>> before you start,
>>>>>>>>>>>>>>>> when you rest things and you forget to remove the unison
>>>>>>>>>>>>>>> hash files you can delete you sysvol..
>>>>>>>>>>>>>>>> we need rsync to create the directory structure with
>>>>>>>>>>>>>>> extended attributes,
>>>>>>>>>>>>>>>> the (now) unison setup copies only the extened attributes
>>>>>>>>>>>>>>>> on files.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cron does the sync every 5 min for me and you can also use
>>>>>>>>>>>>>>> inotify for that.
>>>>>>>>>>>>>>>> You can search for that one on the list.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hope answere this helps you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>> To unsubscribe from this list go to the following URL
>>>>>>>>>>>>>>>>> and read the
>>>>>>>>>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>> To unsubscribe from this list go to the following URL and
>>>>>>>>>>>>>>> read the
>>>>>>>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>> Rowland do you remeber Michael Adam's patch here from april?
>>>>>>>>>>>> Seems it did not yet make it into an stable release.
>>>>>>>>>>> Yes, I vaguely remember it, but it did not go far enough (no
>>>>>>>>>>> disrespect meant Michael, I couldn't have got that far),  I
>>>>>>>>>>> 'think' it only dealt with 'BUILTIN' objects, but they are a
>>>>>>>>>>> small part of the well known RID's .
>>>>>>>>>>>
>>>>>>>>>>> Rowland
>>>>>>>>>> Good point,
>>>>>>>>>>
>>>>>>>>>> An nss_idmap module or extention to nss_winbind which resolves
>>>>>>>>>> xidNumbers to objectSID's might do the trick. It is not
>>>>>>>>>> neccesarry to translate the SID into an name to solve the
>>>>>>>>>> mapping problem.
>>>>>>>>>>
>>>>>>>>>> achim~
>>>>>>>>>>
>>>>>>>>> You mean like the reverse of what ever happens to create the
>>>>>>>>> entries in idmap.ldb ?
>>>>>>>>>
>>>>>>>>> Rowland
>>>>>>>>>
>>>>>>>> Yes,
>>>>>>>>
>>>>>>>> For your example in the other mail "getent group" would return
>>>>>>>>
>>>>>>>> S-1-5-32-544:*:3000000
>>>>>>>>
>>>>>>>> on the dc and
>>>>>>>>
>>>>>>>> S-1-5-32-544:*:2000
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> That would be good, but it would be better if was:
>>>>>>>
>>>>>>> administrators:*:3000000
>>>>>>>
>>>>>>> on the dc and
>>>>>>>
>>>>>>> administrators:*:2000
>>>>>>>
>>>>>>> Rowland
>>>>>>>
>>>>>> Odd thing is the sid to name mapping is already there
>>>>>> (librpc/idl/security.idl) for well know sid's and rid's. Makes it
>>>>>> even more strange that only BUILDIN groups had been implemented by
>>>>>> the patch.
>>>>>>
>>>>>> @steve you would force the users to reserve an predefined range of
>>>>>> numbers in their usermanagement for windows standard groups und users.
>>>>> And your problem with this is ???
>>>>>
>>>>> If people could get their heads around the fact that they do not
>>>>> need any local unix users and just have domain users instead, this
>>>>> would not really be a problem.
>>>>>
>>>>> Rowland
>>>>>
>>>> Not my problem but one. Well-know-rid's for two different domains.
>>>> The sid's differ in the domain part but would get the same fixed gid
>>>> because they have an identical well-known rid part.
>>> I cannot see that this is a problem, if it is a problem then microsoft
>>> has it as well. We are talking about the well know RID's here and
>>> apart from the few that use the domain SID, every Domain uses the same
>>> SID i.e. administrators is always  'S-1-5-32-544'
>>>
>>> Rowland
>>>
>> Well you talked about well known rid's earlier. The well known sid's are
>> the same on all domains, rid's are always prefixed with the domain sid.
>> To prove myself wrong, these do resolve well and cause no problems.
>> As for the sid's (builtin/security) the only problem on the linux side
>> is that they do not resolve at all to an gid. It is not necessary that
>> they resolve to the same gid on every machine, they just must resolve to
>> an number.
> No. They must resolve to the same number. If it's 3000000 on DC1 and you
> rsync it across to DC2 where the same group is mapped to 3000001, it is
> a mess. Your GPOs will fail.
If an group resolves to 3000000 on DC1 and to 3000001 on DC2 and you use 
-o -g during rsync. an file owned by
3000000 will be owned by 3000001 after it got rsynced from dc1 to dc2.
The gpo will continue to work.
>
>>   If an group resolves to different gid's at two systems rsync
>> will take care of the number replacement if not the gid will be the same.
> rsync cannot map builtins because they are not available via nss!
That is what i mean by they do not resolve.
>
>> achim~
>>
>>
>