antiduh
Authentication with AZURE AD fails
Hello, nsspi works fine for domain joined user / machines. Recently our company has switched to AZURE AD. All PCs are now 'AzureAdJoined' and all user are now managed. With this configuration authentication doesn't work anymore. TestServer always fails with LogonDenied (0x8009030c). How can this be solved? Thank you.
I'm a little out of my element, because I have no idea how Microsoft built authentication in Azure, but I'm seeing some bits that suggest Azure doesn't work with SSPI. But I can't confirm that completely yet.
It looks like you're meant to authentication using libraries specific to Azure AD:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-libraries
"The Azure Active Directory Authentication Library (ADAL) v1.0 enables application developers to authenticate users to cloud or on-premises Active Directory (AD), and obtain tokens for securing API calls."
This project seems to have some hints: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-dotnet-webapi
I made some changes to work with AAD. I also had to implement a negotiated Bind.
BTW, there's a bug somewhere regarding encryption. I have a serialized request which is 419 bytes for length. It encryps fine but decryption fails with a message corrupt error. Would a length of 419 be hitting some boundary somewhere? Have you run into anything like this before? I hit this on about 1 out of 500K requests.
hambonewa: Sorry but I don't see any code for a negotiated Bind. I've compared with the original version and it seems that the major difference is encryption and decryption where the buffer is assembled / decomposed differently. Which parts are relevant for working with AAD? With the original version of NSspi I've not yet seen any problems regarding decryption even if length of cipherText is 419. (but I've only tried sending some messages)
Work with AAD: In the meantime I think using SSP methods for managed user (AAD without on-premises AD) is not possible (AAD with on-premises AD should work with the current Nsspi) and another provider has to be used. But it would be nice to have a library which could handle both AD- and AAD-user (without on-premises AD).
Tom8421, if you want some help, email me at [email protected] and it will be much easier.
The issue I had above was because the underlying Win32 library is not thread safe. I thought only encrypting a message needed to be within a lock but both encrypt and decrypt need to be within a lock. I'll repost the corrected code after I finish testing.