I was running running klist on my machine I can see 2 (TGT?) tickets with: Server: krbtgt/DOMAIN.COM # DOMAIN.COM and KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
I understand RC4 is depreciated and all my other tickets are listed with AES256. Just not sure if this is cause for concern?
Does the krbtgt AD account just need to be reset? Is there a risk someone could dump the ticket with the hash and crack it?
Thx
I understand RC4 is depreciated and all my other tickets are listed with AES256. Just not sure if this is cause for concern?
Yes, it's possible that the current keys for the krbtgt principal were created very long ago, before your AD DCs had AES support (meaning there are no AES keys stored for it), and if newer Windows (or Linux Krb5) versions begin turning off RC4-HMAC support, those machines will become completely unable to authenticate.
Does the krbtgt AD account just need to be reset?
Yes, but preferably using the official tool (not by setting a password by hand).
Related
I want to implement kerberos authentication for a software where both the server and the clients run on Windows and are implemented in C++.
When both, the clients and the server are on the same Windows domain it is straight forward to use SSPI and I assume this will work also for cross-realm environments.
When for any reason the server cannot be member of the domain this straigth forward approach will not work.
How is it possible to achieve Kerberos authentiaction against a server that is not member of the domain?
If my research is correct java applications or linux use a keytab file instead of implicitly retrieving the key from AD. Apparently SSPI does not support keytab files. Is there a way to use keytab files in this scenario?
SSPI does not "retrieve the key from AD" – the service key is always stored locally, but with SSPI it's the machine account password which was generated during AD join process (and uploaded to AD rather than retrieved from) that acts in place of the keytab. Windows stores the machine password in LSA and derives the key from it in memory, but it has the same purpose as a keytab file.
There may be a way to store a machine password in a non-AD machine (using ksetup.exe), but it is very much a system-wide change – it seems to make certain parts of the Windows login process function as if the system was domain-joined – so I would not recommend doing so, except in a test VM.
Instead, you can use another Kerberos implementation – MIT Kerberos and Heimdal are the two major non-AD Kerberos implementations that come in the form of C libraries (both are Windows-compatible, though their focus is on Linux/Unix-like systems). Both libraries provide the GSSAPI interface, which is similar to Windows SSPI, and both use keytab files for service credentials.
For C#, Kerberos.NET is available. For Rust, sspi-rs seems to be in active development (it isn't just a binding to Windows SSPI but a standalone implementation as well). Java of course has its own Kerberos implementation built-in as part of JAAS although Apache Kerby exists as well.
Most of those implementations support the same keytab format because they mimic MIT Kerberos to some extent (which was the original Kerberos 5 implementation).
Both MIT Krb5 and Heimdal include not just a library but a KDC service as well, though that part won't run on Windows. (Kerby and Kerberos.NET could also be used to build minimal KDCs.)
The above is more important for servers; however, a client can use SSPI to authenticate to Kerberos services without any requirement to be a domain member.
For realms that are AD-based (regardless of the specific server being domain-joined or not), it is enough to provide a UPN-format username (in the form of user#domain) and a password to SSPI; it will automatically discover KDCs and obtain tickets.
The same works for Kerberos realms that are not AD-based as long as the realm is marked as a "MIT realm" either via registry or using ksetup /AddRealmFlags. (The principal user#REALM needs to be specified as username in this case.) Unlike the earlier mentioned case, this ksetup.exe usage seems to have no negative side effects.
Given a windows domain, and two win7 systems, how can I establish a user verified connection from the first computer to the second without prompting for the user to re-enter credentials.
A good summary of this is: A TCP connection, server-side, has no idea what user is originating the connection. How can implementing a TCP based program permit user validation.
Work around ideas:
- I could write a WMI provider and use the underlying WMI infrastructure to verify the user.
I'd prefer not to get a work-around, as I've been working around not really understanding how to authenticate over the network using Windows for many years. Please help me to understand how Windows is actually performing this step so that I can implement the technique. If the answer is kerberos some example code on how to generate/send something from the client (without prompting for credentials, just use the logged in user) that the server can process/validate.
I think this may have already been answered here: Windows authentication token C++
(Will need some time to implement/test before I will be sure.)
The magic answer I was looking for back then was SSPI (Kerberos). A similar solution exists with OpenSSL. For others looking for this you will also be interested in SSL, TLS (the new SSL), and SASL (a mechanism for deciding on the fly which identification algorithm to use) and it's Microsoft counterpart SSPI.
Is there any more securely way to protect and store a password than Windows DPAPI do?
My program needs to store a secret (something like credentials) to do automatic logins on Windows, and this secret have to be shared with other users accounts because the program can be run on different accounts but sharing the credentials.
I need to protect this secret from tampering to avoid an attacker to inject his own credentials and take the control. If the attacker has phisical access I know that there is nothing we can do, but.... currently, what is the best way to store and protect this secret?
If you want to secure something against tampering, you are probably better off with a multi-level approach. The drawback to this is that gaining access (even with all secrets) is an astronomical feat and will bump up your login time on this.
Keep in mind, however, that a system is only as secure as its weakest point; you can have a file in a hidden encrypted volume behind even more layers of custom encryption, but if you have the passwords on a post-it note by your desk at work, odds are that it wont be secure for long.
The same applies with security on windows. ACLs and encryption are only as strong as your administrators' accounts. For tips on security, try Server Fault.
As for the system itself, implementing public-key cryptography (asymmetric encryption) through keys or digital certificates somehow and giving every user their own individual keys/IDs is a much safer alternative with far fewer risks.
Windows has supported pubkey infrastructure since at least windows server 2000; you can even use a smartcard logon if you have the hardware for it.
Consider the following:
1. An attacker obtains a private key (with protection on it) from a user. This can be broken #2048bit in an hour or two on average hardware. With this example, you need only remove the public key of the user and have them re-generate a new key.
2. An attacker obtains a user's digital certificate, then you have two options:
1) Remove their certificate from the Active Directory store, ACL or other certificate store.
2) Issue a revocation on the certificate, and forceably expire it. This assumes your are acting as the certificate authority.
In short, this answer states one thing: If you are worried about password security that much, then you should not be using passwords. If you make your system take forever to break, then the alternative route is a botnet bruteforce of a password.
Im doing a little research about Windows password and I've a little question.
Windows encrypt user passwords and store them on: C:\WINDOWS\system32\config\SAM encrypting them by the NTLM algorithm (plus Syskey)
NTLM is also a network authentication protocols, so I'm messing up with this.
I would like to know if the NTLM encryption is the same of the NTLM network protocol. I mean, in Windows, when you type your user and password, if the system starts a network protocol on the same system (localhost), as it would if they were too different computers (ip).
Or otherwise, if they are two different things with the same name.
It would be great if someone could give me a little explanation about the difference of both methods.
Hope you can understand my question, as I'm not English!
Thanks in advance!
Disclaimer: I work for Microsoft, but not on Windows or any team that developed NTLM. This knowledge comes from external sources and thus may not be accurate.
NTLM is two things: a one-way hash algorithm and an authentication protocol.
The one-way hash function is what the Windows OS uses to store passwords (in the secrets file, as you note.) This is, of course, so that plaintext passwords need not be stored on disk. When you type your password on the login screen, it will be hashed with the NTLM hash algorithm and compared against the existing hash in the secrets file. If they match, you'll be authenticated. If not, you'll be prompted to enter your password again.
The authentication protocol is a challenge/response protocol that authenticates some on-the-wire protocol like CIFS or HTTP. The algorithm utilizes the aforementioned NTLM hash algorithms in order to build the responses to the server's challenges based on the password that the user typed. The protocol specification for the NTLM authentication protocol is available from Microsoft under their Open Specifications license.
To answer your question, when you log in to Windows, it's likely just using the NTLM hash and checking it against the on-disk file, not doing some network call. Of course, if your machine happened to be a domain controller (and, somehow, couldn't do Kerberos) then it may do NTLM authentication over the network to localhost, but that's a pretty contrived example. Of course, if you're hitting a network resource on that local machine (say, CIFS file sharing or hitting a web site) then you'll be using the network authentication protocol, not going directly to the secrets file.
NTLM is not a network protocol. It's an authentication protocol. They are totally separate things.
There's a pretty good discussion of NTLM here. Pay special attention to the fact that NTLM isn't used any longer (it's been replaced by Kerberos and NTLM2, both of which are defined and discussed in the linked article).
I want to encrypt passwords using the DPAPI like this
ProtectedData.Protect(plain, optionalEntropy, DataProtectionScope.CurrentUser);
and wonder if the domain administrator could decrypt the generated blob, as
Using Passwords Effectively states:
However, in a domain environment a
domain administrator can safely change
your password, and you'll still have
access to your encrypted files.
It seems like the domain administrator would have to decrypt the data (or rather, the encrypted master keys) first, in order to be able to re-encrypt it using a different password.
The answer is yes, provided he also has acces to the entropy key(if one is created), or if he is willing and capable enough to hack into the blobs (see links below).
For the Master key in DPAPI (in CurrentUser mode), the windows login username and password are used to generate the master key.
If the administrator updates the user's domain password, DPAPI wil reencode the master key for that user. The same goes if the user updates his password due to eg. a monthly password change policy.
However, if he doesn't have access to the optional entropy key or the data that composes that key, the file will remain encrypted and all he will get is invalid data.
If DPAPI is used in CurrentMachine mode, the file can only be decrypted on the computer that encrypted it, however the file will be readable to all accounts on that computer, again provided they can also muster the content of the entropy key.
A good repository for information is DPAPI Secrets and this paper on reverse-enginerring DPAPI + link to a tool that can recover data from DPAPI blobs
Short answer : he probably can't right out of the box, but Domain Admin is powerfull. There are many ways they can get to your key if they really want it.
Long answer : DPAPI encrypts your data with a key. IIRC, it uses AES with a key that changes every 90 days. The key is stored on your computer, encrypted with your password. That's the default and it saves your key out of reach of anyone but you.
Unless your domain admin remotely installs a key logger, steals your password, impersonnate you and steal your key (or go straight to the data which he now sees in plain text).
Another somewhat less known fact is that when Credential Roaming is enabled on Active Directory, it will send your encrypted keys to a server. A domain admin could use that copy for an offline attack. But it is hard and unless your data is very valuable, I woulnd't worry about it.
The answer is yes. PoC utility with description: Vulnerability of DPAPI data protection in Win2K, Win2K3, Windows Server 2008, and Windows Server 2012
Works in Win Server 2016/2019 as well.