Säkrare men ändå enklare inloggning i Windows 10

Windows 10 är äntligen här och vi har massa nyheter dels i nuvarande släppt version men även en del funktioner som funnits i vissa ”Technical Preview”-versioner som vi väntar på.
En av de största säkerhetsfunktionerna som vi har i nuvarande version (10240) är Microsoft Passport. Flera har reagerat på hur Windows 10 kan påstå att en pinkod kan vara säkrare än deras tidigare lösenord?

image

Självklart är det enklare att komma ihåg en pinkod och är oftast enklare att skriva än ett komplext lösenord, men hur kan det vara säkrare?

Microsoft Passport

En funktion som är aktiverad by-default. Användaren autentiserar sig i Windows 10 med sitt konto mot någon av följande Identity Providers (IDPs): Azure Active Directory, Microsoft Account eller lokalt Active Directory. Rekommenderat är att påtvinga multifaktorautentisering vid denna process.

Efter autentiseringen skapas ett certifikat, asymmetriskt nyckelpar av datorns TPM chip vilket då är helt knytet till just den enheten/hårdvaran. Saknas TPM (Version 1.2 eller 2.0 för företag och TPM 2 för konsumenter) går det att göra mjukvarubaserat. Säkrast är dock att generera certifikatet via TPM chipet.

Efter en lyckad autentisering knyts Passports publika nyckel till användar-ID:t och registreras av IDPn.

imageimage

Det här är en engångsprocess per enhet och efter detta behöver användaren enbart logga in med sin PIN kod i Windows 10 för att kunna börja autentisera sig.
Vid autentisering mot någon tjänst, i dagsläget Azure AD, Office 365, AD tjänster men även en öppen standard Fast ID Online (FIDO) v2.0 som fler leverantörer nu ansluter sig till skickas en autentiserings-token som bekräftar att användaren är autentiserad till efterfrågad tjänst.

Den privata nyckeln som genereras lämnar aldrig TPM chippet, det är enbart den publika nyckeln som är associerad med användarkontot som signeras och registreras hos IDPn.

Windows Hello

Som standard används enbart PIN för att verifiera användarens identitet på den unika enheten för att sedan ge en single-Sign-on mot alla tjänster som stödjer Passport-autentisering. Genom att kombinera Microsoft Passport med Windows Hello kan vi istället erbjuda att använda biometrisk autentisering i form av avancerad ansiktsigenkänning eller fingeravtryck för att stärka den här processen. Windows Hello kräver att du har en enhet med stöd för den här typen av biometrisk teknik.

Viktigt att ha i åtanke är att din PIN-kod är helt knyten till just den enheten. Med andra ord om någon kommer över din PIN-kod kommer de inte kunna logga in mot någon tjänst med denna (till skillnad från om någon kommer över ditt lösenord)

Microsoft Passport ger

  • En multifaktorautentisering baserat på något som användaren har (sin enhet) och något som användaren vet (sin pinkod) eller något användaren är (Windows Hello). Den privata nyckeln är unik för den enheten och kan inte återanvändas på någon annan enhet.
  • En single-sign-On mot alla tjänster som stödjer Microsoft Passport
  • En säker autentisering utan att använda den svaga autentiseringsformen lösenord

Vad behövs för att komma igång inom din verksamhet?

Någon av följande fyra scenarior:

  • Azure Subscription
  • Azure Subscription + AAD Connect (Om du kör en hybrid miljö)
  • Windows Server 10 (2016) Active Directory och AD FS Server 10 (Om du kör enbart lokal miljö)
  • Du kan även välja att nyttja en egen PKI infrastruktur, vilket inte kräver att du behöver ha Windows Server 10 DC i ditt AD.

Jag och mina kollegor på Onevinn finns alltid till hands för att stötta er vid en implementation av Microsoft Passport och övrig Windows 10 -utrullning.

Publicerat i Windows 10 | Märkt , | 1 kommentar

