joeware - never stop exploring... :)

Information about joeware mixed with wild and crazy opinions...

4/8/2017

AdFind SSL/TLS Certificate / Session Info

by @ 6:15 pm. Filed under general, tech

I think I have settled on the data I want to make available for the –sslinfo switch. If someone thinks there would be some additional info that would be useful please let me know.

Below is what I have for output so far for the –sslinfo switch. I am thinking the switch will initially be in BETA mode even with the release version of V01.50.00 until I sort out exactly how I want it formatted and how it might be used. I also have to sort out how to add the CSV/TSV functionality for it since when it runs in this mode it doesn’t actually get anywhere near the normal output stage of the code. I know for a mass scan of a forest that would likely be the preferred output model.

My original thinking was that the bit strength, cert version, dates, and issuer would be the most valuable bits of info. I visualize being able to tear through an entire forest looking at this info for every DC with a simple for /f loop like

for /f %i in (‘adfind -gcb -dclist’) do adfind -hh %i -sslinfo 

Like so:

[Sat 04/08/2017 18:10:11.39]
E:\DEV\cpp\vs\AdFind>for /f %i in (‘release\adfind -gcb -sc dclist’) do release\adfind -hh %i -sslinfo -utc

[Sat 04/08/2017 18:10:22.83]
E:\DEV\cpp\vs\AdFind>release\adfind -hh K16TST-DC1.k16tst.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

Certificate Info
================
  Encoding Type = X509_ASN_ENCODING (0x01)
  Version       = CERT_V3 (0x02)
  NotBefore     = 2017/04/08-16:11:31 UTC
  NotAfter      = 2018/04/08-16:11:31 UTC
  Sig Algorithm = 1.2.840.113549.1.1.13
  Issuer        = CN=CA1,DC=k16tst,DC=test,DC=loc
  Subject       = CN=K16TST-DC1.k16tst.test.loc

SSL Connection Information
==========================
  Protocol           = Transport Layer Security 1.2 client-side (SP_PROT_TLS1_2_CLIENT)
  Cipher Algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  Cipher Strength    = 256 bits
  Hash Algorithm     = 384 bit SHA hashing algorithm (CALG_SHA_384)
  Hash Strength      = 0 bits
  Key Exch Algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  Key Exch Strength  = 255 bits

The command completed successfully

[Sat 04/08/2017 18:10:22.90]
E:\DEV\cpp\vs\AdFind>release\adfind -hh K16TST-DC2.k16tst.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

Certificate Info
================
  Encoding Type = X509_ASN_ENCODING (0x01)
  Version       = CERT_V3 (0x02)
  NotBefore     = 2017/04/08-16:15:53 UTC
  NotAfter      = 2018/04/08-16:15:53 UTC
  Sig Algorithm = 1.2.840.113549.1.1.13
  Issuer        = CN=CA1,DC=k16tst,DC=test,DC=loc
  Subject       = CN=K16TST-DC2.k16tst.test.loc

SSL Connection Information
==========================
  Protocol           = Transport Layer Security 1.2 client-side (SP_PROT_TLS1_2_CLIENT)
  Cipher Algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  Cipher Strength    = 256 bits
  Hash Algorithm     = 384 bit SHA hashing algorithm (CALG_SHA_384)
  Hash Strength      = 0 bits
  Key Exch Algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  Key Exch Strength  = 255 bits

The command completed successfully

[Sat 04/08/2017 18:10:22.98]
E:\DEV\cpp\vs\AdFind>release\adfind -hh K16TSTCHLD-DC1.k16tstchld.k16tst.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

Certificate Info
================
  Encoding Type = X509_ASN_ENCODING (0x01)
  Version       = CERT_V3 (0x02)
  NotBefore     = 2017/04/08-21:19:19 UTC
  NotAfter      = 2018/04/08-21:19:19 UTC
  Sig Algorithm = 1.2.840.113549.1.1.13
  Issuer        = CN=CA1,DC=k16tst,DC=test,DC=loc
  Subject       = CN=K16TSTCHLD-DC1.k16tstchld.k16tst.test.loc

SSL Connection Information
==========================
  Protocol           = Transport Layer Security 1.2 client-side (SP_PROT_TLS1_2_CLIENT)
  Cipher Algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  Cipher Strength    = 256 bits
  Hash Algorithm     = 384 bit SHA hashing algorithm (CALG_SHA_384)
  Hash Strength      = 0 bits
  Key Exch Algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  Key Exch Strength  = 255 bits

The command completed successfully

[Sat 04/08/2017 18:10:23.11]
E:\DEV\cpp\vs\AdFind>release\adfind -hh K16TSTCHLD-DC2.k16tstchld.k16tst.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

