Jump to content

daabm

Expert Member
  • Gesamte Inhalte

    5.223
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von daabm

  1. Ja, kann man. Problem sind nicht die 2 Domänen, sondern daß es nur einen Bind-User in Domäne A geben soll, nicht in Domäne B. Bei den AD-Sources kann man aber nirgends angeben, wo sich der Bind-User befindet. Ok, in seinem DN steht es drin, aber wir vermuten, daß Clearpass den DN intern mit dem Hostnamen (=Zieldomäne) ergänzt, so daß LDAP://<DomäneB>:636/<BindDNausDomäneA> daraus wird.

    Innerhalb eines Forest und mit 3269 statt 636 würde das ja funktionieren, aber wir haben halt 2 Forests - der DN von Domäne A ist in Domäne B natürlich ungültig.

  2. @Nobbyaushb Der DC möchte da DC sein. Ist hier auch so... Hatte keine Lust, die Windows-Domäne in eine SAMBA-Domäne zu migrieren, und die Synos können in einer Windows-Domäne kein DC werden. Also laufen die Windows-DC jetzt als VM auf den Synos, die in diese Domäne gejoint sind :-)

     

    Muß man ein wenig tricksen bei AD-integriertem DNS, wenn Synology Updates für QEmu ausliefert - da waren mal beide DC nicht erreichbar, und die Synos müssen deshalb auch noch secondary DNS sein und sich selbst als DNS verwenden. Geht aber problemlos.

     

    Und selbstverständlich gibt es auch auf einem DC lokale Richtlinien - siehe secpol.msc. (Fast) alles, was nicht aus einer GPO kommt, ist lokal. Ausnahme nur PW-Policies, die aus dem Domain Head in die DDP zurückwandern.

  3. Hallo zusammen. Hat eigentlich nichts mit Windows direkt zu tun, aber hier paßt es am besten rein...

     

    Ein Kunde setzt Aruba Clearpass als VPN-Lösung ein. User sind in Domäne A, Computer in Domäne B. Technischer Bind-User für Aruba ist auch in Domäne A. Die Domänen sind NICHT im gleichen Forest, aber es gibt einen Bidi-Trust. Die Clearpass-Appliance ist NICHT Mitglied einer dieser Domänen.

     

    Wie muß Clearpass konfiguriert werden, damit der Bind-User aus Domäne A in Domäne B authentifiziert werden kann?

    (Authentifizierung in Domäne A funktioniert problemlos.)

     

    Die Doku (https://www.arubanetworks.com/techdocs/ClearPass/6.7/Aruba_DeployGd_HTML/Default.htm#Active Directory/AD_auth_source_adding.htm%3FTocPath%3DPreparing%20ClearPass%20for%20Active%20Directory%20Authentication|_____2) hab ich gelesen, aber da finde ich keine Erhellung. Und der Multi-Domain Support von Clearpass scheint sich auf einen Forest zu beschränken, in dem dann nicht AD (389/636) gefragt wird, sondern GC (3268/3269).

     

    Bin für jeden Tip dankbar - der Kunde auch :-)

     

    Gruß Martin

  4. Wir kämfpen seit 2 Jahren gegen NTLM.... Man kommt sich vor wie der junge Don Qujchotte...

    Und ich hab viel gelernt über Realms, Disjoint Namespaces und lauter so Zeug, was in einem nativen reinen Windows-AD-Umfeld einfach "out of the box" funktioniert. Aber natürlich stehen unsere Computer in DNS-Zonen, die keine Domain dahinter haben, registrieren aber die AD-Domains als SPN - und so geht das weiter. Drittanbieter scheitern gern komplett, weil sie mit Uni-(PAM-) Trusts nicht klarkommen und von "AuthUsers read all everywhere" ausgehen. Und natürlich keine Möglichkeit vorsehen, Realms zu definieren.

     

    Da läuft noch ganz viel Wasser irgendwelche Bäche runter.

    • Like 1
    • Danke 1
  5. In der Tat, wir sind gespannt. Sogar ich, obwohl ich mit XCH/EXO kaum zu tun habe :-) Dafür kenne ich mich mit Schemas gut aus.

    Den Trainer würde ich gern mal kennen lernen.

    Und wenn die Lösung ist, das LDIF des Schemaupdates vorher zu manipulieren und alle Änderungen an User-Objekten rauszuwerfen: Viel Spaß, wenn dann mal ein Supportcase passiert...

    • Haha 1
  6. Am 16.11.2023 um 09:24 schrieb MiLLHouSe:

    das -AllUsers hinzugefügt und nun steht im Log, dass er ein Paket gefunden hat

    Nur deinstalliert hat er nix, das Paket ist weiterhin vorhanden.

     

    Hab ich doch oben schon geschrieben - AllUsers-Removal funktioniert nur, wenn es ein Bundle ist. Und das hier ist kein Bundle, muß also pro User deinstalliert werden. Wenn Du im geplanten Task einfach ".\Benutzer" einträgst (oder englisch ".\Users"), sollte das klappen.

    Am 16.11.2023 um 10:43 schrieb BOfH_666:

    Dafür gibt es die Kommandozeilen-Option "-WindowStyle Hidden". Diese muss aber als erstes (vor allen anderen ...) angegeben werden, um korrekt zu funktionieren. ☝

     

    Wow - das hilft sogar mir noch. Hab mir bisher mit nem VBS-Wrapper und WScript beholfen...

  7. Ich würde das mal etwas aufdröseln - Pipes in unbeaufsichtigten Skripts sind Mist, weil Du nicht loggen kannst, was in der Pipeline passiert...

    So als Vorschlag - und vielleicht mag ein Mod das in  Skripting-Forum schieben, da gehört es eher hin :-)

    Start-Transcript -Path "$( $MyInvocation.InvocationName ).Log"
    
    $Packages = Get-AppxPackage Microsoft.OutlookForWindows
      
    Write-Host "Number of Packages found: $( $Packages.Count )"
    If ( $Packages.Count -gt 0 ) {
      Foreach ( $Package in $Packages ) {
      	$Package | Select Name, Version, InstallLocation | Format-Table -Autosize
      }
      Write-Host "Removing Packages..."
      Foreach ( $Package in $Packages ) {
       Remove-AppxPackage $Package -Verbose
      }
    } Else {
      Write-Host "No Packages found, nothing to do..."
    }
     
    Stop-Transcript

     

    Die Vorschläge mit "Remove-AppxPackage -AllUsers" werden nicht funktionieren, weil das kein Bundle ist, das kann nur pro User deinstalliert werden. Also muß auch das Skript im Benutzerkontext laufen.

    • Like 1
×
×
  • Neu erstellen...