Bug 5407 - AD-Connector: Standard-Container für neue Objekte angeben
AD-Connector: Standard-Container für neue Objekte angeben
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 4.1
Other Linux
: P2 enhancement with 2 votes (vote)
: ---
Assigned To: Samba maintainers
:
Depends on:
Blocks: 51773 38447
  Show dependency treegraph
 
Reported: 2006-03-09 10:35 CET by Andreas Büsching
Modified: 2020-08-05 13:59 CEST (History)
6 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 1: Nuisance – not a big deal but noticeable
User Pain: 0.011
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2011012710001863, 2012050221003477, 2013071821000855, 2015050521000558
Bug group (optional):
Max CVSS v3 score:


Attachments
apply-con_default_dn.patch (1.23 KB, patch)
2020-08-05 13:51 CEST, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Büsching univentionstaff 2006-03-09 10:35:44 CET
Bei der Synchronisation soll es möglich sein einen anderen Default-Container 
für die verschiedenen Objekttypen anzugeben. Beispielsweise für Benutzer statt 
cn=users,$ldap_base cn=addom,cn=users,$ldap_base. Evtl. sollte der Container 
auch angelegt werden, wenn er nicht existiert. 
 
Momentan gibt es im mapping schon eine Variable ucs_default_dn pro Objekttyp, 
die bisher nicht wirklich verwendet wird. Die kann man ja vielleicht dafür 
nutzen.
Comment 1 Stefan Gohmann univentionstaff 2011-01-28 09:03:34 CET
Erneut nachgefragt, Ticket #2011012710001863
Comment 2 Roman Asendorf univentionstaff 2012-05-03 13:21:26 CEST
Erneut angefragt an Ticket: #2012050221003477
Comment 3 Stefan Gohmann univentionstaff 2013-07-18 09:27:51 CEST
Erneut nachgefragt: Ticket #2013071821000855

con_default_dn und ucs_default_dn werden mit UCS 3 auch noch nicht berücksichtigt.
Comment 4 Stefan Gohmann univentionstaff 2013-08-08 06:56:04 CEST
Sofern der Connector nur von UCS nach AD synchronisiert könnte folgender Workaround helfen:

> Es sollte dazu Powershell 3.0 auf einem DC installiert sein (PS 2.0 geht 
> vermutlich auch, dann kann der tee aber kein "-append")
>
> Mit diesem Mini-Script werden alle neuen User der letzten 24 Stunden vom
> Standard-Container Users in die Ziel-OU verschoben und ein einfaches Logfile
> erzeugt:
>
> get-date >> c:\logs\move-new-users-to-ou.log
> Get-ADUser -filter {employeetype -eq "1" -and sAMAccountName -like "b*"}
-SearchBase "CN=Users,DC=domain,DC=name,DC=de" -properties whencreated |
Where-Object { $_.whencreated -gt (get-date).adddays(-1) } | Tee-Object -file
"c:\logs\move-new-users-to-ou.log" -Append |  Move-ADObject -TargetPath
"OU=Ziel-OU,DC=domain,DC=name,DC=de"
>
>
> Den Filter (Pflichtangabe!):
>
> -filter {employeetype -eq "1" -and sAMAccountName -like "b*"}
>
> setzen wir bei uns, da wir nur unsere Mitarbeiter (beginnen alle mit b* und
> haben den employeetype = 1) verschieben wollen. Im Zweifel kann man einfach:
>
> -filter {SamAccountname -like "*"}
>
> für alle Userobjekte innerhalb des Containers benutzen, man kann aber 
> natürlich auch nach beliebigen anderen LDAP Attributen filtern
> (http://blogs.msdn.com/b/adpowershell/archive/2009/04/14/active-directory-po[..].
>
> Dieses Script einfach in die Aufgabenplanung des Windows DCs eintragen und
> täglich ausführen lassen. Wichtig ist, das man hier als Programm 
> "powershell.exe" angibt und als Parameter den kompletten Pfad zur 
> PS1-Scriptdatei! Ein Kennwort muss für diesen Task nicht gespeichert werden, > da das Computerkonto des DCs alle notwendigen Schreibrechte im LDAP hat.
Comment 5 Sebastian Plattner 2014-06-26 22:19:39 CEST
Ich habe fast das gleiche Problem, nur will ich ein read Sync machen. Also AD -> UCS. Dabei sollen die zu importierenden User nicht unter cn=users sonder unter cn=users-ad abgelegt werden.

ucs_default_dn hat da überhaupt keinen Einfluss auf das Verhalten.

Wann wird das implementiert?
Comment 6 Tim Petersen univentionstaff 2015-05-07 07:47:07 CEST
Requested again at 2015050521000558:
Doesn't seem to be implemented in UCS 4 yet.
Comment 7 Stefan Gohmann univentionstaff 2019-01-03 07:21:03 CET
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Comment 8 Arvid Requate univentionstaff 2020-08-05 13:51:11 CEST
Created attachment 10448 [details]
apply-con_default_dn.patch

The attached patch would fix it.

Alternatively the "position_mapping" could be added, e.g. to the 'user' property mapping file:

position_mapping=[(',cn=users,@%@ldap/base@%@', ',OU=some,OU=other,@%@connector/s4/ldap/base@%@')],