Nieuw in Office 365: Multifactor Authentication

Door ralpje op maandag 17 februari 2014 18:59 - Reacties (1)
Categorie: Office365, Views: 2.723

GMail kon het al langer, maar binnen Office 365 was het een tijd lang alleen voorbehouden aan administrators: multifactor authentication. Gebasseerd op het 'something you know, something you have' principe biedt MFA meer veiligheid dan een one-step authentication: als je password gecompromitteerd is (bijvoorbeeld omdat je overal hetzelfde wachtwoord gebruikt en er ergens een databaseje met niet encrypted passwords is gelekt) dan heeft men nog steeds geen toegang tot je account zonder dat men ook je mobiele telefoon in handen heeft. Eigenlijk een must voor elke cloud-dienst waar potentieel kostbare data zoals e-mail is opgeslagen.

Sinds een weekje is dat dus mogelijk, in Office 365. De dienst is gratis beschikbaar voor alle Office 365 abbonnees, met uitzondering van de SMB- en dedicated plans.

Wel zijn er een paar kleine drawbacks, zoals op de O365 community blog duidelijk wordt: users die MFA gebruiken kunnen niet inloggen in OWA for iPhone en de Windows Azure Module voor Powershell.

Op dit moment werken alle browser-toepassingen van Office 365 met MFA. Voor overige applicaties, zoals de desktop applicaties van Outlook en Lync, kun je een 'App Password' genereren. Dit is vergelijkbaar met bijvoorbeeld GMail, waar je bij gebruik van two factor authentication een sterk wachtwoord kon genereren voor gebruik in je mailclient. Een volledig lijst met applicaties die 'App Password' ondersteunen is hier te vinden.
Overigens heeft Microsoft al aangekondigd te werken aan een update van Office 2013 die dit jaar nog uitkomt, waarin de desktop applicaties ook ondersteuning bieden voor MFA.

Microsoft maakt voor MFA onder andere gebruik van technologie van PhoneFactor , het bedrijf dat in 2012 door Microsoft werd ingelijfd.
De gebruiker heeft een aantal mogelijkheden om als 'tweede factor' in MFA te gebruiken. Er kan een spraakoproep worden gestart naar zowel een mobiel als een vast nummer of een SMS met One Time Password worden verstuurd. Veruit de coolste optie is echter de Multi-Factor Authentication App. Deze app is beschikbaar voor (uiteraard) Windows Phone, maar ook voor Android eniOS en kan op twee manieren gebruikt worden.
Als eerste kan een push-notificatie worden verstuurd naar het toestel zodra er op het account wordt ingelogd. Door de push-notificatie te open en op 'accepteren' te klikken wordt de inlogsessie voltooid. Hiervoor hoeft de gebruiker dus geen code over te tikken waar mogelijk fouten bij gemaakt worden; een klik op de knop is voldoende.
De tweede mogelijkheid vanuit de app is een One Time Password. Bij het openen van de app wordt een 6-cijfigerige code getoond die regelmatig wijzigt. Deze code dient bij het inloggen dan als tweede vorm van authenticatie ingevuld wordt. Dit zou een logische keuze kunnen zijn voor gebruikers die wel een smartphone hebben, maar geen databundel. Op deze manier kan er ook geauthenticeerd worden als er geen WiFi beschikbaar is.

Maar de hamvraag: hoe werkt multifactor authentication in Office 365. Antwoord: zoals je zou verwachten. Microsoft heeft met Wave15 van Office 365 een duidelijk en makkelijk te beheren pakket neergezet en gaat verder op die ingeslagen richting.

Multifactor authentication kan via de O365-portal door de beheerder worden ingesteld. Onder 'users and groups' is de link naar het instellen van MFA te vinden.
Set multi-factor authentication
Na het aanklikken van de link kan door een zoekactie worden bepaald voor welke accounts MFA moet worden geactiveerd.
User instellen voor MFA

