New Public Preview: Azure AD Domain Services admin UX in the new Azure Portal – Enterprise Mobility and Security Blog


New Public Preview: Azure AD Domain Services admin UX in the new Azure Portal

Howdy folks,

I’m excited to announce the public preview of Azure AD Domain Services in the new Azure portal. You can now create new managed AD domains and perform administrative tasks like configuring secure LDAP using the Azure portal. If you follow the blog, you already know that Azure AD Domain Services is pretty cool. It provides managed domain services like domain join, group policy, LDAP, and Kerberos/NTLM authentication, all fully compatible with Windows Server Active Directory.

What might surprise you is that over 8000 (!!) customers are already using Azure AD Domain Services today!

And qith this new public preview, we’ve made it even easier to create a managed AD domain using our brand-new wizard experience. The wizard knits tasks like creating virtual networks, configuring group membership of the delegated administrator group, and enabling domain services into a simple, intuitive, step-by-step experience.

Getting started

Here’s how to get started with the new Azure portal experience:

  1. If Azure AD Domain Services is not enabled for your Azure directoryCreate a new managed domain using the new Azure portal.
  2. If you’ve already enabled Azure AD Domain Services for your Azure directoryContact us via email to migrate your existing managed AD domain to the new Azure portal. From there, you can administer your existing managed AD domain using the new Azure portal.

Note: This public preview release supports only classic Azure virtual networks. We don’t support Resource Manager-based virtual networks yet, but the team is hard at work making that happen and we hope to preview it soon!

We want to hear from you!

As always, your feedback is very important to us! Please share your comments, questions, or concerns on our discussion forum, send us an email at aaddsfb@microsoft.com, or simply comment below.

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

SPN-hacking: derfor er det så vigtigt, at dine servicekonti har ekstra stærke adgangskoder! | Version2


SPN-hacking: derfor er det så vigtigt, at dine servicekonti har ekstra stærke adgangskoder!

Servicekonti i Active Directory er ekstraordinært udsatte og sårbare overfor en bestemt type angreb, som ofte viser sig yderst effektivt til at opnå fulde administratorrettigheder i domænet. Man lykkes med det igen og igen under penetrationstest og intet afholder ondsindede angribere fra at gøre det samme.

Med en almindelig phishing mail og tilhørende simpel malware, eventuelt bare i form af et script, kan man i løbet af meget kort tid opnå Domain Admin rettigheder eller tilsvarende, med begrænset risiko for at blive opdaget. Den lidt nysgerrige interne bruger kan med lidt teknisk snilde gøre det samme.

Denne angrebsvektor har efter min mening slet ikke fået nok opmærksomhed, og helt nye værktøjer gør angrebet endnu lettere at gennemføre, hvorfor dette blogindlæg har fået prioritet over andre i bunken.

Yderligere er det noget, som man rent faktisk kan gøre noget ved, forholdsvis enkelt, og opnå væsentlige forbedringer af virksomhedens forsvarsmekanismer. Der er lavthængende frugter at plukke!

En lang historie kort

Med fare for at oversimplificere vil jeg i det følgende forsøge at abstrahere lidt fra teknikken og holde mig til de overordnede linjer.

Kort opsummeret, så kan enhver bruger i Active Directory (AD), efter indledende authentificering (1), spørge en Domain Controller (DC/KDC) hvilke tjenester (services) der findes hvor i miljøet (2). Herunder hvilke der er tilknyttet en brugerkonto og hvilke der er tilknyttet en computerkonto.

Brugerkonti relateret til Kerberos-tjenester har et såkaldt Service Principal Name (SPN) registreret i AD, der fungerer som et slags katalog over tilgængelige tjenester i domænet.

Efter at have lokaliseret en eller flere interessante servicekonti i AD, kan en angriber anmode en DC om adgang til en af disse tjenester, f.eks. Exchange eller SQL (3).

Derefter vil DCen udlevere en række autentificeringsoplysninger i en “service ticket” (TGS). Denne ticket (3) indeholder data, som kan udnyttes til at bryde servicekontoens adgangskode OFFLINE (4), dvs. uden man behøver “gætte” sig frem ved at spørge DCen igen og igen (brute force), hvilket jo oftest vil føre til låsning af kontoen.

Kerberos SPN Cracking

Normalt vil en klient efter modtagelse af en TGS gå til den server, der har tjenesten installeret (Y) og anmode om adgang til f.eks. SQL, men det er ikke strengt nødvendigt.

