Deaktivierte ADUser und SfBOnline
Manche Firmen legen neue Benutzer vorab als deaktivierte Konten in einem Provisioning-Prozess an. Die Aktivierung des Konto erfolgt erst mit dem Eintritt der Person in das Unternehmen. Zu dem Zeitpunkt wird dann auch das Kennwort gesetzt. Diese Seite beschreibt einen unerwarteten Effekt mit dem Skype for Business Online Control Panel und das eine Reaktivierung in der Cloud nicht von Dauer ist.
Um den Fall genauer nachzustellen, habe ich in meiner Labor-Umgebung folgende Schritte durchgeführt:
Neuer deaktivierter AD Benutzer
Zuerst habe ich einen Benutzer im lokalen Active Directory angelegt, der deaktiviert ist.
Genau genommen habe ich gleich mehrere Konten angelegt, um auch den Gegenbeweis zu führen. Interessant ist aber nur dieser Benutzer.
Aktivieren für SfBOnline
Gehen wir davon aus, dass wir aufgrund der Größe und Bequemlichkeit ADSync nutzen und SfB Hybrid sind. Mit einer lokalen Skype for Business PowerShell aktivieren wir den Benutzer dann für Skype for Business in der Cloud.
Enable-CSUser ` -identity Disableduser@uclabor.de ` -HostingProviderProxyFQDN sipfed.online.lync.com ` -SipAddressType EmailAddress
Das Commandlet setzt dann einige Felder beim AD-Objekte, die auf Skype for Business Hybrid Mode weiter beschrieben sind.
Dies ist quasi der minimale Satz an Daten, die für eine lokale SfB Server-Umgebung erforderlich sind.
ADSync Import/Export
Beim nächsten Lauf der ADSync wird der Benutzer samt seinen LDAP-Feldern übertragen:
Interessant finde ich hierbei, dass nicht alle MSRTCSIP-Felder aus dem lokalen Active Directory ausgelesen und in das Metadirectory übertragen werden. Die Felder wie "MSRTCSIP-InternetAccessEnabled" und "MSRTCSIP-FederationEnabled" werden nicht übertragen. Das Feld MSRTCSIP-PrimaryHomeServer ist in der Cloud nicht nicht erforderlich ist. Entsprechend kann ADSync auch nur die Information aus diesen Feldern zum AzureAD übertragen.
Sie sehen aber auch hier, dass die Information aus dem Feld "UserAccountControl" in das Feld "AccountEnabled" übertragen wurden.
Das bedeutet aber auch, dass diese Einstellungen in SfBOnline zu provisionieren sind und bei einem Betrieb ohne lokale SfB-Topologie nicht mehr gesetzt werden müssen.
Lizenz zuweisen
Ehe ein Benutzer in SfB Online arbeiten kann, benötigt er natürlich eine Lizenz. Dieser Sachverhalt ist schon länger bekannt und hier verhält sich Skype for Business etwas anders als Exchange Online. Exchange legt für eine RemoteMailbox in der Cloud auch dann ein Postfach an, wenn der Benutzer noch keine Exchange Online Lizenz hat. Es wird aber ohne Lizenz nach 30 Tagen wieder gelöscht. Bei Skype for Business muss ich erst eine Lizenz zuweisen,, was per Office 365 Portal oder gruppenbasierte Lizenzierung oder PowerShell schnell bewerkstelligt ist.
Sie sehen hier anhand des "Unblock Sign-in" auch, dass die Anmeldung "deaktiviert" ist und ich eine SfB Online Lizenz zugewiesen habe.
Kontroller SfBOnline Panel
Nun hätte ich erwartet, dass das Konto nach Ablauf der Replikation innerhalb von Microsoft 365 auch im Skype for Business Portal erscheint. Aber selbst nach einer Stunde war nur ein anderer, allerdings aktiver Test-Benutzer sichtbar. Die Replikation und das Provisioning scheint also zu funktionieren aber der deaktivierte Benutzer ist nicht sichtbar.
Eine Kontrolle per Skype for Business Online PowerShell hat aber sehr wohl ergeben, dass ein Benutzer provisioniert wurde: (Auszug)
PS C:\> get-csonlineuser disableduser@uclabor.de UserAccountControl : AccountDisabled, PasswordNotRequired, NormalAccount Id : CN=<guid>,OU=<guid>,OU=OCS Tenants,DC=lync2a001,DC=local AssignedPlan : {<XmlValueAssignedPlan xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Plan SubscribedPlanId="<guid>" ServiceInstance="MicrosoftCommunicationsOnline/NOAM-2A-S6" CapabilityStatus="Enabled" AssignedTimestamp="2020-06-09T13:51:18Z" ServicePlanId="<guid>" xmlns="http://schemas.microsoft.com/online/directoryservices/change/2008/11"> <Capability> <Capability Plan="MCOProfessional" xmlns="http://schemas.microsoft.com/online/MCO/2009/01" /> </Capability> </Plan> </XmlValueAssignedPlan>} InterpretedUserType : HybridOnlineDisabledUser Alias : DisabledUser DirSyncEnabled : True HideFromAddressLists : False OnPremHideFromAddressLists : False ProvisionedPlan : {<XmlValueProvisionedPlan xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Plan SubscribedPlanId="2810e7e6-466c-4cd1-9cb7-1bf8955ceebe" ServiceInstance="MicrosoftCommunicationsOnline/NOAM-2A-S6" CapabilityStatus="Enabled" AssignedTimestamp="2020-06-09T13:51:18Z" ProvisioningStatus="Success" ProvisionedTimestamp="2020-06-09T14:42:27.6955862Z" xmlns="http://schemas.microsoft.com/online/directoryservices/change/2008/11" /> </XmlValueProvisionedPlan>} OnPremHostingProvider : sipfed.online.lync.com OnPremOptionFlags : 257 OnPremEnterpriseVoiceEnabled : False OnPremSIPEnabled : True OnPremSipAddress : sip:DisabledUser@UCLABOR.DE OnPremLineURI : ShadowProxyAddresses : {sip:DisabledUser@UCLABOR.DE} SipProxyAddress : sip:DisabledUser@UCLABOR.DE ServiceInstance : microsoftcommunicationsonline/noam-2a-s6 LastSyncTimeStamp : 09.06.2020 17:15:00 LastProvisionTimeStamp : 09.06.2020 17:15:16 LastPublishTimeStamp : 09.06.2020 17:17:06 LastSubProvisionTimeStamp : 09.06.2020 16:43:35 UserPrincipalName : DisabledUser@UCLABOR.DE PendingDeletion : False DisplayName : DisabledUser ProxyAddresses : {sip:DisabledUser@UCLABOR.DE} SipAddress : sip:DisabledUser@UCLABOR.DE Enabled : False TenantId : <guid> UserRoutingGroupId : <guid> RegistrarPool : sippoolblu2a05.infra.lync.com DialPlan : DE HostingProvider : sipfed.online.lync.com Name : <guid> Guid : <guid> WhenChanged : 09.06.2020 17:17:06 WhenCreated : 09.06.2020 15:46:21 OriginatingServer : EU22A00ADS01.lync2a001.local IsValid : True ObjectState : Unchanged
Das Objekt ist "Valid" aber "Enabled = False". Aus dem "ProvisionedPlan" sehen Sie die "SfB-Lizenz" und der "InterpretedUserType" gibt korrekt ein "HybridOnlineDisabledUser" wieder.
Konto aktivieren
Der Verdacht liegt also nahe, dass es nicht ausreichend ist, den Benutzer On-Premises als SfBOnline-Konto zu konfigurieren und eine Lizenz zuzuweisen. Der einzige Unterschied ist, dass das Konto deaktiviert ist. Im Office 365 Portal konnte ich ja sehen, dass das Benutzerkonto "geblockt" war. Also habe ich im AD das Konto aktiviert und ADSync laufen lassen.
Hinweis: Sie können auch bei einem per
ADSync synchronisierten Konto in der Cloud die Sperre
entfernen.
Interessanterweise erkennt dies sogar ADSync beim nächsten "Import" aus dem Tenant.
Allerdings wird es nicht in das lokale Active Directory geschrieben. ADSync nutzt stattdessen den Wert im lokalen Active Directory um den Wert im AzureAD wieder zurück zu setzen. Das Azure-AD-Konto ist also nur kurze Zeit nutzbar, bis ADSync die Änderungen beim nächsten Synchronisationslauf wieder auf den Wert des lokalen Active Directory setzt.
Wenn Benutzer per ADSync abgeglichen werden, dann müssen Sie im lokalen Active Directory steuern, ob das Konto aktiv oder deaktiviert ist.
Sichtbar
Nachdem das Konto auch im AzureAD aktiv gesetzt wurde, dauerte es noch bis zu einer Stunde, damit der Benutzer auch im Skype for Business Online Control Panel gelistet wurde:
Damit hat dieser Benutzer dann den Status erreicht, den ich bisher immer kannte.
Das Skype for Business Online Control Panel zeigt keine deaktivierten Benutzer an (Stand Jun 2020)
Verschwunden
Natürlich habe ich auch die Gegenprobe gemacht. Ich habe den Benutzer im Active Directory wieder deaktiviert und ADSync seine Arbeit tun lassen.
ich wollte ja wissen, wie sich Skype for Business Online verhält, wenn ein bereits aktivierter Benutzer temporäre oder dauerhaft deaktiviert wird. Ich war dann schon etwas verwundert, dass der Benutzer in Skype for Business Online wieder verschwunden ist.
Das Konto wird aber ausgeblendet, obwohl es natürlich per CSOnline-Powershell noch gefunden wird. Ich hätte zumindest hier erwartet, dass das Konto im SfB Online Control Panel bestehen bleibt.
Zusammenfassung
Es hat mich selbst überrascht, dass das SfB Online Portal sich so verhält. Das ist aber natürlich dem Vorgehen geschuldet, dass ich bislang nur wenig mit deaktivierten Konten zu tun hatte bzw. diese gezielt in der langen Liste der korrekt provisionierten Konten gesucht und vermisst hätte. Aber wenn Sie, bzw. ein Kunde eine größere Anzahl an Benutzern auf dem lokalen SfB Server angelegt und dann in die Cloud migriert hat, wird man schon unruhig, wenn die Konten On-Premises als "Cloud" geführt werden aber in SfBOnline nicht sichtbar sind.
Nebenbei habe ich so auch noch schnell gelernt, dass ich synchronisierte deaktivierte AD-Konten in der Cloud aktivieren kann aber die Änderung nach dem nächsten ADSync-Lauf wieder den lokalen Einstellungen entsprechen.