De beheerder kan niet veel meer dan MFA aan- of uitschakelen. De rest van de configuratie wordt door de gebruiker zelf gedaan. Tijd dus om in te loggen met het account waarop zojuist MFA ingeschakeld is.
Aanmelden met user account
Na de reguliere inlogprocedure meldt de O365-site dat MFA moet worden geconfigureerd voor we verder mogen gaan.
Prompt om MFA te configureren
Default staat MFA ingesteld om gebruik te maken van het mobiele nummer van de gebruiker. Uiteraard kan het mobiele nummer hier gewijzigd worden door de gebruiker en kan er worden gekozen voor een SMS of een spraakoproep.
Instellen van MFA
Ik wil graag hip zijn, dus ik kies voor authenticatie via de mobiele app.
Instellen voor 'mobile app'
Door op 'configure' te klikken kan de app op je telefoon worden geconfigureerd. Dit kan door de url en code uit het pop-up venster over te nemen, of door simpelweg de QR-code met je telefoon te scannen.
Configureren mobile app via QR code
Als de app is ingesteld wordt geverifieerd of authenticatie ook daadwerkelijk werkt.
Verifiëren van applicatie
Als de verificatie succesvol is uitgevoerd kan het instellen van MFA worden afgerond.
Verificatie succesvol
Eén van de laatste stappen is het achterlaten van het mobiele nummer. Op deze manier kun je altijd terugvallen op een andere manier van authenticatie als de app niet beschikbaar is.
Mobiele nummer voor geval van nood
De vierde en laatste stap bij het instellen van je MFA-account is het genereren van een App-Password. Dit wordt, zoals gezegd, gebruikt bij het authenticeren vanuit desktop apps zoals Outlook en Lync.
Configureren van App Passwords
Er wordt één App Password gegenereerd. Uiteraard is het op een later moment alitjd mogelijk om App Passwords bij te maken of juist te verwijderen.
App Password

Als het configureren van MFA voltooid is en het account is ingelogd, kunnen we op de reguliere O365-settings pagina zelf nog zaken aanpassen.
User settings na inloggen
De link 'update my phone numbers' is wellicht wat misleidend, maar hier kan ook de default instelling voor MFA worden ingesteld.
Verschillende beschikbare opties
En op de tab App Passwords kunnen passwords worden aangemaakt over verwijderd.
Aanmaken extra app passwords

Als bij het inloggen de mobiele app om wat voor reden dan ook niet gebruikt kan worden, kan eenvoudig worden gekozen voor een andere vorm van authenticatie.
Mogelijkheid om andere activatie te kiezen
Er verschijnt een lijst mogelijke opties. Alle eerder besproken opties zijn hier beschikbaar.
Keuzemogelijkheden
Ik kies in dit geval voor authenticatie via SMS. Ik ontvang vrijwel direct een SMS op mijn mobiele telefoon met daarin de code die ingevoerd dient te worden.
Authenticatie via SMS

Relatief simpel dus. Eenvoudig in te stellen door te beheerder via de GUI, maar ook via Powershell. De gebruikers kunnen na activatie een mail krijgen waarin netjes staat uitgelegd wat ze moeten doen om hun account correct in te stellen en kunnen zelf bepalen welke form van authenticatie ze willen gebruiken. En uiteraard heeft Microsoft ook nog een handige video waarin het allemaal nog eens wordt uitgelegd.

Met deze multi-factor authentication heeft Microsoft weer een goede stap gezet om Office 365 ook voor meer grootschaliger gebruik goed in de markt te zetten. Op het gebied van security is dit uiteraard een hele grote stap voorwaards en het instellen en beheren is net zo eenvoudig als alle andere functies binnen de Office 365-portal.

Exchange-taken automatiseren met cmdlet extenstion agents

Door ralpje op maandag 07 oktober 2013 09:30 - Reacties (2)
Categorieën: Exchange, Powershell, Scripting, Windows, Views: 2.843

Er zijn dagen dat ik medelijden heb met mijn collega's. Niet omdat het werk vervelend is of omdat de koffie op kantoor slecht is, maar omdat ze mij als collega hebben. En dan met name omdat ik bij elke vraag om assistentie vraag: "heb je powershell al geopend?" ;)
In Server 2012 en Exchange 2013 blijkt eens te meer dat Powershell the way to go is. De grafische beheersmogelijkheden worden steeds verder uitgekleed en zijn, zeker in Exchange, al een tijdje niet meer dan een grafische schil om Powershell heen.
Toch zijn er zaken die in zowel Powershell als de EMC niet direct voor zich spreken. Eén van die dingen kwam ik afgelopen week weer tegen: Exchange retention policies en hoe deze op nieuwe mailboxen toegepast kunnen worden.

