Lync Segregation

Microsoft betreibt sehr viele Firmen in Office 365 und eine der wichtigsten Punkte ist, dass die Firmen möglichst von einander abgeschottet sind. Danke RBAC und Verwaltung per Web ist die Administration schon ziemlich getrennt, d.h. ein Administrator bekommt nur "seine" Anwender zu sehen. Aber das ist nur ein Teil der Miete. Wenn zwei Lync user in der gleichen Umgebung von unterschiedlichen Firmen miteinander in Kontakt treten, dann darf die Information nicht "Same Company" sein und damit Informationen auf der Kontaktkarte preis geben, die eigentlich "geheim" sind.

Lync Adressbuch

Für viele Firmen ist die Trennung innerhalb des Adressbuch schon ein wichtiger Schritt um vielleicht eine allzu große und damit schwerer nutzbare GAL zu verkleinern oder Töchter von der Konzernmutter zumindest in Lync zu separieren. Die Anwender können bei Kenntniss der SIP-Adresse natürlich weiter ungestört miteinander kommunizieren.

Das Lync Adressbuch wird vom Lync Server aus den Daten im Active Directory regelmäßig generiert und einmal zum "Download" bereit gestellt als auch vom per WebQuery erreichbar gemacht. Client landen sich dieses Adressbuch herunter und immer wenn Sie im Lync Communicator einen Namen oder Nummer eingeben, durchsucht der Client das lokale Adressbuch. Ohne eine Filterung würde ein Anwender im Adressbuch immer alle Objekte im gesamten Forest finden können, weil diese ja im Adressbuch vorhanden sind. Zusätzlich durchsucht Lync natürlich noch Outlook Kontakte.

Wenn der große Forest aber nun in Wirklichkeit eine "gehostete" Umgebung ist und viele Firmen die gleichen Server nutzen, dann ist genau dieses Verhalten nicht erlaubt. Es muss also eine Möglichkeit geben, in Lync die Adresslisten zu trennen.

Exchange 2003/2007 haben dazu mit ACLs auf den Objekten gearbeitet (Segregation 2007) und eigene Offline Adressbücher für die einzelnen Firmen. Exchange 2010 hat dazu die Adressbuch Policies (E2010/2013 Adress book Polices) eingeführt, über die jedem Client bestimmte Adressbücher explizit zugewiesen werden. Das funktioniert natürlich nur, wenn die Clients nicht direkt per LDAP die Domaincontroller befragen können.

msRTCSIP-GroupingID oder msRTCSIP-TenantID

Schon im OCS2007R2 gab es die Möglichkeit, Adressbücher zu separieren. Dazu mussten per WMI z.B.: OU-basierte Filter relativ mühsam konfiguriert werden. Seit Lync 2010 wurde dies anders gelöst. Durch die Lync 2010 Schemaerweiterung bekommt jeder AD-Benutzer neue Felder, die überwiegend mit "msRTCSIP-" beginnen und sind von Microsoft gut dokumentiert:

Seit dem Lync 2010 Schema sind also die beiden folgenden Felder auf jedem Benutzer verfügbar, aber per Default nicht gefüllt:

