Why only Domain Users and Domain Admins? I can't follow. But a good idea you've had. So a script can possibly be run on every DC the same. I will check and verify. What about built-in objects like system? These are not available in ADUC if my memory doesn't fail now. Will there be a problem when other built-in objects get a rfc gid/uid. E.g. for now wbinfo resolves uid 0 for administrator. Am 12. Dezember 2014 22:19:45 MEZ, schrieb Rowland Penny <rowlandpenny at googlemail.com>:>On 12/12/14 20:31, Tim wrote: >> My idea is similar. Today I didn't had the time to go on. >> >> But this my concept and it works with a short script (example for >groups): >> >> DC1 (schema master) >> for loop on wbinfo -g will >> check if rfc2307 info is null for these groups in AD (ldbsearch) >> when rfc2307 gid is equal to wbinfo --group-info | cut -d: -f3 then >exit >> else update rfc2307 info by importing created ldif file (ldbmodify) > >You only really need to give Domain Users & Domain Admins a gidNumber, >also you just need to check if the group has a gidNumber and if it >doesn't, update the group by adding the next available gidNumber. The >same goes for a user. > >I also told you where AD normally stores the next uidNumber & >gidNumber. > >Rowland > > >> >> To get this faster an extra file with set rfc2307 gids will be needed >and needs to be updated. >> >> For failover reasons idmap.ldp should be synced to secondary DCs or >if possible its max gid number should be updated on secondary DCs. >> >> Regards >> Tim >> >> >> >> Am 12. Dezember 2014 10:19:07 MEZ, schrieb steve ><steve at steve-ss.com>: >>> On 12/12/14 07:10, Tim wrote: >>>> >>>> Am 11. Dezember 2014 23:25:58 MEZ, schrieb steve >>> <steve at steve-ss.com>: >>>>> On 11/12/14 23:15, Tim wrote: >>>>>> Thanks Steve, >>>>>> >>>>>> I will have a look at it. I think it's important to sync the >>>>> idmap.ldb >>>>>> limits >>>>> It isn't important. The limits are the same on all DCs, even if >you >>>>> have >>>>> not copied the idmap database anywhere else. All you need to do is >>>>> write >>>>> the uidNumber and the gidNumber to the DN of your new users and >>> groups. >>>>> There are many ways of keeping track of >>>>> what-the-next-uidNumber-should-be, which I think is your real >>> problem. >>>> >>>> Can you give an example? Sounds interesting and would really help. >>>> >>> On way. >>> Turn on enumeration. >>> getent passwd and redirect to a file. read each line, cut the 3rd >field >>> >>> (':' is the delimiter) and append to a second file. Find the biggest >>> number and then add 1. >>> There are as many ways as people using rfc2307... >>> HTH >>> Steve > >-- >To unsubscribe from this list go to the following URL and read the >instructions: https://lists.samba.org/mailman/options/samba
On 12/12/14 22:08, Tim wrote:> Why only Domain Users and Domain Admins? I can't follow.Because they are the only two windows groups that you are likely to need on a Unix machine.> But a good idea you've had. So a script can possibly be run on every > DC the same. I will check and verify.Don't bother, been there, doing that.> > What about built-in objects like system? These are not available in > ADUC if my memory doesn't fail now.That is what idmap.ldb is for!!!> Will there be a problem when other built-in objects get a rfc gid/uid. > E.g. for now wbinfo resolves uid 0 for administrator. >Other built-in objects do not need a rfc gid/uid and Administrator gets mapped to root by, you guessed it, idmap.ldb Rowland> Am 12. Dezember 2014 22:19:45 MEZ, schrieb Rowland Penny > <rowlandpenny at googlemail.com>: > > On 12/12/14 20:31, Tim wrote: > > My idea is similar. Today I didn't had the time to go on. But > this my concept and it works with a short script (example for > groups): DC1 (schema master) for loop on wbinfo -g will check > if rfc2307 info is null for these groups in AD (ldbsearch) > when rfc2307 gid is equal to wbinfo --group-info | cut -d: -f3 > then exit else update rfc2307 info by importing created ldif > file (ldbmodify) > > > You only really need to give Domain Users & Domain Admins a gidNumber, > also you just need to check if the group has a gidNumber and if it > doesn't, update the group by adding the next available gidNumber. The > same goes for a user. > > I also told you where AD normally stores the next uidNumber & gidNumber. > > Rowland > > > To get this faster an extra file with set rfc2307 gids will be > needed and needs to be updated. For failover reasons idmap.ldp > should be synced to secondary DCs or if possible its max gid > number should be updated on secondary DCs. Regards Tim Am 12. > Dezember 2014 10:19:07 MEZ, schrieb steve <steve at steve-ss.com>: > > On 12/12/14 07:10, Tim wrote: > > Am 11. Dezember 2014 23:25:58 MEZ, schrieb steve > > <steve at steve-ss.com>: > > On 11/12/14 23:15, Tim wrote: > > Thanks Steve, I will have a look at it. I > think it's important to sync the > > idmap.ldb > > limits > > It isn't important. The limits are the same on all > DCs, even if you have not copied the idmap > database anywhere else. All you need to do is > write the uidNumber and the gidNumber to the DN of > your new users and > > groups. > > There are many ways of keeping track of > what-the-next-uidNumber-should-be, which I think > is your real > > problem. > > Can you give an example? Sounds interesting and would > really help. > > On way. Turn on enumeration. getent passwd and redirect to > a file. read each line, cut the 3rd field (':' is the > delimiter) and append to a second file. Find the biggest > number and then add 1. There are as many ways as people > using rfc2307... HTH Steve >
On 13/12/14 18:24, rintimtim at gmx.net wrote:> Here you are my working script for setting gidNumbers. You're welcome > to verify. > WARNING: I'm not responsible for any damage. Use and test at your own > risk. Variables must be set correctly! > # Groups > maxGid=40000 > pathTmpFiles="/root" > domain="example" > domainDNappendix="DC=example,DC=com" > groupsBaseDN="OU=Subgroups,OU=Groups,$domainDNappendix" > samldb="/var/lib/samba/private/sam.ldb" > wbinfo -g > $pathTmpFiles/ad-groups > while read gid1 > do > echo "$gid1:"$(wbinfo --group-info "$gid1" | cut -d: -f3) > done < $pathTmpFiles/ad-groups > $pathTmpFiles/ad-groups-gid > while read gid2 > do > echo $gid2 | awk -F : -v maxGid=$maxGid '$2>maxGid'" > done < $pathTmpFiles/ad-groups-gid > $pathTmpFiles/ad-groups-gid-change > if [ -z "$(cat $pathTmpFiles/ad-groups-gid-change)" ] > then > #Clean-Up > rm $pathTmpFiles/ad-groups > rm $pathTmpFiles/ad-groups-gid > rm $pathTmpFiles/ad-groups-gid-change > exit 0 > fi > setGid=$(ldbsearch -H $samldb -b > CN=$domain,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$domainDNappendix > | grep -i msSFU30MaxGidNumber | cut -d: -f2) > while read gid3 > do > let setGid=setGid+1 > group=$(echo $gid3 | cut -d: -f1) > ldbsearch -H $samldb -b $groupsBaseDN CN=$(echo $gid3 | cut > -d: -f1) | grep -i dn: > $pathTmpFiles/AD-gid-$group.ldif > echo changetype: modify >> $pathTmpFiles/AD-gid-$group.ldif > echo replace: gidNumber >> $pathTmpFiles/AD-gid-$group.ldif > echo gidNumber: $setGid >> $pathTmpFiles/AD-gid-$group.ldif > ldbmodify -H $samldb $pathTmpFiles/AD-gid-$group.ldif > rm $pathTmpFiles/AD-gid-$group.ldif > done < $pathTmpFiles/ad-groups-gid-change > # Increase MsSFU30MaxGidNumber > echo "dn: > CN=$domain,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$domainDNappendix" > > $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > echo changetype: modify >> $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > echo replace: msSFU30MaxGidNumber >> > $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > echo msSFU30MaxGidNumber: $setGid >> > $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > ldbmodify -H $samldb $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > #Clean-Up > rm $pathTmpFiles/ad-groups > rm $pathTmpFiles/ad-groups-gid > rm $pathTmpFiles/ad-groups-gid-change > rm $pathTmpFiles/setMsSFU30MaxGidNumber.ldif > Cron could do this job every minute. A Script for uidNumbers would be > similar. > Regards > Tim > *Gesendet:* Samstag, 13. Dezember 2014 um 10:54 Uhr > *Von:* "Rowland Penny" <rowlandpenny at googlemail.com> > *An:* Tim <rintimtim at gmx.net>, samba at lists.samba.org > *Betreff:* Re: [Samba] Samba 4 two DCs no matching UID/GID > On 12/12/14 22:08, Tim wrote: > > Why only Domain Users and Domain Admins? I can't follow. > > > Because they are the only two windows groups that you are likely to > need on a Unix machine. > > But a good idea you've had. So a script can possibly be run on > every DC the same. I will check and verify. > > > Don't bother, been there, doing that. > > > What about built-in objects like system? These are not available > in ADUC if my memory doesn't fail now. > > > That is what idmap.ldb is for!!! > > Will there be a problem when other built-in objects get a rfc > gid/uid. E.g. for now wbinfo resolves uid 0 for administrator. > > > Other built-in objects do not need a rfc gid/uid and Administrator > gets mapped to root by, you guessed it, idmap.ldb > > Rowland > > Am 12. Dezember 2014 22:19:45 MEZ, schrieb Rowland Penny > <rowlandpenny at googlemail.com>: > > On 12/12/14 20:31, Tim wrote: > > My idea is similar. Today I didn't had the time to go on. > But this my concept and it works with a short script > (example for groups): DC1 (schema master) for loop on > wbinfo -g will check if rfc2307 info is null for these > groups in AD (ldbsearch) when rfc2307 gid is equal to > wbinfo --group-info | cut -d: -f3 then exit else update > rfc2307 info by importing created ldif file (ldbmodify) > > You only really need to give Domain Users & Domain Admins a > gidNumber, also you just need to check if the group has a > gidNumber and if it doesn't, update the group by adding the > next available gidNumber. The same goes for a user. I also > told you where AD normally stores the next uidNumber & > gidNumber. Rowland > > To get this faster an extra file with set rfc2307 gids > will be needed and needs to be updated. For failover > reasons idmap.ldp should be synced to secondary DCs or if > possible its max gid number should be updated on secondary > DCs. Regards Tim Am 12. Dezember 2014 10:19:07 MEZ, > schrieb steve <steve at steve-ss.com>: > > On 12/12/14 07:10, Tim wrote: > > Am 11. Dezember 2014 23:25:58 MEZ, schrieb steve > > <steve at steve-ss.com>: > > On 11/12/14 23:15, Tim wrote: > > Thanks Steve, I will have a look at it. I > think it's important to sync the > > idmap.ldb > > limits > > It isn't important. The limits are the same on > all DCs, even if you have not copied the idmap > database anywhere else. All you need to do is > write the uidNumber and the gidNumber to the > DN of your new users and > > groups. > > There are many ways of keeping track of > what-the-next-uidNumber-should-be, which I > think is your real > > problem. > > Can you give an example? Sounds interesting and > would really help. > > On way. Turn on enumeration. getent passwd and > redirect to a file. read each line, cut the 3rd field > (':' is the delimiter) and append to a second file. > Find the biggest number and then add 1. There are as > many ways as people using rfc2307... HTH Steve >OK, you could do that, but why?? Why don't you just set msSFU30MaxUidNumber & msSFU30MaxGidNumber to your start number, then create users & groups in ADUC and then go to the UNIX_Attributes tab and add the number there. that way you don't have to use cron. By the way, the contents of 'msSFU30MaxGidNumber' **is** the next number, you shouldn't add one to it before you use it, you should add one to it before you replace it. Rowland
The reason why is that simple: the other admin only knows the windows world and that's why it's gonna be risky regarding file services when he creates new users or groups and forgets about the Unix tab. My personal hope is that samba will one day set rfc ids automatically so that these windows guys won't have to care. E.g. it could be an option when provisioning a new domain. It would make decisions easier to migrate from M$ AD. Just my 2 cents... Regarding msSFUMaxGidNumber: The script first reads it, counts +1 and then writes this back after setting it. So I think it isn't that wrong. Am 13. Dezember 2014 20:43:34 MEZ, schrieb Rowland Penny <rowlandpenny at googlemail.com>:>On 13/12/14 18:24, rintimtim at gmx.net wrote: >> Here you are my working script for setting gidNumbers. You're welcome > >> to verify. >> WARNING: I'm not responsible for any damage. Use and test at your own > >> risk. Variables must be set correctly! >> # Groups >> maxGid=40000 >> pathTmpFiles="/root" >> domain="example" >> domainDNappendix="DC=example,DC=com" >> groupsBaseDN="OU=Subgroups,OU=Groups,$domainDNappendix" >> samldb="/var/lib/samba/private/sam.ldb" >> wbinfo -g > $pathTmpFiles/ad-groups >> while read gid1 >> do >> echo "$gid1:"$(wbinfo --group-info "$gid1" | cut -d: -f3) >> done < $pathTmpFiles/ad-groups > $pathTmpFiles/ad-groups-gid >> while read gid2 >> do >> echo $gid2 | awk -F : -v maxGid=$maxGid '$2>maxGid'" >> done < $pathTmpFiles/ad-groups-gid > >$pathTmpFiles/ad-groups-gid-change >> if [ -z "$(cat $pathTmpFiles/ad-groups-gid-change)" ] >> then >> #Clean-Up >> rm $pathTmpFiles/ad-groups >> rm $pathTmpFiles/ad-groups-gid >> rm $pathTmpFiles/ad-groups-gid-change >> exit 0 >> fi >> setGid=$(ldbsearch -H $samldb -b >> >CN=$domain,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$domainDNappendix > >> | grep -i msSFU30MaxGidNumber | cut -d: -f2) >> while read gid3 >> do >> let setGid=setGid+1 >> group=$(echo $gid3 | cut -d: -f1) >> ldbsearch -H $samldb -b $groupsBaseDN CN=$(echo $gid3 | cut >> -d: -f1) | grep -i dn: > $pathTmpFiles/AD-gid-$group.ldif >> echo changetype: modify >> $pathTmpFiles/AD-gid-$group.ldif >> echo replace: gidNumber >> $pathTmpFiles/AD-gid-$group.ldif >> echo gidNumber: $setGid >> $pathTmpFiles/AD-gid-$group.ldif >> ldbmodify -H $samldb $pathTmpFiles/AD-gid-$group.ldif >> rm $pathTmpFiles/AD-gid-$group.ldif >> done < $pathTmpFiles/ad-groups-gid-change >> # Increase MsSFU30MaxGidNumber >> echo "dn: >> >CN=$domain,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,$domainDNappendix" > >> > $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> echo changetype: modify >> $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> echo replace: msSFU30MaxGidNumber >> >> $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> echo msSFU30MaxGidNumber: $setGid >> >> $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> ldbmodify -H $samldb $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> #Clean-Up >> rm $pathTmpFiles/ad-groups >> rm $pathTmpFiles/ad-groups-gid >> rm $pathTmpFiles/ad-groups-gid-change >> rm $pathTmpFiles/setMsSFU30MaxGidNumber.ldif >> Cron could do this job every minute. A Script for uidNumbers would be > >> similar. >> Regards >> Tim >> *Gesendet:* Samstag, 13. Dezember 2014 um 10:54 Uhr >> *Von:* "Rowland Penny" <rowlandpenny at googlemail.com> >> *An:* Tim <rintimtim at gmx.net>, samba at lists.samba.org >> *Betreff:* Re: [Samba] Samba 4 two DCs no matching UID/GID >> On 12/12/14 22:08, Tim wrote: >> >> Why only Domain Users and Domain Admins? I can't follow. >> >> >> Because they are the only two windows groups that you are likely to >> need on a Unix machine. >> >> But a good idea you've had. So a script can possibly be run on >> every DC the same. I will check and verify. >> >> >> Don't bother, been there, doing that. >> >> >> What about built-in objects like system? These are not available >> in ADUC if my memory doesn't fail now. >> >> >> That is what idmap.ldb is for!!! >> >> Will there be a problem when other built-in objects get a rfc >> gid/uid. E.g. for now wbinfo resolves uid 0 for administrator. >> >> >> Other built-in objects do not need a rfc gid/uid and Administrator >> gets mapped to root by, you guessed it, idmap.ldb >> >> Rowland >> >> Am 12. Dezember 2014 22:19:45 MEZ, schrieb Rowland Penny >> <rowlandpenny at googlemail.com>: >> >> On 12/12/14 20:31, Tim wrote: >> >> My idea is similar. Today I didn't had the time to go on. >> But this my concept and it works with a short script >> (example for groups): DC1 (schema master) for loop on >> wbinfo -g will check if rfc2307 info is null for these >> groups in AD (ldbsearch) when rfc2307 gid is equal to >> wbinfo --group-info | cut -d: -f3 then exit else update >> rfc2307 info by importing created ldif file (ldbmodify) >> >> You only really need to give Domain Users & Domain Admins a >> gidNumber, also you just need to check if the group has a >> gidNumber and if it doesn't, update the group by adding the >> next available gidNumber. The same goes for a user. I also >> told you where AD normally stores the next uidNumber & >> gidNumber. Rowland >> >> To get this faster an extra file with set rfc2307 gids >> will be needed and needs to be updated. For failover >> reasons idmap.ldp should be synced to secondary DCs or if >> possible its max gid number should be updated on >secondary >> DCs. Regards Tim Am 12. Dezember 2014 10:19:07 MEZ, >> schrieb steve <steve at steve-ss.com>: >> >> On 12/12/14 07:10, Tim wrote: >> >> Am 11. Dezember 2014 23:25:58 MEZ, schrieb steve >> >> <steve at steve-ss.com>: >> >> On 11/12/14 23:15, Tim wrote: >> >> Thanks Steve, I will have a look at it. I >> think it's important to sync the >> >> idmap.ldb >> >> limits >> >> It isn't important. The limits are the same >on >> all DCs, even if you have not copied the >idmap >> database anywhere else. All you need to do is >> write the uidNumber and the gidNumber to the >> DN of your new users and >> >> groups. >> >> There are many ways of keeping track of >> what-the-next-uidNumber-should-be, which I >> think is your real >> >> problem. >> >> Can you give an example? Sounds interesting and >> would really help. >> >> On way. Turn on enumeration. getent passwd and >> redirect to a file. read each line, cut the 3rd field >> (':' is the delimiter) and append to a second file. >> Find the biggest number and then add 1. There are as >> many ways as people using rfc2307... HTH Steve >> > >OK, you could do that, but why?? > >Why don't you just set msSFU30MaxUidNumber & msSFU30MaxGidNumber to >your >start number, then create users & groups in ADUC and then go to the >UNIX_Attributes tab and add the number there. that way you don't have >to >use cron. > >By the way, the contents of 'msSFU30MaxGidNumber' **is** the next >number, you shouldn't add one to it before you use it, you should add >one to it before you replace it. > >Rowland