Een klant gebruikt Exchange server (in dit geval Exchange 2010 SP3) in combinatie met een softwarebased anti-spam pakket. Van oudsher is de organisatie gewend aan een 'spam'- of 'junk'mail folder in Outlook, waar de anti-spam software de verdachte mails in neerzet. De gebruiker kan vervolgens zelf beoordelen of de mail inderdaad spam is, of dat er een legitieme email per abuis als spam gemarkeerd is. Er is één nadeel: mensen checken de folder, lezen of verplaatsen de mail die ze nodig hebben en negeren de rest. De spamfolder wordt daarmee een vergaarbak van slechte emails die onnodig storage en backup consumeren maar natuurlijk eigenlijk gewoon verwijderd moeten worden.

De oplossing is relatief simpel: retention policies. Maak een retention tag voor de 'junk'folder, stel hem in op 'delete after 30 days' en maak vervolgens een retention policy die je op alle mailboxen kunt gaan toepassen.

Het daadwerkelijk toepassen op de mailboxen is in Powershell zo gepiept:

powershell:
1
get-mailbox -resultsize unlimited | foreach {set-mailbox $_.identity -retentionpolicy policy}


Zo simpel is het.... Maar de policy is nu alleen van toepassing op de bestaande mailboxen. Mailboxen die nieuw worden aangemaakt krijgen niet automatisch deze policy mee. Ook is het niet mogelijk om een default policy voor je Exchange-omgeving of mailboxdatabase in te stellen.
Ongeacht of je de EMC of Powershell gebruikt zal je dus bij het aanmaken van een mailbox expliciet moeten aangeven dat je deze policy wilt gebruiken.

En dát is dus waar de exchange cmdlet extension agents om de hoek komen kijken; in dit geval de scripting agent.
Exchange heeft een aantal 'extension agents', bijvoorbeeld voor management van het Offline Address Book. De scripting agent is één van deze in totaal zeven agents en is de enige die standaard nog niet is ingeschakeld.

De werking van deze agent is redelijk eenvoudig, maar toch is het vaak een onbekend of, wellicht beter, onderbelicht deel van Exchange. Na het activeren van de scripting agent wordt die agent elke keer aangeroepen als er een een cmdlet op de server uitgevoerd wordt. Dat gebeurt niet alleen bij cmdlets die direct van Powershell worden uitgevoerd, maar ook als ze worden uitgevoerd door de Exchange Management Console, Exchange services of Exchange Control Panel.
Als de agent wordt aangeroepen wordt er gecontroleerd of er scripts geconfigureerd zijn voor dat betreffende cmdlet. Dat is dus wat we gaan doen om te zorgen dat onze retention policy netjes op alle nieuwe mailboxen wordt toegepast.

Als eerste moeten we zorgen dat de scripting agent geactiveerd wordt. Dit is redelijk eenvoudig: in de <installation path>\V14\Bin\CmdletExtensionAgents folder staat een ScriptingAgentConfig.xml.sample. Door deze te hernoemen naar ScriptingAgentConfig.xml hebben we een config file voor de scripting agent. De agent zelf activeren we vervolgens vanuit Powershell:

powershell:
1
Enable-CmdletExtensionAgent "Scripting Agent"


Nu nog zorgen dat we het script laten doen wat we willen :) Laten we eerst naar het volledige script kijken, daarna breken we het in stukken om te zien wat het doet:

XML:
1
2
3
4
5
6
7
8
9
10
11
<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">
<Feature Name="Mailboxes" Cmdlets="New-Mailbox,Enable-Mailbox">
<ApiCall Name="OnComplete">
if($succeeded) {
$Name= $provisioningHandler.UserSpecifiedParameters["Alias"]
Set-Mailbox $Name -RetentionPolicy "Retention Policy"
}
</ApiCall>
</Feature>
</Configuration>


Het eerste dat opvalt is dat het eigenlijk geen script maar XML is. In de XML-file wordt gespecificeerd welke script in welke situatie moet worden uitgevoerd. Door deze opzet is het ook eenvoudig om meerdere zaken in één config-file op te nemen.

De eerste échte regels na het 'openen' van de XML-file geven aan dat deze actie moet worden uitgevoerd bij het aanmaken van nieuwe mailboxen of het mail-enablen van bestaande users.

XML:
1
2
<Feature Name="Mailboxes" Cmdlets="New-Mailbox,Enable-Mailbox">
<ApiCall Name="OnComplete">

Met andere woorden: bij het gebruik van new-mailbox of enable-mailbox moet iets gestart worden, en wel nadat de actie compleet uitgevoerd is. De 'feature name' tag mag je zelf invullen en is puur voor de overzichtelijkheid van je XML-file. Je kunt bijvoorbeeld blokken met zaken voor provisioning scheiden van scripts die je wilt starten als je een mailbox verwijdert.

