Active Directory Password Storage Specifics

  • 94 Views
  • Last Post 5 days ago
chaselton posted this 19 October 2017

Hello All, I’ve been asked for information about how Active Directory stores passwords; specifically, a) what encryption algorithm(s) are used to protect passwords at rest in the Active Directory database and b) are there any changes to said algorithms between 2012 R2 and 2016. I’ve found the following two links, one from the activedir.org site and the other from TechNet http://www.activedir.org/thread/how-passwords-are-stored-in-active-directory https://technet.microsoft.com/en-us/library/hh994558(v=ws.10).aspx   The first link is missing information about encryption for at rest passwords, while the second is written for Windows Server versions 2003 to 2008 R2.  Has anyone found documentation on AD password storage encryption algorithms (and relevant details) for Server 2012 R2 and 2016 that would answer the two questions above?   Thanks in advance, Cyd

Order By: Standard | Newest | Votes
chriss3 posted this 19 October 2017

RC4, DES+RID as salt, Windows Server 2016 as of TP4 RC4 was replaced with AES256 in CBC +0 protects NTOWF hashes in the DB. Documentation? Um no sorry, I might write a blog post on this. This is an old post where I explained how it works in Pre-Windows Server 2016 builds. https://social.technet.microsoft.com/Forums/office/en-US/5efae3ab-e899-4e02-b6c6-2a364eaa6fd7/what-encryption-used-for-password-in-active-directory-2003-and-how-we-can-check-and-view?forum=winserverDS   

show

a-ko posted this 19 October 2017

Any link on the changes in 2016?



That said, to add on to this—if someone compromises your DC you have bigger issues. So how the passwords are stored in that database are pretty much irrelevant, IMO.



The only reason password storage is a problem in open source tools (i.e. MySQL WebApp dumps) is because the applications themselves usually have full read-write privileges to the table where the passwords are stored. The passwords are managed by the application

itself, not by some external process.



However, that’s not quite how this works in Windows. A web application configured to authenticate against Active Directory isn’t setting the password (nor able to read the password)—and they’re typically only doing a simple LDAP bind to determine password validity.

 

Hopefully, as the future continues to be “Federate All The Things”, even application password dumps will be a thing of the past—as we’re now brokering authentication to 3rd parties via Federation, with no credentials stored locally

in the application. Authorization is still done within the application (usually), but that’s not as big of a deal as a password dump.

 

show

chriss3 posted this 19 October 2017

No there is no public documentation on this at all so far I know. The concept with the SYSKEY is pretty good but is available together with the DIT in almost all scenarios, backup, IFM etc, only exception is RODC IFM. I agree that going after the DB is not the most common why to obtain password hashes, if you own a DC you can get those online, however going after IFM, BACKUPs and Virtual Disks for DCs can sometimes be a way. Bonus: in ADAM/ADLS the SYSKEY is stored within the DB. 

show

barkills posted this 19 October 2017

That said, to add on to this—if someone compromises your DC you have bigger issues. So how the passwords are stored in that database are pretty much irrelevant, IMO.

[BA] Totally agree with you but …   There are various identity assurance standards which spell out how password credentials must be handled at rest to provide assurance to others about how trustworthy your identities are, and where FIPS was the minimum bar for an approved algorithm, RC4 didn’t meet those standards. There were ways to meet the standards like turning on bitlocker on the DC, but for existing deployed DCs w/o bitlocker that meant a full rebuild cycle. I helped with an analysis of AD for one such identity assurance standard here: https://spaces.internet2.edu/display/InCAssurance/InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+201404. During our analysis, we spoke with several Microsoft teams about the fact that RC4 was still in use for this critical protection—it was rather ridiculous.   That said, the real risks today are beyond at-rest password encryption.   So while I don’t think this matters from a practical point of view, I’m really happy to hear that Microsoft made a change. J

chaselton posted this 20 October 2017

Thanks Christoffer.  FYI, if you do write a blog post on this definitely post to the list.

 

This line from your email is a bit cryptic, even after reading your older post, could you elaborate?

           

RC4, DES+RID as salt, Windows Server 2016 as of TP4 RC4 was replaced with AES256 in CBC +0 protects NTOWF hashes in the DB.

 

 

 

Note: the first link in your older post is broken so here’s the updated one for reference:

https://msdn.microsoft.com/en-us/library/cc221063.aspx

 

 

 

 

 

show

chaselton posted this 20 October 2017

[BA] Totally agree with you but …



 

There are various identity assurance standards which spell out how password credentials must be handled at rest to provide assurance to others about how trustworthy your identities are, and where FIPS was

the minimum bar for an approved algorithm, RC4 didn’t meet those standards. There were ways to meet the standards like turning on bitlocker on the DC, but for existing deployed DCs w/o bitlocker that meant a full rebuild cycle. I helped with an analysis of

AD for one such identity assurance standard here:

https://spaces.internet2.edu/display/InCAssurance/InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+201404. During our analysis, we spoke with several Microsoft teams about the fact that RC4 was still in use for this critical protection—it

was rather ridiculous.


 

This is exactly why I posted my original question.

 

 