Microsoft Advanced Threat Analytics (ATA)

Attacker sker dagligen och det är de attacker som ingen märkt av, eller känner till, som verkligen skadar verksamheten.
76% av alla attacker börjar med ett stulet konto/identitet, identiteter som idag finns på alla möjliga enheter och tjänster. I snitt tar en attack runt 8 månader och utan din vetskap kanske din miljö just nu är under attack. Det finns nu ett verktyg från Microsoft som kan identifiera detta! Innan vi går in på detta verktyg börjar vi med och tittar hur en attack ofta går till, enkelt förklarat, i tre olika steg:

Steg 1, stjäl någons identitet (lösenord)

I många fall skickas ett massutskick (SPAM) ut för att få användarna att uppge sina inloggningsuppgifter och/eller så väljer man ut helt vanliga användare. Oftast de där användarna som säger ”det är ingen som vill mig något, jag har inget hemligt” och som även har samma lösenord på den där matbloggen som det dom har till sitt konto i Active Directory. Alternativt någon form av ”brute force attack” eller keylogger för att få tag i ett lösenord och efter det har attackeraren kommit in på användaren dator.

Steg 2, identifiera en identitet med högre behörighet

Från användarens dator söker man sedan efter andra cachade identiteter med högre behörighet inom Active Directoryt, antingen på datorn i sig eller närliggande system som den specifika användaren har tillgång till. I många fall har någon på IT loggat in med ett konto medlem av ”Domain Admin”-gruppen för att installera en viss applikation eller vid installation/konfiguration av den aktuella datorn eller servern.

Steg 3, ta över kontrollen

När man väl identifierat detta konto och dess lösenord som är sparat i form av en lösenords-hash används detta och tekniken pass-the-hash eller pass-the-ticket (som vi sett ”hacker-demon” i 10 års tid demonstrera) för att logga in på en domän kontrollant.

När attackeraren väl kommit in på en domän kontrollant med full behörighet är spelet över. Attackeraren har full kontroll över allt inom verksamheten och kan göra precis vad den vill, inklusive att sopa igen sina spår.

Detta här är verkligheten! Attacker sker dagligen och det är de attacker som ingen märkt av eller känner till som verkligen skadar verksamheten.

Hur skyddar man sig?

Det finns flera sätt att minska risken för det här och skydda sig. Bara genom att få sig en tankeställare om tillvägagångssättet ovan brukar få de flesta att själv identifiera vad de behöver utföra för ändringar i sin infrastruktur.

Det intressanta är också att det finns något som har koll på allt ovanstående i form av försök till inloggningar, lyckade inloggningar och annan typ av access till olika tjänster och system inom din infrastruktur, nämligen ditt Active Directory!

Microsoft Advanced Threat Analytics (ATA)

Nu finns ett verktyg för att kunna identifiera den här typen av attacker och i god tid larma om att något suspekt pågår.

Microsoft Advanced Threat Analytics (ATA)! Verktyget är än så länge i Preview men kommer inom kort ut på marknaden.

Precis som namnet antyder är det dels ett analysverktyg som analyserar ditt Active Directory och gör följande:

  • Identifierar risker i ditt AD – Allt i form av svaga protokoll, läsbara lösenord till kända sårbarheter
  • Detekterar attacker mot system – Pass-the-Ticket, Pass-the-Hash till Bruteforce attacker med mera
  • Upptäcker onormala beteenden – suspekt aktivitet eller helt enkelt inloggningar mot system som frångår vanligheten

ATA installeras i din lokala miljö och beroende på infrastruktur konfigureras en eller flera ATA Gateways med portspegling av dina domänkontrollanter. All information samlas sedan upp i ett ATA Center som även det konfigureras lokalt. Ingenting installerad på befintliga servrar eller domänkontrollanter och vid rätt konfiguration är ATA helt dolt även för någon som angriper miljön.