Man kan med andre ord “cracke” adgangskoden på kraftige maskiner, fuldstændig risikofrit, uden chance for at blive opdaget. I de fleste tilfælde har man oven i købet meget lang tid til det, da klassiske servicekonti kun sjældent skifter adgangskode.

Det skal siges, at årsagen basalt set ligger i måden Kerberos fungerer på og har som sådan intet med hverken Microsoft eller Active Directory at gøre.

Protokollen er simpelthen designet sådan – og det bedste man kan gøre for at beskytte sig, er at anvende stærke adgangskoder, dvs. meget lange, komplekse og tilfældige adgangskoder (se mere nedenfor).

Rent teknisk, så er en del (server-delen) af den “service ticket”, som DCen sender retur til klienten krypteret med NT-hash værdien af servicekontoens respektive adgangskode. I ovenstående tilfælde SQL serverens servicekonto. Både DC og server ventes at kende denne værdi og kan således anvende den som symmetrisk nøgle til krypteret kommunikation over netværket via klienten.

Alt hvad en angriber skal gøre, er at “gætte” eller bryde nøglen, f.eks. med brute force, maske- eller wordlist-angreb. Det kan man kun hvis adgangskoden ikke er stærk.

Jamen, vi bruger da stærke adgangskoder!?

De fleste IT-administratorer er højst sandsynligt klar over, at adgangskoder på servicekonti bør være ekstra stærke. Vi har i hvert fald sagt det til hinanden meget længe…

Vi er bevidste om, at servicekonti ofte har højere privilegier end almindelige brugere i domænet, i visse tilfælde “Domain Admin” rettigheder eller tilsvarende.

Men under de adgangskodeanalyser som vi jævnligt foretager for kunder, kan vi typisk bryde adgangskoder for 35-50% af servicekontiene i miljøet!

Det er lavt i forhold til almindelige brugere og administratorer, men tallet kunne rent faktisk være et garanteret 0% – uden voldsomt megen bøvl.

Så okay… Måske bruger du og dine kollegaer ekstra stærke adgangskoder til servicekonti, men ham der havde din stilling før dig, gjorde måske ikke.

Lidt historik om SPN-hacking

Personligt fik jeg denne angrebsvektor på lystavlen, da Tim Medin introducerede KerberoastDerbycon i september 2014.

Dengang var angrebet noget mere omstændigt at gennemføre end nu.

For at eksportere de nødvendige oplysninger til cracking, havde en angriber (eller pentester som mig selv) behov for Mimikatz (bare i almindelig user-mode) på maskinen, eventuelt eksekveret i PowerShell (Invoke-Mimikatz).

Alternativt kunne Wireshark, Microsoft Message Analyzer eller den indbyggede kommando NETSH anvendes, men den slags kræver lokale administratorrettigheder.

God gammeldag netværks-sniffing (“wire tapping”) var en anden mulighed – og sammen med lidt Python scripts kunne man med lidt møje og besvær trække de nødvendige data (KRB5TGS) ud af PCAP trace-filerme.

Herefter kunne man forsøge at cracke med en wordlist og Kerberoast, hvilket ikke var helt optimalt.

Selve crackingdelen har kunnet håndteres effektivt offline og med GPU-kraft siden en ændring til John the Ripper (KRB5TGS) i september 2015 og hashcat siden februar 2016.

Med en ændring i PowerSploit fra september 2016 kunne KRB5TGS eksporten klares i PowerShell, uden administrative rettigheder.

For kort tid siden har Will Schroeder (Harmj0y) – i øvrigt en fantastisk White Hat, som bl.a. også står bag fremragende værktøjer som Veil-Framework, BloodHound, Empire og PowerSploit – frigivet Invoke-Kerberoast.ps1, som gør eksporten af KRB5TGS nemt og mobilt.

Det hele er næsten for nemt nu!

Hvad gør vi så for at forsvare os?

Der er flere konkrete ting, som man kan gøre her og nu:

1) Få overblikket over de udsatte servicekonti

Der er heldigvis flere måder at få overblik over præcis hvilke brugerkonti, der er knyttet til tjenester i Active Directory, f.eks.:

2) Sørg for at alle servicekonti med SPN har ekstra stærke adgangskoder.

Det bør i de fleste tilfælde ikke være noget problem at vælge en adgangskode på mellem 25 og 127 karakterer. Det er blot et spørgsmål om en copy-paste operation eller to.

Meld alle servicekonti ind i én sikkerhedsgruppe og associér den med en Fine Grained Password Policy (FGPP) hvor adgangskodekravene er sat højt, f.eks. minimum 25 karakterer.

