Active Directory Web Services (ADWS) is a kind of SOAP interface (?) to AD listening on port 9389. It exists since W2k8r2. It's required for the Power Shell AD module to work for example. See: https://msdn.microsoft.com/en-us/library/dd303965.aspx https://technet.microsoft.com/en-us/library/dd391908%28v=ws.10%29.aspx The Samba AD server should support that also.
(In reply to Björn Jacke from comment #0) Just a heads up that I'm currently investigating this and have a proof-of-concept of receiving the decoded SOAP queries as plain XML (to be used by the server).
(In reply to Garming Sam from comment #1) Do you have the code somewhere? Do you have example capture you're able to share? My wireshark tree at https://git.samba.org/?p=metze/wireshark/wip.git;a=shortlog;h=refs/heads/ws-metze-current can dissect the first few layers including decrypting.
I'll post some more detail later, but I discovered a convenient set of Python libraries that someone wrote for a MiTM proxy (and inserted some GENSEC code myself): https://github.com/ernw/net.tcp-proxy https://github.com/ernw/python-wcfbin Protocol stack for the brave: TCP MC-NMFTB (MC-NMF TCP binding protocol) MC-NMF (.NET framing protocol) MS-NNS (.NET NegotiateStream protocol) [GSSAPI wrapping] MC-NBFX (.NET binary format) MC-NBFS (.NET binary format for SOAP) MC-NBFSE (.NET binary format extension for MC-NBFS for dictionary compression) [SOAP unwrapping] XML / SOAP (overview in MS-ADDM) belonging to one of the following: - MS-WSDS (Directory extensions to WS-Enumeration) - MS-WSPELD (LDAPv3 control support to WS-Transfer and WS-Enumeration) - MS-WSTIM (Directory extensions to WS-Transfer) - MS-ADCAP (Custom operations e.g. Change password) WS-Transfer appears to implement stateless CRUD operations while WS-Enumeration has a stateful enumeration context for pulling.
While I was googling around, I also found: https://github.com/tst2005googlecode/random-wireshark-dissectors/blob/master/nmf.lua I don't know if that's of any use to you or if you've seen it. One other thing I discovered is that you can dump the SOAP (more or less, you have to strip the outer XML wrapper and there's some additional internal threads it seems) by changing a config file on the ADWS server. https://blogs.msdn.microsoft.com/adpowershell/2009/10/05/how-to-view-soap-xml-messages-to-and-from-ad-webservices-and-powershell/
Successfully have AD Powershell commands accepting responses from our custom server. There's a lot of work to actually iron out all the details and actually polish the code, but Get-ADObject works on single objects and with a bit of fiddling with the server at runtime, we have Get-ADComputer successfully listing computers. Will post PoC code soon - currently implements bits of WS-Transfer (GET), WS-Enumeration. TODO: - Controls are ASN.1 encoded (and our Python bindings only handle string forms) - Map the remaining LDAP attributes and investigate synthetic attributes - Implementing Custom Actions One other thing that isn't clear from the specification is how long the SOAP dictionary is meant to last for compression. It's also unclear how the client is meant to transition between endpoints and what the expectations are of the server.
Haven't had any more time to investigate this. The primary thing this needs is testing. In particular, there are a number of quirks in the protocol and the Windows client that we need to verify: 1) Paging semantics vs LDAP paged_results semantics 2) Ordering of attributes and partial attribute set behaviour 3) Synthetic attribute behaviour (can it be triggered from Windows to begin with?) 4) Behaviour with multiple connections and endpoints 5) Mapping of attributes to the different syntax types 6) Dictionary behaviour across a session 7) Checking that our schema (extendedAttributeInfo and attributeTypes) are accepted by default. 8) General testing with add, delete and modify which we have yet to implement and ideally the most used custom actions. https://gitlab.com/catalyst-samba/samba-adws
Just one thing to note for any full implementation is that the Powershell expects to be able to connect to the ADWS with multiple connections. If you use a single threaded server, and hold the older connections, it will be unable to bind to multiple endpoints (without first breaking the connection). The current prototype still also has some issues with LMDB that we didn't investigate.
I strongly recommend *not* writing the server code in C due to the extremely complex parsing required. Rust, F#, C#, and Python would all be better choices. The .NET ecosystem might have some of the needed libraries already.