Efter implementation behöver ATA 2-3 veckor på sig för att bygga upp en baseline och därefter kommer den känna av ovanligheter och suspekta beteenden bland användarna. Vid incidenter kommer larm redovisas och det finns även möjligheter att konfigurera så det skickas ut ett mail när detta inträffas.

Enkelt test i Onevinns demomiljö där ATA larmar när vi skickar en osignerad LDAP förfrågan med ett domänadminkonto (vilket exponerar inloggningsuppgifterna):

clip_image001

Vi kan även göra sökningar och för att se över en viss användare och dess aktivitet.

clip_image002

Om vi kombinerar den här typen av teknik i vårat lokala Aktive Directory och sedan använder Azure Active Directory för extern access skulle vi enkelt kunna få rapporter vid suspekta beteenden av en identitet externt och då använda det interna ATA verktyget för att se all intern aktivitet med samma konto. Bästa av alla världar i det moderna samhället med dess enheter och tjänster som finns och används överallt av våra användare.

(Läs även https://itsakerhetsguiden.se/autentisering-i-azure/ )

Kort film om ATA

Läs mer här:
http://www.microsoft.com/en-ca/server-cloud/products/advanced-threat-analytics/

Publicerat i Active Directory, Advanced Threat Analytics | 4 kommentarer

Azure Web Application Proxy

Jag beskrev i en tidigare artikel om fördelarna att autentisera sig via Azure AD, men vad kan man då ha denna autentisering till?
Drömscenariot vore ju att kunna ta vilken intern webapplikation som helst och kunna ge tillgång till denna från Internet med extra säkerhet i form av bland annat:

  • Behörighetskontroll via självbetjäningsportal
  • Flerfaktorautentisering
  • Larm och rapporter över suspekta inloggningsförsök
  • Skydd mot DDOS attacker

Vi vill även kunna genomföra detta utan att behöva öppna upp för någon inkommande trafik till vår interna infrastruktur

Eftersom scenariot är att vi vill publicera en intern applikation får vi ju också förutsätta att denna applikation även internt kräver inloggning och då en användarvänlig sådan med integrerad AD/Windowsinloggning. Jag har en enkel site (skapad av Chris Klug) som påvisar vilken användare det är som loggat in, vilket ser ut enligt följande från en intern klient:

clip_image001

Med hjälp av Azure Web Application Proxy kan vi nu publicera den som våra övriga applikationer och även integrera med eventuellt Office 365. Vilket kan se ut enligt följande för en användare

image

Ställer vi in flerfaktorkrav kan vi påtvinga en användare som inte ens har konfigurerat flerfaktor att tvingas konfigurera detta vid första anslutning till denna applikation. I detta fall rings användarens mobiltelefon upp och användaren bekräftar ägandeskapet av telefonen genom att bekräfta genom att trycka #

clip_image003clip_image005

I fortsättningen när applikationer startas visas följande:

clip_image006

Efter bekräftad autentiseringen startar applikationen:

clip_image001[1]

Precis som applikationen påvisar ser vi att användaren är autentiserad och detta hade kunnat vara vilken applikation som helst.

Är ni extra uppmärksammade så har ni även sett att URLen är densamma som den interna URLen ”intranet.domän.com” vilket gör att klienten kan fortsätta gå mot samma URL som den är van vid och sitter användaren internt på sin företagsdator fungerar det precis som vanligt. Om användaren där emot loggar in från Internet påtvingas användaren ange flerfaktorinloggning och alla (försök till) inloggning loggas i organisationens Azure portal.

Eftersom en video säger mer än tusen print screens, kommer här även en demonstration av lösningen:

 

Vad gäller då för att det här skall fungera?

Vi publicerar den med Azure Web Application Proxy och definierar namn och URL till vår interna applikation, i mitt fall namnet Local Intranet med URL https://intranet.domän.com

Lokal konfiguration

Det vi sedan får göra är att sätta upp minst två Application Proxy Connectorer (för redundans). Dessa installeras på domän medlemmar av det lokala Active Directoryt och det krävs att det härifrån går att internt surfa till den specifika siten.

Connectorn installeras från Azure portalen och kräver enbart utgående TLS krypterad trafik. Ingen inkommande trafik behöver definieras! Redan här kan vi se fördelarna med att publicera via Azure. I framtiden kanske vi inte har en enda regel som tillåter ingående trafik till vårat interna nät utan nyttjar den här typen av lösning.

För att få integrerad inloggning att fungera mot intern site används Kerberos Constrained Delegation (KCD) och därav behöver datorobjekten ha rätt att delegera kerberos biljetter till den specifika webservern. En kerberosbiljett krypteras med hjälp av ett konto som skall ha rätt att dekryptera biljetten, vilket i det här fallet är webbservern och detta definieras och utpekas av ett Service Principal Name (SPN)

Det vi behöver göra är att skapa ett SPN för namnet på siten och tilldela detta till datorobjektet för webbservern (vid lastbalansering används ofta ett service konto för webtjänsten och då är det servicekontot som skall tilldelas detta SPN)

I mitt fall blir mitt SPN http/intranet.domän.com och kommandot blir
setspn -S http/intranet.domän.com webservern
och webserverns SPN pekas sedan ut för delegering för datorobjekten

Autentiserad trafik från Azure portalen hämtas nu upp av connectorn som i sin tur skapar en kerberosbiljet. Biljetten krypteras så enbart webservern kan dekryptera denna och skickas sedan till webservern som verifierar inloggningen.

Azure konfiguration

I Azure kan vi sedan definiera en grupp över de som skall få tillgång till den här applikation där vi då också för möjlighet att delegera beslutet över vilka som skall ha tillgång till denna applikationen ner till verksamheten med hjälp av självbetjäningsportaler

Vi får sedan möjlighet att konfigurera vår site. Som standard kommer siten få en autogenererad adress baserat på vad du döpt sajten till.

clip_image007

Det här gör att siten kommer fungera över https där Azure ger ut ett certifikat med korrekt namn.

Extern DNS

För att få att tilldela ett eget domännamn behöver vi:
Bekräfta ägandeskapet av vår domän vilket genomförs via ett DNS entry och vi behöver även skapa ett CNAME som pekar på ovanstående adress

Tilldela Certifikat

Eftersom inte Microsoft kan ge ut ett certifikat för vårat eget domännamn har vi sedan möjlighet att importera ett eget web server certifikat. Vi kommer även framöver få information direkt från vår Azure portal över när vårat certifikat är på väg att gå ut, så vi kan förnya certifikatet i god tid innan.

Flerfaktorinloggning

Vi kan sedan komplettera vår publicering med flerfaktor. Vi kan begära flerfaktorinloggning för

  • All tillgång till applikationen
  • Enbart när man inte är ansluten från jobbet (via ett definierat subnät)
  • För en viss grupp av användare

Alternativt blockera tillgången helt om man inte ansluter från ett definierat nät.

Vi har nu gjort det möjligt att nå vår interna applikation från internet med en säker och kontrollerad anslutning och dessutom utan att behöva göra några som helt öppningar i vår lokala brandvägg för inkommande trafik!

Publicerat i Azure, WAP | Märkt | Lämna en kommentar

RMS Analyzer

Jag hade häromdagen en utmaning där jag skulle återuppliva en gammal labbmiljö baserat Windows Server 2008 R2 plattformen med AD RMS. En miljö som varit avstängd under en längre tid och hade därmed en hel del fel. För att snabba på felsökningen använde jag ett relativt nytt verktyg som analyserar både Azure RMS och AD RMS både som slutanvändare och administratör, RMS Analyzer!

image

Verktyget går igenom alla förutsättningar för att RMS skall fungera problemfritt och ger både resultat och åtgärdsförslag.

image

Min kollega Tom skrev tidigare i veckan ett riktigt bra blogginlägg om detta verktyg

 https://mssec.se/2015/04/14/rights-management-services-analyzer-tool-updated/

Publicerat i RMS | Märkt , | Lämna en kommentar

Autentisering i Azure

Ett av de svagaste sätten för att autentisera sig är att enbart använda sig av lösenord. Trots det är detta det vanligaste sättet vi använder för att nå både privata och kritiska arbetsrelaterade tjänster.

Med Azure Active Directory Premium får vi möjlighet att ”förlänga” det lokala AD till Azure för att sköta autentisering där, både för lokala tjänster och molntjänster.
Varför vill vi då flytta ut en så kritisk tjänst som autentisering till en molntjänst och hur skulle det kunna höja säkerheten?

Det finns många svar på den frågan och jag tänker med den här artikeln försöka beskriva några av dem.

Flerfaktorautentisering

image

För att komma runt den svaga autentiseringsformen lösenord används flerfaktorautentiseringsmetoder med den klassiska kombinationen; någonting som användarna vet (lösenordet) och någonting som användarna har.
För att göra det användarvänligt ser man till vad en användare oftast har med sig. till exempel sin mobiltelefon!
Här finns fler alternativ

  • OTP (One-Time-Password) via SMS
    (En kod skickas som SMS och användaren får ange denna kod för att komma vidare.
  • Uppringning
    Användarens mobiltelefon rings upp av en automatisk tjänst där man även kan skapa ett unikt meddelande, vilket både ökar användarvänligheten och säkerheten. Användaren blir uppmanad att trycka en tangent för att bekräfta autentiseringen.
  • OTP via app till mobiltelefon och/eller platta
    Azure AD har en autentiseringsapp som finns till de vanligaste plattformarna, iOS, Android och Windows.
  • Sekundär E-post
    Ett mail skickas till användarens angivna mailadress, där användaren får bekräfta ägandeskapet av E-postadressen genom att klicka på en länk.

I vissa scenarier kan det även vara en bra idé att kombinera två av de ovanstående. Exempelvis vid en lösenordsåterställning där användaren kan bekräfta att den innehar sin mobiltelefon, har tillgång till angiven e-postadress, kombinerat med unika frågor som bara användaren vet svaren på.
Återigen kravet på att nyttja något som användaren har och något som användaren vet, för att bekräfta en inloggning.

För att höja användarvänligheten och anpassa säkerhetsnivån efter känsligheten på den tjänst som autentiseringen går mot, anpassas detta. Ett exempel är att användaren slipper multifaktor när den loggar in från en enhet som organisationen känner till för de flesta tjänsterna och de mest kritiska kräver flerfaktorautentisering. På en främmande enhet är det vanligast att påtvinga flerfaktorautentisering mot alla verksamhetstjänster.

Övervakning/Larm

Då autentiseringstjänsten är en av de absolut mest kritiska tjänster vi har, är också en viktig del att kontrollera om de som ansluter mot tjänsten är legitima. Något som oftast saknas i lokalt publicerade tjänster!
Azuretjänsten validerar alla klienter som ansluter baserat på en mängd olika typer av data.

Sker inloggningar

  • från olika geografiska positioner under en orimlig tid, vilket tyder på att fler använder samma konto
  • med suspekta beteenden som fel lösenord, utan flerfaktor krav etc. som tyder på att en obehörig försöker logga in

Ansluter klienten från en

  • svartlistad IP som har varit känd från tidigare attacker
  • okänd källa, där det tyder på att en anonymiseringstjänst används.
  • möjligt infekterad enhet

Frågan är hur Azure kan ha koll på all denna fakta utan att ens kräva någon form av lokal agent på anslutna klienter?
Det finns en organisation inom Microsoft kallad ”Microsoft Cybercrime Center” vars uppgift är att identifiera ”Bad guys”. Det här arbetet utförs på många olika sätt. All data som samlas in från Microsofts antivirus, inbyggda skyddet (Smart Screen filtret) i Internet Explorer med mera analyseras bland annat här.

Med avancerade algoritmer identifieras var ifrån attacker och skadlig kod kommer ifrån. Förutom att bevismaterial skickas till myndigheter runt om i världen, används även denna data för att stötta Microsofts egna kunder. Uppgifterna används för identifiera möjliga hot mot din autentiseringstjänst i Azure. Det finns både rapporter och larm för att underrätta din organisation om att något pågår.

image

Var sker lösenordsautentiseringen?

Det finns idag två alternativ över var lösenordskontrollen sker

  1. Ha kvar lösenordsautentiseringen i ditt lokala Active Directory och komplettera med flerfaktorautentisering. Med hjälp av en ADFS-federation mellan lokalt AD och ditt Azure AD styrs lösenordskontrollen mot ditt lokala AD.
    Här är det viktigt att ha en pålitlig ADFS-lösning med redundans, då tjänsten blir extremt kritisk. Som det ser ut i skrivande stund behövs minst fyra servrar för att uppnå detta. Två ADFS servrar som frontas av två Web Application Proxy (WAP, ADFS front-end) servrar. Maskinerna skall även lastbalanseras, vilket genomförs bäst med en dedikerad hårdvara för lastbalansering.
  2. Synkronisera användarnas lösenord till ditt Azure AD för att ge möjlighet för användarna att autentisera sig med samma lösenord direkt mot Azure. En av fördelarna är att det inte ställer krav på lokal infrastruktur.
    En vanlig missuppfattning är att användarens lösenord finns läsbart i Azure, vilket INTE är fallet. Det är en avancerad krypteringsfunktion som dels använder den inbyggda hash-funktionen i det lokala AD (som gör att lösenorden inte ens är läsbara av det lokala ADt). Lösenordets hash kommer på nytt omvandlas till en ny hash som synkroniseras till Azure AD. Det här gör att Azure klarar av att autentisera användarens lösenord men kommer aldrig ha varken original lösenordet eller ens den lösenordshashen som används av det lokala ADt. Det här gör att även om någon skulle komma över den lösenordshash som finns i Azure skulle det aldrig gå att använda denna för att till exempel logga in mot lokala tjänster.
Publicerat i Azure | Märkt , , , | 3 kommentarer

Sessioner från TechX Azure

Det var fullsatt på TechX Azure som gick av stapeln för några veckor sedan på Microsofts huvudkontor i Akalla, Stockholm. Om du missade detta event eller helt enkelt inte fick plats i salen under min session om informationsskydd med Azure RMS, kommer här en andra chans.

Sessionen innehåller till största delen en demonstration av Azure RMS. Jag går igenom;
Styrkan i att använda mallar och gruppmedlemskap, för att enkelt kunna ge ut behörighet till information.
Styrkan i att kunna använda självbetjäningsportaler via Azure AD Premium för att överlåta ansvar från IT till rätt personer inom organisationen.
Styrkan att via mallar också kunna ta bort behörigheten till information, filer oavsett var de befinner sig och till tidigare maildialoger.

Demoscenariot är att Sheldon Cooper en framgångsrik forskare skall utbilda Penny i fysik och under en begränsad tid ge Penny tillgång till informationen

 

Kan även rekommendera fler inspelningar från TechX.

Bland annat min kollega Jörgen (@ccmexec) Nilsson visar hur Windows Intune höjer säkerheten genom att få kontroll på enheter som iOS, Android och Windows Phone –enheter

Maja och Joakim på Microsoft som går igenom Azure AD Premium

Alla tre ingår i licenssviten (EMS) Enterprise Mobility Suite… http://www.microsoft.com/sv-se/server-cloud/products/enterprise-mobility-suite/buy.aspx

Poppa popcorn och luta dig tillbaka i kontorsstolen, mycket nöje Ler

Publicerat i Microsoft Event, RMS | Lämna en kommentar

Inkludera externa användare i RMS-mallar

Tidigare har vi enbart kunna tilldela rättigheter för interna användare och grupper via RMS mallar. Det kan dock finnas behov av att skapa en mall inkluderande vissa externa användare från exempelvis samarbetspartners eller kunder. Tack vare Azure RMS har det blivit betydligt enklare att dela RMS skyddad information med en extern användare (till skillnad från AD RMS). Vi har nu även fått möjligheten att via Azure RMS mallar inkludera externa användare. 

Via Azure konsolen har vi enbart möjlighet att söka bland befintliga användare och grupper

image

Men med hjälp av PowerShell-kommandot Set-AadrmTemplateProperty går det att specificera en eller flera externa användare.
(Det är dock inte möjligt att lägga till en grupp från en extern domän av tekniska skäl!)

image

Efter genomfört PowerShell-kommando återvänder vi till vår Azure konsol och ser där att vi fått upp vår nya externa användare. Vi har även nu möjlighet att ändra användarens rättigheter via detta grafiska gränssnitt.image
Observera att PowerShell-kommandot ovan rensar eventuella befintliga användare och grupper från mallen. Används detta kommando startar man med att definiera externa användare för att sedan lägga till eventuella interna användare till samma mall.

Resultat av ovanstående Scenario

Vi har nu gjort det möjligt för ledningsgruppen att dela ledningsinformation skyddad med denna mall i alla dess former, som exempelvis Officedokument och krypterade epostmeddelanden med sin revisor. Revisorn har enbart möjlighet att granska informationen. Om man i framtiden väljer att avsluta samarbetet med denna revisor ändrar man mallen och tar bort revisorn. Efter detta kommer inte revisorn längre åt tidigare mottagna mail eller skyddade dokument oavsett var han sparat dessa.

image

Publicerat i RMS | Märkt | Lämna en kommentar

Efterlängtade RMS nyheter!

I natt annonserades en hel del nyheter från produktteamet för informationsskyddslösningen RMS. Det är tydligt att RMS är ett område där Microsoft satsar allt vad de har och lyssnar med stora öron efter vad kunderna efterfrågar.

Skräddarsydd hantering av mallar

Att skapa mallar över vilka rättigheter som skall gälla för olika användare eller grupper av användare förenklar för slutanvändaren och ligger till grund för automatisering av skydd. Ju större organisation och ju fler grupperingar inom en verksamhet desto fler mallar behövs. Ett tidigare problem har varit att alla inom samma organisation ser alla definierade mallar. Detta skapar förvirring men kan även resultera i misstag som att sätta fel behörighet på en fil.

Vi har nu fått möjligheten att sätta scoop på våra mallar för att specificera vilka användare/grupper som skall få tillgång till dessa mallar.

clip_image002

Fullständig dokumentation finns här Azure RMS Custom Templates documentation

Kontrollerad utrullning av Azure RMS

Ett återkommande problem för flera organisationer har varit att kontrollera sin utrullning vid själva införandet av RMS, då funktionaliteten gått ut till alla användare. Vi har nu möjligheten att styra baserat på gruppmedlemskap vilka som får/kan använda Azure RMS. Detta gör det både möjligt att köra en Proof of Concept (PoC) vid införande och även styra så enbart vissa delar inom organisationer kan använda RMS.

Som så mycket annat inom RMS konfigureras detta via PowerShell, och kommandot:
Set-AadrmOnboardingControlPolicy

Migreringsverktyg från AD RMS till Azure RMS

Det har nu lanserats verktyg för att förenkla övergången från en lokal AD RMS till Azure Rights Management. Med hjälp av dessa verktyg kan både befintliga mallar och även krypteringsnycklar överföras till Azure. Att få över nycklarna är något som är extremt viktigt om man tidigare nyttjat AD RMS och har befintlig krypterad information. Genom en överföring kommer alla befintligt skyddade filer nås som tidigare och inarbetade mallar finns på plats så användaren känner igen sig.

Mer info: Migrating from AD RMS to Azure Rights Management

Återkom gärna till oss på Onevinn för närmare rådgivning vid en sådan migrering.

Uppdaterad RMS App till Windows

Både Windows Phone och Windows (desktop) har fått en uppdaterad version av RMS Appen. De som använder AD RMS och har en konfigurad Mobile Device Extentsion har nu fullt stöd till Windows Phone. Appen för Windows Phone har även fått stöd för cachning för att kunna dekryptera information offline.

Mer info och hemladdning från Windows Phone store.

Appen till Windows (7, 8.1) har fått stöd för multipla epost domäner.

Release notes för Windows 8.1 release notes.

Publicerat i RMS | Lämna en kommentar

FCI RMS error 0x80045380

Server rollen File Classification Infrastructure (FCI) ingår i Windows Server 2008 R2 och framåt och precis som det låter används rollen för att klassificera information.

Att använda FCI för att med automatik klassificera vilken information som är känslig, och baserat på känsligheten applicera rätt RMS skydd på dokument som läggs på en filserver är det enklaste sättet att komma igång och skydda rätt information med automatik.

FCI hämtar mallar från RMS servern och vid användning av Azure RMS hämtas då dessa via en konfigurerad RMS connector.

Om FCI och dess File Managment Task redovisat error 0x80045380 betyder detta att konfigurerad mall inte motsvarar mallen på RMS servern. Det här uppstår exempelvis när du förändrat namnet på din RMS mall.

image

Det här löser man enkelt genom att starta om tjänsten File Server Resource Manager på aktuell filserver vilket då hämtar aktuella mallar från RMS tjänsten på nytt.

image

Efter omstart av denna tjänst fungerar lösningen som tänkt igen och felmeddelandet är borta.

Publicerat i RMS | Märkt | Lämna en kommentar

IT-Säkerhetsfokus på TechX Azure

image

Med några dagar kvar till Julafton är det nog inte många som funderar på vad som händer på arbetsfronten i januari. Det är nog med julstressen och att hålla sig uppdaterad på alla nyheter från Microsoft kommer säkerligen på efterkälken.

Men en perfekt start på nya året är att redan nu boka in sig för ett besök hos Microsoft den 28-29:e januari då TechX Azure går av stapeln. Två dagar med fullspäckat schema med tekniknyheter både för IT-proffs och utvecklare.

Både jag och min kollega Jörgen Nilsson kommer köra sessioner med IT-Säkerhetsfokus.

Jag kommer gå igenom hur man skyddar sin information och nyheterna i Azure Rights Manangement. Jörgen kommer gå igenom hur man hanterar alla telefoner, plattor med mera som ansluts till företagets tjänster. Hur man kan både ställa krav och begränsa informationsspridning från dessa via Windows Intune.

Sessionsbeskrivningarna ser ut enligt nedan och på TechX Azure kan ni läsa mer och anmäla er. Ses i januari Blinkar

Skydda din information med det senaste från Azure Rights Management

I stort sett varje verksamhet har idag känslig information utanför sin kontroll, både på anställdas privata enheter och framför allt olika molntjänster. Skydda din information och få spårbarhet oavsett var den sparas med Azure Rights Management. Anders berättar om det senaste inom Azure Rights Management och visar hur man automatiserar och förenklar för våra användare.

Hantera och skydda dina iOS-, Android- och Windows Phone-enheter med Microsoft Intune

I stort sett varje verksamhet har idag känslig information utanför sin kontroll, både på anställdas privata enheter och övriga enheter som man exempelvis synkar sin E-Post till via Office 365/Exchange. Under denna session fokuserar vi på hur man kan hantera moderna enheter, distribuera appar, hantera säkerhetsinställningar. Med andra ord får kontroll över sina enheter.

Publicerat i Microsoft Event | Märkt | Lämna en kommentar