Skift herefter adgangskoderne for servicekonti med svage – eller ukendte – adgangskoder.

Der findes masser af scripts til at sikre høj adgangskodestyrke (længde, kompleksitet og tilfældighed), f.eks. New-SWRandomPassword.ps1.

PS> New-SWRandomPassword -MinPasswordLength 25 -MaxPasswordLength 127

3) Ryd op i ubrugte SPN registreringer

Når man nu går servicekonti igennem, kan man lige så godt slette SPN registreringer, som ikke længere anvendes med f.eks. setspn.exe.

4) Managed Service Accounts

Undersøg muligheden for at anvende (Group) Managed Service Accounts (MSA).

Desværre er det fortsat kun få tjenester der understøtter Managed Services Accounts, f.eks. IIS, SQL og AD LDS.

5) Udnyt computerkontienes adgangskoder i stedet

Undersøg muligheden for at omstille tjenester til at køre under en af systemets indbyggede kontekster.

Computerkonti har som standard stærke adgangskoder, som automatisk skifter hver 30. dag. De er praktisk talt ubrydelige med nuværende computerkraft og kryptografiske standarder.

Undgå dog at skifte til SYSTEM hvis tjenesten kan køre under en almindelig brugers rettigheder. Det sidste er at foretrække for at mindske risikoen i tilfælde af en sårbarhed i tjenesten, jf. punkt 7.

6) Analyser Event ID 4768 (Kerberos TGS Request)

Når en klient anmoder om en “service ticket” (TGS) oprettes en event på DCen. Hvis der kommer flere fra samme klient på forskellige tjenester inden for kort tid, så er det nok værd at undersøge (læs: SIEM).

7) Lås servicekonti ned til et absolut minimum af rettigheder

Alt for ofte får servicekonti tildelt for mange rettigheder og låses ikke tilstrækkeligt ned, med f.eks. “Deny interactive logon”, “Deny logon from the network” m.v.

Det kan betale sig at gå aktive servicekonti efter i sømmene og fjerne overflødige rettigheder, både lokalt og i AD.

Afslutning

Jeg håber, at nærværende indlæg kan inspirere til, at der strammes op omkring adgangskoder på servicekonti for Kerberos-registrerede tjenester rundt omkring i de danske datacentre.

God fornøjelse!

/Jakob

Referencer:

Does your logon hang after a password change on win 8.1 /2012 R2/win10? | Ask the Directory Services Team


Does your logon hang after a password change on win 8.1 /2012 R2/win10?

Hi, Linda Taylor here, Senior Escalation Engineer from the Directory Services team in the UK.

I have been working on this issue which seems to be affecting many of you globally on windows 8.1, 2012 R2 and windows 10, so I thought it would be a good idea to explain the issue and workarounds while we continue to work on a proper fix here.

The symptoms are such that after a password change, logon hangs forever on the welcome screen:

How annoying….

The underlying issue is a deadlock between several components including DPAPI and the redirector.

For full details or the issue, workarounds and related fixes check out my post on the ASKPFEPLAT blog here http://blogs.technet.com/b/askpfeplat/archive/2016/01/11/does-your-win-8-1-2012-r2-win10-logon-hang-after-a-password-change.aspx

This is now fixed in the following updates:

Windows 8.1, 2012 R2, 2012 install:

For Windows 10 TH2 build 1511 install:

I hope this helps,

Linda

Using Repadmin with ADLDS and Lingering objects | Ask the Directory Services Team


Using Repadmin with ADLDS and Lingering objects

Hi! Linda Taylor here from the UK Directory Services escalation team. This time on ADLDS, Repadmin, lingering objects and even PowerShell….

The other day a colleague was trying to remove a lingering object in ADLDS. He asked me about which repadmin syntax would work for ADLDS and it occurred to us both that all the documented examples we found for repadmin were only for AD DS.

So, here are some ADLDS specific examples of repadmin use.

For the purpose of this post I will be using 2 servers with ADLDS. Both servers belong to Root.contoso.com Domain and they replicate a partition called DC=Fabrikam.

    LDS1 runs ADLDS on port 50002.
    RootDC1 runs ADLDS on port 51995.

1. Who is replicating my partition?

If you have many servers in your replica set you may want to find out which ADLDS servers are replicating a specific partition. ….Yes! The AD PowerShell module works against ADLDS.

You just need to add the :port on the end of the servername.

One way to list which servers are replicating a specific application partition is to query the attribute msDs-MasteredBy on the respective partition. This attribute contains a list of NTDS server settings objects for the servers which replicate this partition.