Certificate Info
================
  Encoding Type = X509_ASN_ENCODING (0x01)
  Version       = CERT_V3 (0x02)
  NotBefore     = 2017/04/08-21:27:51 UTC
  NotAfter      = 2018/04/08-21:27:51 UTC
  Sig Algorithm = 1.2.840.113549.1.1.13
  Issuer        = CN=CA1,DC=k16tst,DC=test,DC=loc
  Subject       = CN=K16TSTCHLD-DC2.k16tstchld.k16tst.test.loc

SSL Connection Information
==========================
  Protocol           = Transport Layer Security 1.2 client-side (SP_PROT_TLS1_2_CLIENT)
  Cipher Algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  Cipher Strength    = 256 bits
  Hash Algorithm     = 384 bit SHA hashing algorithm (CALG_SHA_384)
  Hash Strength      = 0 bits
  Key Exch Algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  Key Exch Strength  = 255 bits

The command completed successfully

[Sat 04/08/2017 18:10:23.24]
E:\DEV\cpp\vs\AdFind>release\adfind -hh K16TST-RODC1.k16tst.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

Certificate Info
================
  Encoding Type = X509_ASN_ENCODING (0x01)
  Version       = CERT_V3 (0x02)
  NotBefore     = 2017/04/08-16:27:19 UTC
  NotAfter      = 2018/04/08-16:27:19 UTC
  Sig Algorithm = 1.2.840.113549.1.1.13
  Issuer        = CN=CA1,DC=k16tst,DC=test,DC=loc
  Subject       = CN=K16TST-RODC1.k16tst.test.loc

SSL Connection Information
==========================
  Protocol           = Transport Layer Security 1.2 client-side (SP_PROT_TLS1_2_CLIENT)
  Cipher Algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  Cipher Strength    = 256 bits
  Hash Algorithm     = 384 bit SHA hashing algorithm (CALG_SHA_384)
  Hash Strength      = 0 bits
  Key Exch Algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  Key Exch Strength  = 255 bits

The command completed successfully

 

And if you have a machine that doesn’t have a valid cert installed it will give the standard connection failure you already get.

[Sat 04/08/2017 18:10:23.35]
E:\DEV\cpp\vs\AdFind>release\adfind -hh k16tst2-dc1.k16tst2.test.loc -sslinfo -utc

AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016

LDAP_BIND: [k16tst2-dc1.k16tst2.test.loc] Error 0x51 (81) – Server Down
Terminating program.
And if you have a machine that doesn’t have a valid cert installed it will give the standard connection failure you already get.

 

     joe

Rating 3.67 out of 5

4/7/2017

AdFind Beta News

by @ 7:15 pm. Filed under general, tech

Added this SSL Info functionality this week. I am likely to still change it up a little. I would like to see if I can report on the server cert too. And maybe see about this going into a CSV/TSV type output format as well since it is well outside the normal code path.

Beta drop to the web site in the next week I would say… It got delayed because I started decoding msDS-RevealedUsers for RODC computer objects. That BLOB was a little different than I expected and it took a bit but I got it sorted. In the meanwhile while thinking that issue out I realized I wanted to give out info about the LDAPS connection too. 

 

E:\>adfind -ssl -rootdse -sslinfo
 
AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) April 2016
 
SSL Connection Information
  protocol           = Transport Layer Security 1.0 client-side (SP_PROT_TLS1_CLIENT)
  cipher algorithm   = AES 256-bit encryption algorithm (CALG_AES_256)
  cipher strength    = 256 bits
  hash algorithm     = SHA hashing algorithm (CALG_SHA) bits
  hash strength      = 160 bits
  key exch algorithm = Ephemeral elliptic curve Diffie-Hellman key exchange (CALG_ECDH_EPHEM)
  key exch strength  = 256 bits
 
The command completed successfully

Rating 3.00 out of 5

Woo hoo I am famous…

by @ 6:11 pm. Filed under general

… or at least I was in 2014!!

https://www.onelogin.com/blog/microsoftactive-directory-integration-experts

Rating 3.00 out of 5

4/6/2017

New Google Open Source Respository

by @ 10:47 pm. Filed under general

Repository – https://opensource.google.com/projects

Blog – https://opensource.googleblog.com/

Rating 3.00 out of 5

4/3/2017

CodePlex closing down, moving to GitHub

by @ 9:34 am. Filed under general

https://blogs.msdn.microsoft.com/bharry/2017/03/31/shutting-down-codeplex/

Rating 3.00 out of 5

3/26/2017

AdFind V01.50.00 Speed Increase for Security Descriptors When Resolving SIDs to Names

by @ 6:02 pm. Tags:
Filed under tech

