The two biggest holes I have encountered in the .Net libraries are probably NTFS file access and user authentication. I fully appreciate that shifting from a Win32 API to a new API (in this case .Net) is a "huge" task and hopefully these two aspects are coming...
In the meantime I have a question about what would be a good way to handle non-repudiability in an Active Directory environment.
The System.Security.Principal.WindowsIdentity class lets me know the authenticated user is and the System.Net.NetworkCredential class even lets me make use of the authenticated user's credentials when using IIS. But what if the application needs to digitally sign a SOAP request or do some other cryptographic type operation on behalf of a user?
I got a little bit excited with the release of WSE2 when I saw the multitude of classes and support available for digital signatures. However after playing around with it a bit I found that the classes to create security tokens from an XML signature, or similar, were all inaccessible and could only be used by way of an IIS SOAP extension, thus allowing only very narrow usage scenarios.
I appreciate that using the Win32 API it is possible to serialise Windows security tokens but this is a task that would take weeks to month(s) rather then the day(s) that we, as .Net developers, are now expected to operate under.
The ability to utilise single sign on and at the same time leverage distributed computing paradigms such as web services and remoting all require user authentication. Not having a managed API is a major, major disadvantage to being able to utilise one of the most basic services of a Windows environment!