You can do this with ADSIEDIT or ldp.exe or PowerShell or any other means.

Powershell Example: Use the Get-ADObject comandlet and I will target my command at localhost:51995.  (I am running this on RootDC1)

Notice there are 2 NTDS Settings objects returned and servername is recorded as ServerName$ADLDSInstanceName.

So this tells me that according to localhost:51995 , DC=Fabrikam partition is replicated between Server LDS1$instance1 and server ROOTDC1$instance1.

2. REPADMIN for ADLDS

Generic rules and Tips:

  • For most commands the golden rule is to simply use the port inside the DSA_NAME or DSA_LIST parameters like lds1:50002 or lds1.contoso.com:50002. That’s it!

For example:

  • There are some things which do not apply to ADLDS. That is anything which involves FSMO’s like PDC and RID which ADLDS does not have or Global Catalog – again no such thing in ADLDS.
  • A very useful switch for ADLDS is the /homeserver switch:

Usually by default repadmin assumes you are working with AD and will use the locator or attempt to connect to local server on port 389 if this fails. However, for ADLDS the /Homeserver switch allows you to specify an ADLDS server:port.

For example, If you want to get replication status for all ADLDS servers in a configuration set (like for AD you would run repadmin /showrepl * /csv), for ADLDS you can run the following:

Repadmin /showrepl /homeserver:localhost:50002 * /csv >out.csv

Then you can open the OUT.CSV using something like Excel or even notepad and view a nice summary of the replication status for all servers. You can then sort this and chop it around to your liking.

The below explanation of HOMESERVER is taken from repadmin /listhelp output:

If the DSA_LIST argument is a resolvable server name (such as a DNS or WINS name) this will be used as the homeserver. If a non-resolvable parameter is used for the DSA_LIST, repadmin will use the locator to find a server to be used as the homeserver. If the locator does not find a server, repadmin will try the local box (port 389).

The /homeserver:[dns name] option is available to explicitly control home server selection.

This is especially useful when there are more than one forest or configuration set possible. For

example, the DSA_LIST command “fsmo_istg:site1” would target the locally joined domain’s directory, so to target an AD/LDS instance, /homeserver:adldsinstance:50000 could be used to resolve the fsmo_istg to site1 defined in the ADAM configuration set on adldsinstance:50000 instead of the fsmo_istg to site1 defined in the locally joined domain.

Finally, a particular gotcha that can send you in the wrong troubleshooting direction is a LDAP 0x51 “server down” error which is returned if you forget to add the DSA_NAME and/or port to your repadmin command. Like this:


3. Lingering objects in ADLDS

Just like in AD, you can get lingering objects in AD LDS .The only difference being that there is no Global Catalog in ADLDS, and thus no lingering objects are possible in a Read Only partition.

EVENT ID 1988 or 2042:

If you bring an outdated instance (past TSL) back online In ADLDS you may see event 1988 as per http://support.microsoft.com/kb/870695/EN-US “Outdated Active Directory objects generate event ID 1988”.

On WS 2012 R2 you will see event 2042 telling you that it has been over TombStoneLifetime since you last replicated so replication is disabled.

What to do next?

First you want to check for lingering objects and remove if necessary.

1. To check for lingering objects you can use repadmin /removelingeringobjects with the /advisory_mode

My colleague Ian Farr or “Posh chap” as we call him, recently worked with a customer on such a case and put together a great PowerShell blog with a One-Liner for detecting and removing lingering objects from ADLDS with PowerShell. Check it out here:

http://blogs.technet.com/b/poshchap/archive/2014/05/09/one-liner-collect-ad-lds-lingering-object-advisory-mode-1946-events.aspx

Example event 1946:

2.  Once you have detected any lingering objects and you have made a decision that you need to remove them, you can remove them using the same repadmin command as in Iain’s blog but without the advisory_mode.

Example command to remove lingering objects:

Repadmin /removelingeringobjects lds1:50002 8fc92fdd-e5ec-45fb-b7d3-120f9f9f192 DC=Fabrikam

Where Lds1:50002 is the LDS instance and port where to remove lingering objects

8fc92fdd-e5ec-45fb-b7d3-120f9f9f192 is DSA guid of a good LDS server/instance

DC=Fabrikam is the partition where to remove lingering objects

For each lingering object removed you will see event 1945.

You can use Iain’s one-liner again to get a list of all the objects which were removed.

As a good practice you should also do the lingering object checks for the Configuration partition.

Once all lingering objects are removed replication can be re-enabled again and you can go down the pub…(maybe).

I hope this is useful.

Linda.