show

joe posted this 20 October 2017

Sadly, one of the overall conclusions here Cynthia is that if you need to attempt to defend AD against most of these identity assurance standards, it will be very difficult to succeed because AD's actual storage method is hard to defend. The security model is highly dependent on the fact that APIs to read the raw data are not readily available like they would be in a traditional database and the whole AD security model is predicated on limiting access to the physical data store.
You likely are not in a good position to just move to a different product either though so a "creative accommodation" may be required.
Good luck!
Joe K.


show

barkills posted this 20 October 2017

My recollection (and I don’t see any indication that this has changed) is that the best documentation on the mechanisms behind AD password storage were on 3rd party sites—the MS documentation was either

non-existent, incomplete, or misleading because you had to combine multiple sources which weren’t intended to be used that way. The best info was available from folks who had reverse-engineered it in the process of building tools to extract hashes from the

underlying AD data store.

 

Brian

 

show

michael1 posted this 20 October 2017

The problem is exacerbated because even those people outside of Microsoft who know the answers can’t say them because of the NDA associated with Source Code Access.

 

show

a-ko posted this 20 October 2017

Honestly, if this is for a compliance reason (say, NIST 800-171 requirements), then they’re going to be pretty lenient with you if you have compensating controls. You don’t necessarily NEED to know how it’s stored to pass compliance checks.

(I’ve built environments that have received US federal government ATOs). Unfortunately I understand how ambiguous some of the documentation is. Back in my former life (before I decided to exit the gov sector for a bit), I was working to try and join the NIST

documentation groups to try and help push for more clarity in these areas.

 

For example, in NIST 800-171, Section 3.5, Requirement 3.5.10, “Store and transmit only encrypted representations of passwords”. Technically speaking, AD’s usage of RC4 meets this requirement. What also meets this requirement is a reversibly-encrypted

plain-text password transmitted over TLS via SAML (as stupid as that sounds).

 

However, oddly enough, Microsoft’s LAPS tool does NOT meet the above requirement. As LAPS stores the passwords as plain-text in protected attributes on computer objects in AD.

 

However, if you use Bitlocker on the disk and LDAPS to retrieve the data, that would technically meet the same requirement (even if not exactly in the spirit of the requirement itself).

 

show

GuyTe posted this 5 weeks ago

 

There are 2 layers of encryptio:



  1. Each hash is encrypted using DES, while the RID of the security principal is used as salt for the encryption function (SystemFunction026 in AdvApi32.dll). The result is a partially

    encrypted hash. In the case of password history attributes, the partially encrypted hashes are concatenated into a single blob.
  2. The resultant blob is encrypted:



    1. Pre-W2K16. In this case RC4 is used






                                                   

i.     Generate random salt of 16 bytes



                                                  

ii.     RC4key = MD5(Pek, random salt)



                                                 

iii.     EncryptUsingRC4(partially encrypted blob, rc4key) (SystemFunction033 in AdvApi32.dll)





    1. W2K16 uses AES (this is the change Chritoffer is talking about)






                                                   

i.     Generate random salt of 16 bytes



                                                  

ii.     EncryptWithAES, while the salt is used as IV (initialization vector) and PEK as the encryption key

 

PEKList itself is stored in the DIT and is encrypted using SYSKEY. In the case of W2K16 the PEKList is encrypted using AES. For pre-W2K16 it is RC4.

 

When AES is used, it is used in CBC mode with zero-padding

è CBC +0

 

Guy

 

show

chaselton posted this 2 weeks ago

Revisiting this after being slammed with work for the past several weeks…apologies for the delay

Brian (and anyone else, of course):  Any chance you have links to 3rd party sites that you’d recommend, before I hit up Google?

 

show

chaselton posted this 2 weeks ago

Many thanks Guy.  This is very helpful.

 

show

joe posted this 2 weeks ago

Cynthia, the session that Guy and Michael just presented at the HIP Conference this week was phenomenal and has all the gory details of how this all works. It is actually quite a bit more complicated than I realized and I already realized there was a lot to it.
https://www.hipconf.com
I'm hoping that they'll be able to make that content available soon.
Joe K.


show

chaselton posted this 2 weeks ago

Joe,

That would be fantastic if they could make that available;  this looks like what I’ve been looking for.

 

show

chriss3 posted this 2 weeks ago

  • on that, awesome session 

    show

GuyTe posted this 5 days ago

We are planning to make the sessions/slide decks available, but it might take some time.

 

Cynthia, I’ll send you a copy directly.

 

Cheers,

Guy

 

show

SmitaCarneiro posted this 5 days ago

Guy,

 

All the sessions were really great. Looking forward to seeing the sessions posted online.

 



Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

www.itap.purdue.edu

 

 



 

show

kurtbuff posted this 5 days ago

That's very good news. Please announce here when done, pretty, pretty please?

It would be even better if there were videos, but I know that takes a
huge amount of effort and no little expense.

Kurt

show

darren posted this 5 days ago

We did video record every session, as far as I know. I am not quite sure yet, when they will be available, but I will post here when I figure it out.

Thanks,

Darren

show

Show More Posts
Close