<div dir="ltr">Hi Ivan and Radovan,<br><br>yes! Conditional synchronization was the missing piece and now I have a working solution. Thanks a lot!<br><br>To sum it up - have an active directory forrest with multiple domains connected to midpoint 3.5 for read and update operations.<br><br>What worked for me in the end was basically to follow the documentation in <a href="https://wiki.evolveum.com/display/midPoint/Active+Directory+Multi-Domain">https://wiki.evolveum.com/display/midPoint/Active+Directory+Multi-Domain</a> with an extra detail<br>1) in connectorConfiguration specify the root domain as 'host' and every subdomain as one 'servers' element with the corresponding baseContexts<br>2) set referralStrategy to ignore and specify the globalCatalogServers and set globalCatalogStrategy to resolve (don't know if the global catalog is necessary in the end or not)<br>3) define an objectType for every ad domain with a unique intent plus a default one. Every objectType has the same baseContext/filter as the corresponding 'servers' element in connectorConfiguration<br>4) define an objectSynchronization for every domain with the corresponding intent plus a default one. Every synchronization has again the same dn/baseContext test as the domain servers/baseContext. Something like "basic.getSecondaryIdentifierValue(shadow) ==~ ~/(?i)^.*dc=subdomain,dc=root,dc=com$/" ( as found in midpoint/samples ).<br><br>I didn't find a way to work with the resource as a whole so far, each task has an intent and affects just a single subdomain. To connect all 17 subdomains i have i will probably try a xslt preprocessor to generate the resource xml and the tasks.<br><br>> N.B.: The split of configuration to schemaHandling and synchronization <div>> was one the historical mistakes in the midPoint configuration design.</div><div>> The plan is to fix this and similar issues in midPoint 4 ... whenever that </div><div>> may be.<br><br>Great! It is a bit odd to specify/control something so tightly related on several 'independent' places. Gave me so much freedom i got lost.<br><br>> > In the case of AD it might be theoretically possible to<br>> > search through global catalog. But that is not very practical as global<br>> > catalog does not have all the data. We would need to fetch each and<br>> > every account from its authoritative location anyway. This is<br>> > inefficient and therefore it is not implemented.<br><br>I didn't know what AD is a week ago but ... learning a tiny bit so far i understand this is the intended global catalog design. First search this gc ( like in an index, only some attributes are indexed ) and second work with the real 'entity' on the domain node. So a single global import of everything in the gc under one baseContext in this two step automated process would make sense, at least in my case.<br><br>Thanks again for the great help!</div><div><br></div><div>arnost</div><div><br>2017-02-23 11:58 GMT+01:00 Radovan Semancik <<a href="mailto:radovan.semancik@evolveum.com">radovan.semancik@evolveum.com</a>>:<br>><br>> Hi,<br>><br>> On 02/22/2017 04:34 PM, Arnošt Starosta - AMI Praha a.s. wrote:<br>>><br>>> But when that subdomain data/shadows are processed further in the subdomain intent task the objectSynchronization configurations for different intents seem to collide and no accounts for subdomains are created. The subdomain shadow objects are reported on the progress tab as "(ACCOUNT - default - user)" instead of "(ACCOUNT - subdomain - user)".<br>>><br>>> It seems only the first objectSynchronization element is considered and renders the object "not applicable".<br>><br>><br>> Please make sure that you have set kind/intent also in the synchronization section. And that you have correct conditions in the synchronization section. The conditions may be needed to sort the imported accounts to the "intents". As the multi-domain is seen as one resource, midPoint has no practical way how to sort the accounts to intents automatically. At least not now.<br>><br>> It is described here: <a href="https://wiki.evolveum.com/display/midPoint/Synchronization+Configuration">https://wiki.evolveum.com/display/midPoint/Synchronization+Configuration</a><br>><br>> N.B.: The split of configuration to schemaHandling and synchronization was one the historical mistakes in the midPoint configuration design. It does not make much sense now. I have already regretted that design choice several times. But it is there almost from the begining, long before we had intents. This is the cost of evolution. And now we strongly prefer compatibility and upgradeability, so there is no easy way to fix that. The plan is to fix this and similar issues in midPoint 4 ... whenever that may be.<br>><br>>> Is that a bug or is my 'objectSynchronization per intent' wrong?<br>><br>><br>> I would guess that it is configuration issue. You probably need to add the conditions to synchronization sections. It is unlikely that this is a bug as this is a tested setup. But of course, I cannot completely rule out the possibility that there is a bug.<br>><br>>> Btw trying to 'import' the accounts from subdomains doesn't even try to fetch the data. I always have to 'reconcile'. Don't know if that indicates something or not.<br>><br>><br>> This one is quite strange. Import and reconcile are almost the same in this aspect. Both are based on account search. But again, I would guess that this suggest either wrong configuration or a very strange bug.<br>><br>><br>> --<br>> Radovan Semancik<br>> Software Architect<br>> <a href="http://evolveum.com">evolveum.com</a><br>><br><br><br><br>--<br><br>Arnošt Starosta<br>solution architect<br><br>gsm: [+420] 603 794 932<br>e-mail: <a href="mailto:arnost.starosta@ami.cz">arnost.starosta@ami.cz</a><br><br>     <br><br>AMI Praha a.s.<br>Pláničkova 11<br>162 00 Praha 6<br>tel.: [+420] 274 783 239<br>web: <a href="http://www.ami.cz">www.ami.cz</a><br><br>     <br><br><br><br>Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.<br>jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.<br><br><br><br><br><br><br><br><br><br><br><div><div><div class="gmail_extra"><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><table style="font-family:verdana,arial,helvetica,sans-serif;border-collapse:collapse;padding:0px;margin:0px;border-width:0px;border-style:solid;width:482px"><tbody><tr style="padding:0px;margin:0px;border:0px solid gray"><td style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px;width:160px;vertical-align:bottom;padding:0px;border:0px solid gray"><br></td><td style="color:rgb(0,0,0);font-family:verdana,arial,helvetica,sans-serif;font-size:10px;border-width:0px 1px 0px 0px;border-style:solid;border-color:gray rgb(204,204,204) gray gray;padding:0px"><br></td><td style="color:rgb(0,0,0);font-family:verdana,arial,helvetica,sans-serif;font-size:10px;padding:0px;border:0px solid gray"><br></td><td style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px;vertical-align:bottom;padding:0px;width:123px;border:0px solid gray"><br></td><td style="color:rgb(0,0,0);font-family:verdana,arial,helvetica,sans-serif;font-size:10px;border-width:0px 1px 0px 0px;border-style:solid;border-color:gray rgb(204,204,204) gray gray;padding:0px"><br></td><td style="color:rgb(0,0,0);font-family:verdana,arial,helvetica,sans-serif;font-size:10px;padding:0px;border:0px solid gray"><br></td><td style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:11px;margin:8px;width:116px;border:0px solid gray"><br></td></tr><tr style="padding:0px;margin:0px;border:0px solid gray"><td colspan="7" style="color:rgb(0,0,0);font-family:verdana,arial,helvetica,sans-serif;font-size:10px;padding:0px;width:480px;border:0px solid gray"><br></td></tr><tr style="padding:0px;margin:0px;border:0px solid gray"><td colspan="7" style="color:rgb(128,128,128);font-family:arial,sans-serif;font-size:11px;padding:0px;border:0px solid gray"><br></td></tr></tbody></table></div></div></div></div>
</div></div></div></div></div>