As previously mentioned I have been focusing on some speed tweaks for AdFind for larger scale environments. One of the items I have wanted to speed up was the decoding of Security Descriptors especially in orgs where they got a little crazy with AD Delegation and added a ton of ACEs to object Security Descriptors. I have succeeded in this space, even better than what I had hoped.

The test AD object I am performing my speed tests on had 390 ACEs and I am resolving the SIDs halfway across the USA via a “slowish” VPN connection. Resolving the SIDs for multiple objects is actually not bad because once AdFind resolves a SID it caches it for quick retrieval the next time it encounters it within that run[1].

Here are the numbers:

VERSION Time MS
V01.49.00 SIDs only 3219
V01.50.00 SIDs only 3078
   
V01.49.00 Resolve SIDs 75296
V01.50.00 Resolve SIDs (initial) 35719
   
V01.49.00 Resolve SIDs 75296
V01.50.00 Resolve SIDs (enhanced) 4250

Yes you are reading that right, Security Descriptor expansion with SID Resolution reduced from 75.3 seconds to 35.72 seconds to 4.25 seconds.

I am expecting to wrap up a zip file with the V01.50.00 Beta in the next week with a special download location. If you are interested, stay tuned. Smile 

   joe

 

[1] I have long considered adding some persistence for SID caching but I haven’t thought about it enough to pull the trigger yet.

Rating 4.33 out of 5

3/21/2017

Where did this OS binary come from?

by @ 10:24 am. Filed under tech

Is anyone aware of a mechanism to determine what the source of a given OS binary is from?

I.E. Say you want to know where your lsass.exe binary or tcpip.sys binary came from, what specific hot fix or rollup or whatever. How do you do it?

    joe

Rating 3.00 out of 5

3/13/2017

The postings on this site…

by @ 10:19 am. Filed under general

I recently saw some internal guidance at work and decided I should post this message in case anyone at any time ever had any kind of confusion around it…

 

The postings on this site are my own and do not necessary reflect the views of my employer, ANY employer, or anyone else ever anywhere.

Rating 3.00 out of 5

3/8/2017

AdFind Build Info

by @ 1:29 am. Filed under general

Thoughts?

[Wed 03/08/2017  0:27:11.67]
E:\DEV\cpp\vs\AdFind\Debug>adfind -appver
AdFind V01.50.00.00cpp VS BETA Joe Richards (support@joeware.net) February 2016
  BUILD    :1.50.0.3150
  BUILDDATE:20170308-00:26:46

[Wed 03/08/2017  0:27:13.79]

Rating 4.00 out of 5

2/14/2017

Additional UPN Suffixes

by @ 9:45 am. Filed under tech

One of my good AD aware friends pinged me yesterday while I was at work asking about what was the specific AdFind command to find out the additional (or alternate) UPN Suffixes that may be defined for a domain. I responded back with a quick answer off the top of my head that it was on the Partitions container in the configuration container. I don’t usually like giving short answers like that but I was at work and that is the time I had available.

Once off work I did a quick google to find where someone had written this up before so I could share it. The several top links I kept clicking on just talked about how to do this from Domains and Trusts so I thought, WTH, I will write it up and hopefully this post will become one of the top posts for adding or viewing additional (or alternate) UPN Suffixes so people know you don’t have to use the GUI.

So the quick (and possibly wrong depending on your actual need, more on that later) answer is that you can find the additional (or alternate) UPN Suffixes defined in AD with the following query.

adfind -partitions -s base upnsuffixes

Or if you want to point to an AD Forest that isn’t your default forest you can use

adfind -h domainname -partitions -s base upnsuffixes

Why is that possibly wrong? Let’s walk through it.

So first the way most sites and instructions seem to be giving you for adding additional (or alternate) UPN Suffixes is to open Domains and Trusts (domain.msc) and right click on the top line that shows what you are connected to and then click on Properties which will give you the following dialog box which you can then populate with the additional (or alternate) UPN Suffixes you care to use.

image

 

What is placed there can indeed be found with the command shown above as so:

[Mon 02/13/2017 19:30:23.13]
E:\DEV>adfind -h k16tst.test.loc -partitions -s base upnsuffixes

AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016

Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc

dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.org

1 Objects returned

Further if you want to add an additional (or alternate) UPN Suffix from the command line you can rather simply accomplish that with AdMod like so:

[Mon 02/13/2017 19:30:26.77]
E:\DEV>admod -h k16tst.test.loc -partitions upnsuffixes:+:cloud.joeware.net

AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012

DN Count: 1
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2008 R2
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc

Modifying specified objects…
   DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc…

The command completed successfully

And holy crap I just realized I haven’t released a new version of AdMod in 5 years. Ugh.

Anyway now it looks like:

[Mon 02/13/2017 19:34:54.22]
E:\DEV\>adfind -h k16tst.test.loc -partitions -s base upnsuffixes

AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016

Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc

dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.net
>uPNSuffixes: cloud.joeware.org

1 Objects returned

And in domain.msc

image

So what does it look like when you want to create a new user in ADUC (dsa.msc) now?

It looks like this:

image

Wow totally cool right? Winking smile  But wait, I don’t see why anything above could possibly be wrong per your earlier parenthetical declaration.

So a little known fact and likely even less used (probably a good thing) configuration you can put into place is to set the additional (or alternate) UPN Suffixes at the OU level and have those additional (or alternate) UPN Suffixes only “take effect” in ADUC at that one and only level of the OU hierarchy in the forest. It will actually override the forest level additional (or alternate) UPN Suffixes that are displayed in in ADUC.

Though you can still use a tool that lets you specify an arbitrary UPN to set it to anything you choose, this configuration only forces validation within ADUC’s main user creation/modification forms and not within the Directory Service itself.

For example:

[Mon 02/13/2017 19:36:04.17]
E:\DEV>admod -h k16tst.test.loc -default -rb ou=users2,ou=testou upnsuffixes:+:deviantsoftware.net

AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012

DN Count: 1
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2008 R2
Base DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc

Modifying specified objects…
   DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc…

The command completed successfully

[Mon 02/13/2017 19:37:45.50]
E:\DEV>adfind -h k16tst.test.loc -default -rb ou=users2,ou=testou upnsuffixes

AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015

Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server Threshold
Base DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc

dn:OU=Users2,OU=TestOU,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: deviantsoftware.net

1 Objects returned

Here is what it looks like when you try to create a user via ADUC in that specific OU.

image

But here is what happens if you go to a subOU of the OU that you set the additional (or alternative) UPN Suffix value. Note that the additional (or alternative) OU specific UPN Suffixes are not displayed.

Again, though you can still use a tool that lets you specify an arbitrary UPN to set it to anything you choose, this configuration only forces validation within ADUCs main user creation/modification forms and not within the Directory Service itself.

image

 

You may recall, as it was only seconds ago for you, that I mentioned that you can set the UPN Suffix on a user’s UPN to ANY value you choose. That is generally true but isn’t correct in all use cases. It works perfectly in a single forest where you are not expecting anyone to use the values outside of that forest – say in the case of a cross forest trust. In a cross forest trust the external forests need to know where to route the userid authentication requests to and it does that via the domain names combined with the registrations of the UPN Suffixes on the Partitions object in the Configuration container. Anything NOT listed there will not be able to be used across a cross-forest trust.

And that also means the additional (or alternate) UPN Suffixes ONLY stamped on OUs cannot be routed across a forest trust either. In fact when you try to establish a trust after you have set some suffixes up as we did here in this post, you will see a message like this:

image

Note the lack of the extra additional (or alternate) UPN Suffix I had assigned to the OU?

If you need the routing you can set the additional (or alternate) UPN Suffix on the Partitions container AND on the OU. The setting at the OU level tells ADUC (or any tool smart enough to look for that attribute on the OU) to limit the UPN Suffix display and the setting on the Partitions container tells the rest of the world who has a forest trust where to go to resolve the ID to a principal to perform the authentication.

But joe, you say fervently and with no trust, what if you just deleted that extra OU level additional (or alternate) UPN Suffix prior to creating that trust and we just didn’t see that step? Well you have to trust me that I didn’t. Alternately I guess I can show you let see what AdFind says because, you know, trust but verify…

[Tue 02/14/2017  8:01:05.20]
E:\DEV>adfind -h k16tst.test.loc –gcb -f upnsuffixes=* upnsuffixes -e ad

AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016

Using server: K16TST-DC1.k16tst.test.loc:3268
Directory: Windows Server 2016
Base DN: DC=k16tst,DC=test,DC=loc

0 Objects returned

Err wait… what?? Maybe I did lie!!! Or wait, maybe AD is lying???

How about this then…

[Tue 02/14/2017  8:06:12.55]
E:\DEV>adfind -h k16tst.test.loc -prb -f upnsuffixes=* upnsuffixes

AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016

Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN:

dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.net
>uPNSuffixes: cloud.joeware.org

dn:OU=Users2,OU=TestOU,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: deviantsoftware.net

2 Objects returned

If you don’t have AdFind V01.50.00 VS BETA which is everyone but me as I write this then you can use -pr with -null in the place of -prb.

Did you catch that?

In the category of leaving them wanting more… I will now end this post. The –pr(b) switch vs the –gc(b) switch is a good discussion for later. Smile 

  joe

p.s. It is nice to knock the rust off and get the old blog post fingers running again. Winking smile

Rating 4.60 out of 5

[joeware – never stop exploring… :) is proudly powered by WordPress.]