Thursday, July 28, 2016

MS - Certificate autoenrollment behind a firewall

For anyone who has autoenrollment for certificates on machines that are behind firewalls, here are the ports and servers you want to look at for setting up firewall rules:


Client to domain controller:
    Kerberos port 88 (UDP/TCP)
    Ldap (TCP 389)
    RPC (tcp 135)
    RPC on dynamic port (>1023 TCP)

Client to certificate server(s) with the template available 
    RPC (TCP 135)
    Dynamic RPC (TCP > 1023) for CA servers on windows 2003 and earlier
    Dynamic RPC (TCP > 49151) for CA servers on newer windows OS's


If you want to find the specific port that the certificate services server is listening on for RPC requests, you can find it in several different ways.  If you have access to logon to the server, you can use:

tasklist /svc |find /I "Certsvc"

In that output, look at the process ID number and use it in the command below.  If the port is 52775, use:

netstat -ano |find "LISTEN" | Find "52775"


If you do not have access to logon to the server to run these commands and you have access to the old windows resource kit files, you can use RPC dump to look for the uuid 91ae6020-9e3c-11cf-8d7c-00aa00c091be.  Use:

rpcdump /S nameofremoteserver /I /v /P ncacn_ip_tcp.

This will output more than what you need, so search through the output to find the guid in the UUID field.  The port will be what is listed as the Endpoint, or in the StringBinding.


ProtSeq:ncacn_ip_tcp
Endpoint:52775
NetOpt:
Annotation:
IsListening:YES
StringBinding:ncacn_ip_tcp:computername[52775]
UUID:91ae6020-9e3c-11cf-8d7c-00aa00c091be
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 0 VersMinor 0


Once you have obtained the port, you can use any port testing tool from the client to the CA server, like test-netconnection to see if that port, and port 135 is accessible to the client. 

Thursday, July 21, 2016

"SSLv3 Information Disclosure Vulnerability" - Dell Openmanage

If you have vulnerability scanners flagging systems for SSLv3 related vulnerabilities, check your Dell OMSA version. Versions earlier than 8.x are configured with weaker protocols, as seem in the server.xml in \program files\dell\sysmgt\apache-tomcat\conf

OMSA 8.x

<Connector compression="force" SSLEnabled="true" clientAuth="false" keystoreFile="conf/keystore.db" keystorePass="${keystore_password}" keyPass="${key_password}" maxThreads="150" maxPostSize="6291456" port="1311" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"/>

--------------

OMSA 7.x

<-- <Connector port="1311" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> --> <Connector compression="force" SSLEnabled="true" address="*" clientAuth="false" keystoreFile="conf/keystore.db" keystorePass="${keystore_password}" keyPass="${key_password}" maxThreads="150" maxPostSize="6291456" port="1311" protocol="HTTP/1.1" scheme="https" secure="true" sslProtocol="TLS" ciphers="SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"/>



You can test SSLv3 connections with openssl.

Server with OMSA 8.3

C:\>openssl s_client -connect OMSA8server-ssl3 Loading 'screen' into random state - done CONNECTED(00000230) 12252:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:./ssl/s3_pkt.c:284:

Server with OMSA 7.3

C:\>openssl s_client -connect OMSA7Server:1311 -ssl3
Loading 'screen' into random state - done
CONNECTED(00000230)
depth=0 /C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
verify return:1
*snip*
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 57901ECD7AE62B7F65EFA4160F2106E5ED39AB0BC5E53FEA6AD8359F7DC01AAB


Session-ID-ctx:
Master-Key: B37B02F7037C019E471A564F56629C1FBF45967F120DF631A15DCA048202CD2F069C9628116DAA00BB93466EDF5FA2E8
Key-Arg : None
Start Time: 1469062860
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---

"TLS/SSL RC4 Cipher Suites Information Disclosure Vulnerability" Dell OpenManage

If you have vulnerability scanners flagging systems for RC4 related vulnerabilities, check your Dell OMSA version. Versions earlier than 8.x are configured with weaker protocols, as seem in the server.xml in \program files\dell\sysmgt\apache-tomcat\conf

OMSA 8.x

<Connector compression="force" SSLEnabled="true" clientAuth="false" keystoreFile="conf/keystore.db" keystorePass="${keystore_password}" keyPass="${key_password}" maxThreads="150" maxPostSize="6291456" port="1311" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"/>

