Add DirectoryServices tests

[karelz]

DirectoryServices has been ported without any test cases (see #14734). The tests require client-server setup (server running on Windows "Desktop" .NET Framework), which we do not support in our CI/test infrastructure.
Moreover the AD test server cannot run as public-internet-facing Azure server for the tests (it is not recommended by AD server team) :(

Idea: Create schema for adding tests, which will run only manually. Write the tests in such way that once we have client-server setup in CI/test infra, it will be easy to wrap them/migrate them into that structure.

Execution plan

1. Write a single typical-ish simplest DirectorySevices test.
   • The test will run against external AD test server (which can run locally or on another machine).
   • The test can be run only manually, not part of CI. Via special command line script.
   • Note: The test should also pass on full .NET Framework
2. Create client-server mini-infra for DirectoryServices tests.
   • Create simple unified way to propagate into the test information about the IP/port info of the external AD test server.
   • Enable running those tests manually, until we figure out how to enable client-server tests in CI/Helix test infra.
   • Note: The tests should be runnable also on full .NET Framework
   • Bonus: Make the mini-infra usable also for WCF tests which need Desktop-based WCF server (consider leveraging & partnering with existing WCF test suite - @zhenlan) and Networking tests which need sometimes client/server pieces of their test, currently depending on localhost (@karelz can ping the right experts on his Networking v-team)
3. Add more tests based on example from [1] and using DirectoryServices mini-infra [2]
   • This will allow us to run all DirectoryServices tests manually.

@tquerec @jay98014 can you please help us /guide us to create [1]. How to install AD test server locally / in a VM? Can you give us one Desktop test for DirectoryServices as example?
We should be able to make progress on [2] and [3] without your direct help.

[karelz]

@WinCPP was interested to help, esp. by end of July. [1] and [2] should be prep work earlier.

[WinCPP]

Thanks @karelz for looping me onto this. I am still going through #14734 , a lot of threads there... But as a start, I think I need to have an AD setup on my local machine to simulate the reconfigurable client-server setup? I enabled virtualization on my Win10 pro box, activated hyper-V. But then I realized I need to have a Windows installer... 😄 Am I on correct path...?

[hughbe]

I'm looking in to writing some unit style tests for System.DirectoryServices.Protocols (I don't think this should clash with your work).
I created the branch https://github.com/hughbe/corefx/tree/protocols-add-test-proj but when I run msbuild /T:BuildAndTest /P:Coverage=true, I get:

Committing...
No results, this could be for a number of reasons. The most common reasons are:

1. missing PDBs for the assemblies that match the filter please review the
   output file and refer to the Usage guide (Usage.rtf) about filters.
2. the profiler may not be registered correctly, please refer to the Usage
   guide and the -register switch.

Does anyone know why this happens?

[danmoseley]

@hughbe it's for reason 3. :) there is no coverage matching the -filter:"+[System.DirectoryServices.Protocols]*" (I see this when I opened the file C:\git\corefx\bin/Windows_NT.AnyCPU.Debug/System.DirectoryServices.Protocols.Tests/netstandard//RunTests.cmd)

I added var x= new System.DirectoryServices.Protocols.AddRequest(); and it says I have 0.3% coverage when I open up file:///C:/git/corefx/bin/tests/coverage/index.htm.

[hughbe]

I guess that makes sense - was thrown off by the missing PDBs stuff, thought it was a configuration issue. Cheers!

[tquerec]

There are a number of different options available for LDAP servers.

Active Directory - Available only as a windows server role
Active Directory Lightweight Directory Services - Available on Windows Server and as an optional feature on Windows client
3rd party LDAP stores - There are a number of open and closed source LDAP directories available. These include servers like SAMBA, Open LDAP, etc.

Each of the namespaces in S.DS.* has different directory server requirements.

S.DS -Requires any LDAP v3 compliant server.
S.DS.P - Requires any LDAP v3 compliant server.
S.DS.AM - Requires a Microsoft LDAP server, This could be Active Directory or AD LDS
S.DS.AD - Requires Active Directory

As long as we keep the configuration out of the code we should be able to write generic tests for S.DS and S.DS.P which work against any server type.

Starting with AD LDS or Open LDAP is probably the easiest route unless you already have a Windows Server license.

To install AD LDS on Windows 10 client

1. Open the Windows Features control panel
2. Check "Active Directory Lightweight Directory Services"
3. Select Ok
4. The AD LDS wizard will now be installed This MSDN link gives an overview on how to answer the wizard questions.

[hughbe]

@tquerec I'm trying to find "Active Directory Lightweight Directory Services" but can't seem to find anything in the panel

http://imgur.com/a/4xBse

[willdean]

@hughbe It's perhaps no help to you other than to save you wasting more time scrolling up and down, but this is what it looks like here: (Windows 10 Pro 10.0.14393)

Are you using Pro or Home?

[hughbe]

I don't get that unfortunately... I have home edition

[pasikarkkainen]

Hmm.. so what's the status here? Is anyone currently working on the DirectoryServices tests ?

[WinCPP]

@karelz I think I can start on this now. To start with I have created an instance of AD LDS on my Win 10 Pro machine at home as mentioned by @tquerec in one of the previous posts. From here, I think there are two things to be done predominantly - write tests using local instance and then wrap up whole thing using scripts to setup and tear down the instances (may be per build job run), including execution of the test cases. But I think for second to be done, basic tests need to be in place... Hope I'm thinking in right direction. The second part itself being an area of its own - automation infra as already discussed in this thread...

So if I were to do some quick stuff for part 1 i.e. creating test cases, can someone please point me to the API set that I can use to begin with. Or if I need to do something else, please let me know. I'll make them generic enough in terms of the server and instance to be used, as mentioned in this thread.

I think do I sound as if I've suddenly woken out of sleep 😄 ?

[karelz]

@tarekgh started working on it recently - he just forgot to assign it to himself ... @tarekgh can you use help from @WinCPP?

[karelz]

@tarekgh is it done? Can you please assign it to yourself and update appropriately? Thanks!

[tarekgh]

assigned it to me.

[WinCPP]

Relocating my query from the merged PR dotnet/corefx#24533 to this thread...

---

Hi @tarekgh,

I have got ADLDS instance installed on my Windows 10 desktop. I am trying to get correct configuration of the same. I have edited the configuration.xml. But with this the tests are failing. Is this correct config? Please note that my home PC is a Windows 10 machine in work group; essentially no domain. Appreciate your inputs and if there are some steps to get this working on a desktop. (Background: as we discussed on the PR, I wanted to get tests running on my local machine before starting to contribute. But since OpenDJ is asking for signing up with company name, etc. I switched over to ADLDS).

localhost 389 cn=Directory Manager password ServerBind,None Also are there any specific steps to create a particularly named instance using ADSI Edit?

Thanks,
Mandar

[tarekgh]

@WinCPP I I believe you have to have a Windows Server installed with Active Directory. ADLDS you have installed on the client is just to manage the AD on the server.
If you cannot install a Windows Server with Active Directory, then OpenDJ would be the other way to install it on the Windows client.

CC @tquerec who is the expert here and can advise better regarding the needed configuration.

[WinCPP]

Just to give background about what I have done... I installed ADLDS on Windows 10 as per discussion in this thread (ref. this comment). I think that has resulted into installation of active directory (lightweight) on my windows 10 machine; please refer to the image towards end of this comment.

Between OpenDJ is proving to be a problem because it asks me to register to be able to download OpenDJ and that registration requires Company name. I tried with company name as "home" (can't give my real employer's name ... legal restrictions) and I never got the email to confirm my account with ForgeRock!!! So kind of stuck...

[tarekgh]

I didn't try this scenario but you may try the following configuration and let me know what you'll get:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <ServerName>localhost</ServerName>
    <Domain>o=dotnetfoundation</Domain>
    <Port>389</Port>
    <User>Directory Manager</User>
    <Password>password</Password>
    <AuthenticationTypes>ServerBind,None</AuthenticationTypes>
</Configuration>

does "Directory Manager" is your admin user account on your machine? if it is not, please try to use your admin user-name and password.
Also, note that I didn't use cn= part in the user's name as this was required for OpenDJ but not for Windows connection

[tarekgh]

forgot to mention, I'll try your scenario too early next week too to ensure this work.

[tarekgh]

@WinCPP I have installed LDS and tried it. what you need to do is use the configuration

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <ServerName>localhost</ServerName>
    <Domain>o=dotnetfoundation</Domain>
    <Port>389</Port>
    <User>Directory Manager</User>
    <Password>password</Password>
    <AuthenticationTypes>Secure</AuthenticationTypes>
</Configuration>

note that, the user and password should be your machine user account which installed LDS. Also, the domain value "o=dotnetfoundation" should be the DN you used to create a partition when installing LDS. AuthenticationTypes has to be Secure.

After that, you'll be able to bind to LDS but some tests will still fail. the reason is the schema used in LDS is different than the schema in the AD servers. one example is, the organizionalRole class is not defined at all on LDS. to fix that, either we try to import such schema data from the server or we fix the test to use classes defined in both LDS and AD server (and LDAP services).

Is this something can be interesting to you to look at? Please let me know, otherwise, I'll try to look at this issue later and fix it. Thank you.

[WinCPP]

@tarekgh Thank you. I will try this out to have the local setup working with LDS. After that I am interested in fixing the test classes to make it work with LDS and AD Server as you mentioned above.

[WinCPP]

Hi @tarekgh I got the tests working on my AD LDS setup with the credentials related changes that you mentioned. Just like you mentioned, the tests that make use of "OrganizationalRole" class are failing. I searched the internet to get the ldif files for OrganizationalRole, but looks like I will not find them, probably because they are proprietary...? Don't know. Also I don't have AD Server setup as my machine at home is not server class. So not sure how to proceed.

Between, ADLDS appears to have "Roles" container at the "Organization" level and same are not supported at "Organizational Unit" levels. So are we alternatively looking to make the tests work with ADLDS by having function overloads depending on the Active Directory installation type?

[tarekgh]

@WinCPP thank you for looking at this issue.

It is better we look for the classes which are common between the server and LDS schema. and then we can update the tests to use these classes instead. we need to ensure. can you do this search? I may be able to help in that early next week too if you get stuck.

[tarekgh]

https://github.com/dotnet/core-eng/issues/2096

[tarekgh]

@WinCPP I am closing this issue as we already added the needed tests. feel free to open a new issue to track support running the tests against LDS. Thank you.