Every developer from time to time experience such task in their career which makes a hell out of nothing. In my case, such task was to work with Active Directory for a bigger client which name I can’t reveal. Let’s name this client for our purposes: I. So, client I is just a big corporation which needs some simple system to be built. The thing is not what the app should really do, so it is not about a domain, the thing is about the infrastructure, the communication and what we should settle before starting work - how to cooperate with IdP.

And the thing I mean with “cooperate with IdP” is the way of how the authorization flow is solved in that project. It is actually based upon Active Directory instance, which is on-premises. The case is that .NET 5 does not have an actual support for it - there is no easy way of integrating it easily. What’s more, I asked some easy questions to answer me so I would know which options of those 3 mentioned, I shall consider, but… yes, I didn’t get the answer.

There are 3 straight forward ways to accomplish such integration.

The 1st one is the easiest - just use Windows Compatibility Package and connect the application server to the domain itself as a some user. Then, use PrincipalContext and UserPrincipal to cooperate with Active Directory. The only problem is that the application runs using an Logon session which is seen on the server as a user X. That means, that any action taken upon the PrincipalContext or via UserPrincipal or GroupPrincipal is actually executed using the X account so with its permissions. That either means that an app has too high or to low permissions to the domain controller what respectively follows on with:

  • the app not able to execute queries against an AD controller for data needed to operate properly,
  • the app can execute whatever is needed on AD controller, but it is an extreme security flaw, i.e. if an app won’t be properly tested against security breaches scenarios, then it can allow to fabricate such scenario that it will allow attacker to get into AD controller and escalate further in, for example: impersonation into other users. So it seems like there is no a good solution taking this option, aye? This is why I did the research and found out some more options.

The 2nd one can hardly be called a real solution to the integration scenario described above. It is because it involves bridging Azure Active Directory with Active Directory controller on-premises. Then we use AAD integration which Microsoft provides for .NET Core/.NET 5 and we get it all done. It seems easy, aye? And even it is allowed by client’s sysops - they have offered usage of AAD. But I consider this way as the last option to go with, as of the fact that bridging on-cloud service with AD controller which is inside a corporation network can be not performant enough. We have no real SLA for such solutions as we cannot really tell what will be the load on local AD setup. That’s because this AD setup takes care of not just PCs in the corporative network, they also take care of kiosks set up next to CNC machines. Even if we say that there are more than just one instance of AD, the network traffic for replication to AAD is from one AD node, not from all. So, we still get back to the start, where the local AD can be a real bottle neck during some “hot periods”.

The 3rd case is the most straight forward… just grab a plain, old Novell LDAP driver and wrap it up with some abstraction, register it to DI and… get to it. The most serious flaw of this approach is wrapping it up with custom abstraction. Somehow YAGNI and to add up more - KISS is not in place. It won’t be simple as we would like it to have so in a result we take into account maintaing more code than it supposingly should have. What’s more… writing custom abstraction layer doesn’t end well from perspective of a domain and the business. That’s because writing such layer using all good practices would be too costly, but on the other hand taking it low cost, costs us a bad architecture. And we all know how this scenario is going to end, aye?

So, having all that said, we can say that this is not difficult to be achieved, this is no rocket science at all. However, it is a difficult project taking a view from design and architecture perspecitve. To say more, communication is not the good side of this project too. And this is what worries me the most as I am writing this post just after a week from starting working with this client and it will not end earlier than after a few more months…

To sum it all up, it is not always about tech stack or difficulties in solving the problem itself. The problem somtimes lies in the communication when you don’t really know what business wants, sysops doesn’t cooperate, because of procedures slowing them down and you have to work on the project, because “development” phase has officially started.

Just wish me luck and stay tuned for more posts. Greetings!