In de volgende regels geven we aan wanneer er iets moet worden uitgevoerd en wat dat dan is:

XML:
1
2
3
4
if($succeeded) {
$Name= $provisioningHandler.UserSpecifiedParameters["Alias"]
Set-Mailbox $Name -RetentionPolicy "Retention Policy"
}


De variabele $name wordt eerst ingesteld, door de aangeroepen API, met de naam van de zojuist aangemaakt mailbox.
Vervolgens wordt een set-mailbox aangeroepen op de $name mailbox om de retention policy in te stellen.
In de script block, die wordt aangeven met de { en } symbolen, kun je reguliere powershell-code opnemen. Je kunt er echter ook voor kiezen om een externe .ps1-file met Powershell-scripts aan te roepen. Zeker als je veel gebruik gaat maken van de scripting agent en wat meer complexe code gaat gebruiken is dat bevorderlijk voor leesbaarheid van de config-file.

Aan het eind wordt het XML-document uiteraard weer netjes afgesloten.

De handeling die door de scripting agent wordt uitgevoerd zie je niet terug in (bijvoorbeeld) de Powershell-code die de EMC laat zien bij het aanmaken van de mailbox. Wel krijg je feedback in de wizard als de API call rondom de scripting agent niet goed kan worden uitgevoerd en een error geeft. In dat geval wordt de mailbox wel probleemloos aangemaakt, maar worden de extra acties vanuit de scripting agent niet doorgevoerd op de mailbox.
Als de scripting agent wel gewoon zonder problemen zijn werk kan doen, zal je direct na het aanmaken van de mailbox in de eigenschappen van de mailbox zien dat de retention policy actief is.

Je begrijpt dat je op deze manier veel zaken in Exchange kunt automatiseren. Het leukste is om hier in je testomgeving eens mee aan de slag te gaan, zodat je kunt zien wat er allemaal mogelijk is.

Voor de verbeelding nog een ander mooi voorbeeld van het gebruik van de agent:

XML:
1
2
3
4
5
6
7
8
<Feature Name="MailboxProvisioning" Cmdlets="remove-mailbox">
<ApiCall Name="validate">
if($succeeded)    {
$removedmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]
New-MailboxExportRequest -Mailbox $removedmailbox -FilePath \\filserver\PSTFiles
}
</ApiCall>
</Feature>

In dit geval wordt de ApiCall 'validate' gebruikt. Bij het uitvoeren van een cmdlet checkt Exchange altijd eerst of het cmdlet valide is en of er genoeg informatie is om het cmdlet te starten. Als dit het geval is, wordt de scripting agent getriggerd. Dit gebeurt dan dus nog vóór het cmdlet daadwerkelijk wordt uitgevoerd. Wat het bovenstaande stuk code doet laat zich dus raden ;)

Laatste tip voordat je hiermee aan de slag gaat: in een multiserver omgeving moet je de scripting agent op elke exchange-server activeren en ook de xml-file op elke server beschikbaar hebben. Het makkelijkste is dan natuurlijk om die file simpelweg te kopiëren van de ene naar de andere server.

Meer informatie over de scripting agent vindt je (uiteraard) op Technet: http://technet.microsoft.com/en-us/library/dd297951.aspx

Vind de nerds in je Exchange-omgeving

Door ralpje op donderdag 19 september 2013 21:07 - Reacties (11)
Categorieën: Exchange, Office365, Powershell, Windows, Views: 4.777

Leuke oneliner in Powershell om te zien wie z'n iDevice al heeft geüpdatet naar iOS7:

powershell:
1
Get-MobileDevice | where {$_.DeviceOS -like "ios 7*"} | ft UserDisplayName, FriendlyName, DeviceOS, DeviceModel -A


Note: get-mobiledevice werkt alleen in Exchange 2013 (of O365 wave15). Voor Exchange 2010 of O365 wave14 gebruik je get-activesyncdevice.

Nu is dit natuurlijk een redelijke nutteloos stukje Powershell. Leuk om te zien welke fanboy al snel na het uitkomen van iOS7 heeft geüpdatet, maar niet meer dan dat. Tot je bedenkt dat er in het verleden wel eens problemen waren met Exchange en iDevices na bepaalde iOS-updates: je kunt met Powershell in zo'n geval dus eenvoudig een ActiveSync rule maken die bepaalde iOS-versies (of Android-versies. Of wat dan ook) blokkeert of in ieder geval niet meer automatisch toelaat.