Die Bedeutung ist in "Schema Changes in Lync Server 2010" (http://technet.microsoft.com/en-us/library/gg398944(v=ocs.14).aspx) auch beschrieben..

  • msRTCSIP-GroupingID
    This attribute is a unique identifier of a group, used to group address book entries.
  • msRTCSIP-TenantId
    This attribute stores the unique identifier of the tenant. This identifier should be unique across all tenants.

Da fragt man sich natürlich erst mal, warum es zwei Felder gibt, die in die gleichen Richtung gehen. Die Lösung ist denkbar einfach: Das Feld msRTCSIP-GroupingID sorgt nur dafür, dass sich nur noch die Personen mit der gleichen msRTCSIP-GroupingID gegenseitig im Adressbuch finden. Aber sonst gibt es keine weitere weitere "Filterung". wenn Sie also eine Mail von einer Person der gleichen Lync Umgebung aber anderen msRTCSIP-GroupingID bekommen, dann sehen sie dennoch dessen Präsenz in Outlook und haben per Default den "Same Company-Level". Darauf weist Microsoft explizit noch einmal hin:

The attribute msRTCSIP-GroupingID should not be used in a commercial hosting environment and is not supported by Microsoft due to the privacy and security risks when providing multi-tenancy in a hosting environment. The use of the attribute only simulates a grouping of users in logical partitions, and does not create a true partition in which the security and privacy of the tenants can be tightly controlled.
Quelle: PartitionByOU Replaced with msRTCSIP-GroupingID http://technet.microsoft.com/en-us/library/gg429725.aspx

Wer also wirklich mehrere komplette separierte Firmen auf der gleichen Lync Umgebung betreiben will, muss stattdessen mit dem Feld "msRTCSIP-TenantId" arbeiten. Doch dazu später mehr.

Ein Blick in das Active Directory Schema zeigt, dass es einfach ein String mit bis zu 16 Zeichen Länge ist. Das Feld wird indexiert und ist im GC vorgehalten und per Default nicht gesetzt.

Hier kann per Skript eine ID hinterlegt werden, über die eine Art geschlossene Benutzergruppe gebildet wird. Alle Empfänger mit dieser GroupingID können sich untereinander finden. Jeder Empfänger kann aber nur genau eine GroupingID haben. Anders als in Exchange 2010 ABPs ist es also nicht möglich, dass ein Empfänger in mehreren "Kreisen" auftaucht. Speziell der Fall in sehr großen Firmen ist daher nicht abzudecken, dass Tochterfirmen nur sich selbst sehen aber die Konzernmutter alle Empfänger sieht.

Eintrag per Skript setzen

Nun ist es ja nicht gerade die bevorzugte Methode per ADSIEDIT an den LDAP-Feldern zu schrauben. Das ist fehleranfällig und gefährlich. Leider gibt es aber keine GUI, mit der diese Einstellung erfolgen kann. Das wäre aber auch nicht wirklich sinnvoll. Ein Skript kann aber hierbei helfen. Ob Sie nun dieses Feld anhand einer OU-Zugehörigkeit oder über die Mitgliedschaft z.B. in einer Gruppe setzen bleibt ihnen überlassen. Das Feld muss aber wohl eine GUID enthalten. Es bietet sich daher an, die ObjektID der Quelle, also der OU oder der Gruppe einfach als Schlüssel heran zu ziehen. So ist der Wert sicher eindeutig und zuzuordnen.

Mit PowerShell und den Active Directory SnapIns ist das auch schnell gemacht. für das abschließende Update-CSAddressBook muss es eine Lync PowerShell sein

# Import des AD Moduls 
Import-Module ActiveDirectory

# Filterung der Adresslist auf basis einer OU
$FirmenOU = "OU=Benutzer,OU=Firma,DC=msxfaq,DC=de"

# OU holen und GUID auslesen
$GUID = (Get-ADOrganizationalUnit -Identity $FirmenOU).ObjectGUID
# Alternativ koennen Sie auch eine zufällige GUI setzen
# $GUID = [guid].NewGuid() 

# Suche aller user und Setzen der msRTC-GroupingID
Get-ADUser `
   -LDAPFilter "(ObjectClass=user)" `
   -SearchBase $FirmenOU `
   -Properties msRTCSIP-GroupingID,msRTCSIP-PrimaryUserAddress,comment `
|Set-ADUser `
   -Replace @{'msRTCSIP-GroupingID'=$GUID} 

# Update anwerfen Update-CsAddressBook 

Wer natürlich einen Provisioning-Prozess hat, sollte hier gleich beim Anlegen bzw. Aktivieren des Benutzers die passenden Einträge vornehmen.

Multi Tenant Hosting

Ich gehe auf dieser Seite absichtlich nicht auf die Trennung von Firmen auf der gleichen Lync Umgebung ein. Ich habe zwar weiter oben schon das Feld "msRTCSIP-TenantID" beschrieben aber die Installation einer solchen sauber abgeschotteten HostingUmgebung mit mehreren Kunden (Tenants) ist eine ganz eigene Sache für sich und selbst ich als Lync Master orientiere mich dabei dann strikt an die Vorgaben von Microsoft, die auch für jeden öffentlich zugänglich sind

Microsoft Lync Server 2010 Multitenant Pack für Partner Hosting Deployment Guide
http://www.microsoft.com/en-us/download/details.aspx?id=28587

Die Separierung mittels msRTCSIP-TenantID filtert nicht nur das Adressbuch, sondern generiert wirklich auch eigene Adressbücher für jeden Tenant, was Sie z.B. als mehrere Verzeichnisse im ABFILES-Verzeichnis auf dem Lync-Webservice erkennen können.

Aber um den internen Schutz zwischen den Firmen zu gewährleisten, wird basierend auf dem Inhalt von msRTCSIP-TenantID einige Daten in der SQL-Datenbank anders gespeichert. Ein ganz so "einfacher" Wechsel oder gar Parallelbetrieb mit Benutzern ohne msRTCSIP-TenantID ist nicht möglich. Der Einsatz einer echten Hosting-Installation muss also wohl überlegt werden, da damit auch die ein oder andere FunktionsEinschränkung verbunden ist. Der betrieb mit msRTCSIP-TenantID ist also wirklich nur etwas für Provider, die mehrere Lync Kunden auf einer Shared Umgebung laufen lassen wollen.

The GroupingID will let you partition the address books. The AD Property Sets will keep the presence bubbles from showing in Outlook, etc. If you want to be really strict about partioning the Tenants, then you could use the TenantID and install the IncomingFederation/OutgoingFederation server applications on the Front end servers. This isnt all of it though, because you are going to have to setup the Simple URL's at the Tenant Global scope. (This isnt possible with the existing PowerShell cmdlet's, so expect to do some direct DB inserts into the XDS) As you can see, unless you really know how this beast works at a low level and have the capability to dig deep.. you probably want to stick with GroupingID and Property Sets.
Quelle: http://social.technet.microsoft.com/Forums/lync/en-US/ccfe8c64-261d-4f0c-8c87-ca7fcb56a497/lync-multitenant-installation

Andererseits ist es nicht ausreichend mit der GroupingID die Adresslistenansicht zu filter, wenn wir wirklich mehrere unabhängige Kunden auf der gleichen Lync-Umgebung hosten wollen:

Caution: The attribute msRTCSIP-GroupingID should not be used in a commercial hosting environment and is not supported by Microsoft due to the privacy and security risks when providing multi-tenancy in a hosting environment. The use of the attribute only simulates a grouping of users in logical partitions, and does not create a true partition in which the security and privacy of the tenants can be tightly controlled.
Quelle: http://blogs.technet.com/b/nexthop/archive/2012/08/08/lync-server-2010-multitenant-pack-for-partner-hosting-overview.aspx

Get-CSUser und Get-CSADUser

Auf der Lync PowerShell gibt es gleich zwei Commandlets, die sich mit der Verwaltung von Lync Empfängern beschäftigt.

Interessant ist dabei, dass beide ein Feld "TenandID" (msRTCSIP-TenantId) liefern aber keines ein Feld, was auf die GroupingID (msRTCSIP-GroupingID) verweist. Es bleibt also auch hier für Auswertungen nur der Weg über ADSI oder die Active Directory Commandlets.

Weitere Links