--------------

OMSA 7.x

<-- <Connector port="1311" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> --> <Connector compression="force" SSLEnabled="true" address="*" clientAuth="false" keystoreFile="conf/keystore.db" keystorePass="${keystore_password}" keyPass="${key_password}" maxThreads="150" maxPostSize="6291456" port="1311" protocol="HTTP/1.1" scheme="https" secure="true" sslProtocol="TLS" ciphers="SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"/>



You can test cipher's with openssl. The example below is RC4-MD5. The format of available cipher commands in openssl is different than the tomcat configurations above. You can run "openssl ciphers" to get the list.

Server with OMSA 8.3

C:\>openssl s_client -connect OMSA8Server:1311 -cipher RC4-MD5
Loading 'screen' into random state - done
CONNECTED(00000234)
11868:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:./ssl/s23_lib.c:188:


Server with OMSA 7.3

C:\>openssl s_client -connect OMSA7Server:1311 -cipher RC4-MD5
Loading 'screen' into random state - done
CONNECTED(00000230)
depth=0 /C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
verify return:1
---
Certificate chain
0 s:/C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
i:/C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
---
Server certificate
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
subject=/C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
issuer=/C=US/ST=TX/L=Round Rock/OU=SA Enterprise Software Development/O=Dell Inc/CN=OMSA7Server
---
No client certificate CA names sent
---
SSL handshake has read 1044 bytes and written 359 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 57901EA40CB03FB263CDC30D1B77107D9B872C0BB8D9DF655981A3AA3DA67C94


Session-ID-ctx:
Master-Key: 707E2C192E1ED22E22684CBEF9B1EC139F6EA00456AFE5B6E473242064006D9C86F3D85E0CBAEC39697D82CE65F6BA4D
Key-Arg : None
Start Time: 1469062820
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---

Tuesday, June 21, 2016

Tips for AD group membership managment in powershell

Managing large groups can fail due to limits in Active Directory Web Services when too many members are in a group.

Fails: Get-adgroupmember "LargeGroup"
       error:  Get-ADGroupMember : The size limit for this request was exceeded

Works:  Add-adgroupmember and remove-adgroupmember

Work Around: get-adgroup "LargeGroup" -properties members | select -expand members

This will get the distinguishednames of all members as an array.

-----------------------------------------------

Piping groups or users into a group membership cmdlet to change the group memberships.

1) When you are piping groups into a cmdlet where the user(s) are static.  Pipe to Add-ADGroupMember.
    Ex:  get-adgroup -filter {name -like "HelpDesk*"}| add-adgroupmember -members $userdn

2) When you are piping users into a cmdlet where the group(s) are static.  Pipe to Add-ADPrincipalGroupMembership
    Ex: get-aduser bob | Add-ADPrincipalGroupMembership -memberof $groupdn

NOTE: Add-ADPrincipalGroupMembership will generate successful security audit events (Directory Service Change) for the addition of the group member, even if they were already a member of the group

-----------------------------------------------

When using Add-ADGroupMember with an array of members, if any of them are part of the group already, the whole operation will fail.  Its best to try adding one at a time.

Thursday, June 16, 2016

Piping get-aduser output through several custom powershell functions

For people who write scripts to process large amounts of AD objects, you may find that use of pipelines will be more memory efficient that variables and foreach. In one case, I was working through a problem with a script in powershell v2, where lots of strange failures were occurring, such as failing to assign values to a variable. A statement like: $a = 1, may just randomly not work. As the script was doing some heavy processing of large numbers of objects, I assumed memory consumption was the problem. I wanted to convert the script to use of pipeline. Since the script had several functions that handled different aspects of what was needed, I thought it would be good to try multiple pipelines. In the end, the change to pipelines fixed all the failures in the script.

What I wanted:

Take an OU, run get-aduser on the OU -> Pipe to an analysis function to check password expiration for different types of accounts and password policies, then decide if an email notice needed to be sent -> Pipe (if needed) to an email function -> Pipe the results of all of the above to logging function.

At each stage, different bits of calculated data or additional properties needed to be added to the original get-aduser object. This was possible by using custom PSObjects after the initial analysis function. The basics of the code is below:

