joeware - never stop exploring... :)

http://www.joeware.net/freetools/tools/rdp-sec-check

Story

There was an issue where I needed to be able to ascertain whether or not a terminal server was listening for RDP and actually functioning properly. The main advice out there was to use portqry which simply told you whether or not the TCP port was listening or Telnet which wasn’t very clean or actually trying to connect with an RDP client. None of those were very good for my purposes, to script some tests to truly validate that RDP (and by extension the network between the test machine and the tested machine) was working.

As I searched I finally ran into rdp_sec_check on the Portcullis Labs website (http://labs.portcullis.co.uk/application/rdp-sec-check/) based on the MSFT RDP documentation (http://msdn.microsoft.com/en-us/library/cc240445.aspx) and after a few quick tests I realized it was what I needed for my testing, it just required a little tweaking to be a little more aligned with what I wanted and the goal was to tweak as little as possible for my needs.

The script is perl script which is popular in the Windows world but not so popular that I am guaranteed it is everywhere. Additionally, since the script depended on an additional module from CPAN to be loaded I decided to embed the perl script into an EXE with the CPAN module so it was a single simple EXE for folks to use. I expect that will greatly expand the number of admins who will be able to use it. If you like, since the original script was GPLv2, the source is included in the ZIP file so you can run the perl script directly if you prefer.

After I had finished my mods the Windows utility qwinst was brought to my attention by @ldap389. This is a good tool for checking the RDP service with considerably functionality but it requires perms to run against servers. This utility does not require any rights.

I want to say a HUGE THANKS to Mark Lowe and Portcullis Security (@portcullis) for making this available. Otherwise it would have required writing something based off of the RDP documentation mentioned above. After testing this and getting feedback, it is possible I may still do that and write the code in C++. Time will tell, if this serves the needs in a good enough fashion, I will leave it as is.

Finally, it should be obvious at this point, but this is not a normal joeware utility. I don’t usually do this but it was the most feasible solution at the moment and figured I would share once I saw the dearth of available tools for my Windows Admin friends. As such, this tool will look and "feel" different from my other tools. You will be fine. 🙂

  joe

I was pinged today by a coworker who was trying to track down password change audit entries that looked something like:

Event Type:        Success Audit
Event Source:    Security
Event Category:                Account Management
Event ID:              628
Date:                     1/14/2013
Time:                     2:52:32 PM
User:                     NT AUTHORITY\SYSTEM
Computer:         DCNAME
Description:
User Account password set:
               Target Account Name:   USERID
               Target Domain: DOMAIN
               Target Account ID:           DOMAIN\USERID
               Caller User Name:           DCNAME$
               Caller Domain:   DOMAIN
               Caller Logon ID:                (0x0,0x3E7)

And he was hoping I could tell him "who" was doing it based on the Caller Logon ID. I figured I would just send him a link explaining what the caller logon ID was and that in this case it wasn’t going to give him any info but I couldn’t find any good links out on the web talking about what the Caller Logon ID value even is. I saw a lot of questions around it and a lot of people completely ignoring the question so I responded to him and decided I should write a quick blog entry on how to sort this out.

The Caller Logon ID in the event log is basically a logon session ID on the local computer. This will allow you to chase down the user SID, authentication package, logon type, logon server, and when the user logged on and if you are really interested, the processes running in that logon session.  This information can be extracted with some pretty simple code using

http://msdn.microsoft.com/en-us/subscriptions/aa375400(v=vs.85).aspx

and

http://msdn.microsoft.com/en-us/subscriptions/aa379437(v=vs.85).aspx

Or you could simply download logonsessions from sysinternals to do the work for you!

http://technet.microsoft.com/en-us/sysinternals/bb896769.aspx

Running it will show you all of your logon sessions.

As to why that doesn’t help us here is that I happen to recognize the logon session ID of 0x0,0x3E7 because that, to my knowledge, has always been the first logon session (Session ID 0 if you enable viewing of Session IDs in TaskMan) which belongs to the local computer. So that just further tells you that it really is LocalSystem (NT AUTHORITY\SYSTEM) that is the ID that is making the change. Now if you want you can tell logonsessions to dump the processes running under the logon session with -p but that usually isn’t all that useful for that session because you will often see a bunch of svchost processes which really doesn’t help.

For example:

[0] Logon session 00000000:000003e7:
    User name:    WORKGROUP\JOELT17$
    Auth package: NTLM
    Logon type:   (none)
    Session:      0
    Sid:          S-1-5-18
    Logon time:   1/13/2013 10:56:30 PM
    Logon server:
    DNS Domain:
    UPN:
      296: smss.exe
      480: csrss.exe
      520: wininit.exe
      540: csrss.exe
      584: winlogon.exe
      628: services.exe
      644: lsass.exe
      652: lsm.exe
      756: svchost.exe
      984: svchost.exe
     1020: svchost.exe
      340: stacsv64.exe
     1056: svchost.exe
     1308: DisplayLinkManager.exe
     1540: DisplayLinkUserAgent.exe
     1572: wlanext.exe
     1596: conhost.exe
     1648: spoolsv.exe
     1852: armsvc.exe
     1928: AESTSr64.exe
     1960: AppleMobileDeviceService.exe
     2020: mDNSResponder.exe
     2040: btwdins.exe
     1188: EvtEng.exe
     1832: InstallFilterService.exe
     1212: LMS.exe
     2192: mysqld.exe
     2248: o2flash.exe
     2308: PMBDeviceInfoProvider.exe
     2456: RegSrvc.exe
     2544: SeaPort.exe
     2708: sqlwriter.exe
     2812: WLIDSVC.EXE
     3304: WLIDSVCM.EXE
     3352: unsecapp.exe
     3736: WmiPrvSE.exe
     4500: SearchIndexer.exe
      700: iPodService.exe
     4088: svchost.exe
     4876: svchost.exe
     5068: dllhost.exe
     5432: inetinfo.exe
     3384: SearchFilterHost.exe

Hopefully this helps folks out. 🙂

   joe

So I previously http://blog.joeware.net/2012/12/13/2650/ pointed out an article talking about AD Support in Samba 4.0. Upon further reading around on the Samba Wiki, white papers, and release notes etc, the article appears to be a little over generous on the functionality.

One thing specifically that I was shocked to read is this

In addition, the new version offers full interoperability with Microsoft Active Directory servers. A Samba 4 server can be joined to an existing Active Directory domain, and Microsoft Active Directory Domain Controllers can join a Samba 4 server.

which is directly contradicted by the Samba 4.0 Whitepaper at http://wiki.samba.org/index.php/Samba_4.0_Whitepaper

Active Directory Compatible Server

Samba 4.0 for the first time features an Active Directory Compatible Domain Controller.

The one setup as Active Directory Compatible Server supported out of the box with Samba 4.0 is this:

• There is only a single domain in the forest.
• There are no cross-forest-trusts (more explicitly, samba can be trusted but can not trust)
• Samba is the only domain controller in its domain.

These limitations are being worked on and will be removed in later 4.X releases.

The support for multiple domain controllers in a domain requires to flavours of replication:

• directory replication (for the user database)
• file system replication (for the sysvol and netlogon shares)

Of these two windows protocols, the directory replication is available in samba, but the file system replicatoin is still being worked on.

Note: homogeneous Samba 4.0 Multi-DC-Domains

Hence one can set up homogeneous Samba 4.0 Active Directory multi-DC domains, i.e. domains with multiple Samba 4.0 domain controllers and no windows domain controllers. For this kind of setup, one needs to set up an external substitute for the file system replication, for instance with some rsync-based shell scripts. One has to do this very carefully though, since the there is not concept of sysvol master role.

which appears to be contradicted by http://wiki.samba.org/index.php/Samba4/HOWTO/Join_a_domain_as_a_DC

You start samba as a DC in the same way that you start it as a normal server, just run the command ‘samba’ from the sbin directory of your installation.

When you first start Samba as a new DC in an existing Windows domain, you may find errors messages like these in the samba log file:

UpdateRefs failed with WERR_DS_DRA_BAD_NC/NT code 0xc00020f8 for 5344d0a6-78a1-4758be69-66d933f1123._msdcs.samba.example.com CN=RID Manager$,CN=System,DC=samba,DC=example,DC=com

This is caused by the Windows domain controller that haven’t yet run its Knowledge Consistency Checker (KCC), which means it has not yet created connections to the new Samba DC.

So perhaps things are not as shiny as indicated by The Register but hey, it is a start… Things should[1] only get better.

  joe

[1] I am not guaranteeing this…