powershell:
1
New-ActiveSyncDeviceAccessRule -QueryString &#8220;iOS 7.0&#8243; -Characteristic DeviceOS -AccessLevel Quarantine

O365: Same Sign On

Door ralpje op dinsdag 04 juni 2013 08:32 - Reacties (4)
Categorieën: ActiveDirectory, Office365, Views: 2.287

Voor klanten die graag Office 365 gebruiken maar niet graag werken met 'gescheiden' passwords voor de on-premise omgeving en die in cloud was er tot nu toe één optie: Door middel van ADFS en DirSync de gegevens van je on-premise AD syncen naar de cloud en daarmee ook je (kerberos)authenticatieticket synchroniseren. Eén keer inloggen en je bent geauthenticeerd op beide omgevingen.
Ideaal natuurlijk, maar ook een behoorlijk uitgebreide setup: je zult de ADFS rol ergens moeten implementeren, je zult een ADFS-proxy moeten inrichten én je moet DirSync kunnen draaien. De laatste twee rollen kun je niet elkaar óf met een domain controller combineren, waardoor je flink zult moeten investeren in servers.... en die wilde je nou net kwijt met je overstap naar de cloud.

Inmiddels heeft Microsoft hier een mooi alternatief voor gevonden: Password Synchronization. Deze extra functie in de nieuwe versie van DirSync bied de mogelijkheid om door middel van een zogenaamde password hash sync je on-premise password te syncen naar de cloud.
Dat syncen geeft ook gelijk aan wat het grootste nadeel is: er is géén single sign on. Je password wordt (gehashed, uiteraard) gesynchroniseerd vanuit de on-premise AD naar de cloud, maar er vindt geen synchronisatie plaats tussen (bijvoorbeeld) kerberostickets.
Het voordeel is echter dat je het password tussen beide omgevingen gelijk trekt en je dus bij een expired password maar op één plaats je password hoeft te wijzigen (en te onthouden ;)) én dat er minder ijzer nodig is om het te realiseren: de sync zit simpelweg in de nieuwste DirSync-versie en je hebt dus geen ADFS-Proxy of andere uitgebreide oplossingen nodig. Voor kleinere gebruikers die geen single sign on nodig hebben maar wel graag uniformiteit hebben in wachtwoorden is dit een prima optie en eens te meer toont Microsoft aan dat ze de markt goed in de gaten hebben en waar mogelijk hierop inspelen.

Mijn twee grootste wensen voor O365 op dit moment: Two-factor authentication (die nu in beta al voor admins beschikbaar is!) en self-service password recovery. Die laatste functie zit al deels in de nieuwste Wave 15 voor O365, maar uitsluitend voor admins. Ik verwacht dat Microsoft allebei deze functies voor het einde van dit kalenderjaar voor alle gebruikers heeft uitgerold.

Een alias aan een mailbox toevoegen

Door ralpje op zaterdag 18 mei 2013 00:04 - Reacties (1)
Categorieën: Exchange, Office365, Powershell, Views: 2.191

Iets wat je regelmatig doet en wat, zeker binnen Office 365, tot veel geklik leidt: het toevoegen van een alias aan een mailbox.
Omdat ik meeste beheerwerk in Office 365 via PowerShell doe maakte in een PS-Function die eenvoudig aan te roepen is om deze handeling uit te voeren.


PowerShell:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Function Add-EmailAlias {
    param($Identity, $EmailAlias)

    begin {
        $mb = Get-Mailbox $Identity
        if($mb.EmailAddressPolicyEnabled) {
            Set-Mailbox $Identity -EmailAddressPolicyEnabled $false
            $policy += 1
        }
        $addresses = $mb.EmailAddresses += $EmailAlias
    }

    process {
        Set-Mailbox $Identity -EmailAddresses $addresses
    }

    end {
        if($policy) {Set-Mailbox $Identity -EmailAddressPolicyEnabled $true}
    }
}


Simpelweg de functie aanroepen met als parameter de naam van de mailbox en de gewenste alias is genoeg.
Add-EmailAlias username alias@domein.nl

Om de functie te gebruiken dien je hem aan je PS-Profile toe te voegen. Een overzicht van de verschillende profiles, waar je ze kunt vinden en wat ze doen vind je overal op internet, bijvoorbeeld bij The Scripting Guy.