function process-OU { 
 param(  
  [parameter(mandatory=$true)][string]$searchbase, 
  [string]$type="standard"
 )
 Get-ADUser -Filter {(enabled -eq $True) -and (mail -like "*") } `
      -SearchBase $SearchBase `
      -Properties mail, PasswordLastSet, sn, PasswordNeverExpires | 
           analyze-user -type $type |email-user |log-result
}

function Analyze-User{
 [CmdletBinding()]
 param (
  [Parameter(Mandatory=$True,ValueFromPipeline=$True)]
    [Microsoft.ActiveDirectory.Management.ADAccount]$user,
  [string]$Type
 )
 begin {}
 process {
  #do some analysis and decide if you want to 
                #continue with write-output $user
  #
  #Add any additional pieces of information to the user object with
  #   add-member -input $user -force NoteProperty Expired $False
  if ($proceedtoEmail) { write-output $user } 
 }
}

function Email-User {
 [CmdletBinding()]
      Param(  
        [Parameter(Mandatory=$True,ValueFromPipeline=$True)]
        [PSobject]$emailuser  
      )
    #Notice the parameter type is a generic 
    #[psobject] as it is no long conforming 
    #to the [Microsoft.ActiveDirectory.Management.ADAccount] type
 Begin{}
 Process {
  #handle email creation and sending.  
                #Check if it was sent without error, 
                #add email status as another property
 }
}

function log-result {
 [CmdletBinding()]
         Param(   
            [Parameter(Mandatory=$True,ValueFromPipeline=$True)]
              [PSObject]$user   
        )
 begin {}
 process {
  #do some logging here
 }
}


process-OU -searchbase "ou=myusers,dc=contoso,dc=com" -type "regular"

Wednesday, April 27, 2016

Start menu won't open in Windows 10 Home

Recently my kids were complaining that they needed Microsoft Office for their school work, and libre office wasn't compatible enough with what they wanted to do.  So we had to get a new machine to have something that would run Windows.  Within the first week, one of the kids managed to do something to screw up his user profile to the point that it took several minutes to logon.  Once on, the start menu wouldn't open, half of the task bar tray icons weren't working, and none of them would give any menu's when right clicking.

In the event logs, they were full of ESENT events:

Event 465: ESENT

svchost (2972) TILEREPOSITORYS-1-5-21-1971466138-3024181641-1488003878-1003: Corruption was detected during soft recovery in logfile C:\Users\thekid\AppData\Local\TileDataLayer\Database\EDB.log. The failing checksum record is located at position END. Data not matching the log-file fill pattern first appeared in sector 279 (0x00000117). This logfile has been damaged and is unusable.

Event 477: ESENT

svchost (2972) TILEREPOSITORYS-1-5-21-1971466138-3024181641-1488003878-1003: The log range read from the file "C:\Users\thekid\AppData\Local\TileDataLayer\Database\EDB.log" at offset 1142784 (0x0000000000117000) for 4096 (0x00001000) bytes failed verification due to a range checksum mismatch.  The expected checksum was 9075318455674107058 (0x7df2020d660074b2) and the actual checksum was 9075318455674107058 (0x7df2020d660074b2). The read operation will fail with error -501 (0xfffffe0b).  If this condition persists then please restore the logfile from a previous backup.

Event 454: ESENT

svchost (2972) TILEREPOSITORYS-1-5-21-1971466138-3024181641-1488003878-1003: Database recovery/restore failed with unexpected error -501.

When I went into Settings -> Accounts -> Family & other users area to try to delete the account, the only options are change account type and block.  To actually delete it, I had to use the "Manage family settings online" option.  Under the more menu pull down, there is an option to remove from family.  This shifts the account from "Your Family" down to "Other Users", where you will have an option to remove them from the machine once you click on the name.  It takes a bit of time to wipe out their profile, but once its done, their user account folder is empty.

As some Microsoft people will write, user profile corruption really doesn't exist, but in reality it happens a lot.  Windows 10 seems to be pretty sensitive to it and fails catastrophically.  I wish schools would just use free office apps so we can stick to Linux.

There are several write ups that could help resolve this type of problem if you go searching for the specific event ID's above.  If you just search for the start button not working, the tips you may come across seem pretty useless.  Deleting a user account has its own issues (loss of data, or requirement to backup before doing so).  For some other methods of dealing with this issue check out this post.