pfx to pem
openssl pkcs12 -in cert.pfx -out cert.pem -nodes
cer to pem
openssl x509 -inform der -in cert.cer -out cert.pem
p7b to pem
openssl pkcs7 -in cert.p7b -inform DER -print_certs -out cert.pem
Monday, November 11, 2019
Wednesday, October 30, 2019
Hunting bad LDAP queries on your DC
This is a quick guide to find bad LDAP queries running against your Domain Controller.
To get the needed events on your DC, set the following registry settings using PowerShell:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "0"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "0"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "120"
Your DC is now logging event 1644, with information about the LDAP queries.
If you are using this cmds any LDAP Query that´s taking over 120ms(Search Time Threshold (msecs)) will be logged.
The Log Level is set to 5 ('15 Field Engineering' -Value "5") that means it logs all events, including debug strings and configuration changes. Also a complete log of the service is recorded.
Expensive LDAP search reults, are the searches those visit large number of entries. The default threshold for expensive search is 10000. We can set it using Expensive Search Results Threshold reg key, in this case we set it to 0 to get all queries.
Inefficient Search Results Threshold, are the searches those return less than 10% of visited entries. The default visited entries threshold limit for inefficient query is 1000 which means if a query visit less than 1000 entries then it will not be consider inefficient query even though if it return no entry. So we set it to 0 to get all queries.
So now you can open the Event Viewer, go to Directory Services log and depending of the number of "bad" LDAP queries, you will see a lot of 1644 events. In this events you will get information like User,Filter,Client and the attribute that preventing Optimization. So with this values you can identify the source and fix it.
Find attached an example event:
Internal event: A client issued a search operation with the following options.
Client:
10.10.10.10:54601
Starting node:
dc=domain,dc=int
Filter:
( | (uid=Jon.Doe) (sAMAccountName=Jon.Doe) )
Search scope:
subtree
Attribute selection:
uid,sAMAccountName
Server controls:
Visited entries:
359807
Returned entries:
1
Used indexes:
DNT_index:662818:N;
Pages referenced:
2945008
Pages read from disk:
0
Pages preread from disk:
0
Clean pages modified:
0
Dirty pages modified:
0
Search time (ms):
4111
Attributes Preventing Optimization:
uid
User:
domain\serviceaccount.1
In this case you can contact the responsible admin for Client 10.10.10.10 and modify the query to use a better filter. For example if you don´t use the uid field in AD, you can remove it from the LDAP query and just search for teh samaccountname.
If you have enough logs collected, you can revert your changes using the following commands:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "0"
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold'
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold'
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)'
To get the needed events on your DC, set the following registry settings using PowerShell:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "0"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "0"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "120"
Your DC is now logging event 1644, with information about the LDAP queries.
If you are using this cmds any LDAP Query that´s taking over 120ms(Search Time Threshold (msecs)) will be logged.
The Log Level is set to 5 ('15 Field Engineering' -Value "5") that means it logs all events, including debug strings and configuration changes. Also a complete log of the service is recorded.
Expensive LDAP search reults, are the searches those visit large number of entries. The default threshold for expensive search is 10000. We can set it using Expensive Search Results Threshold reg key, in this case we set it to 0 to get all queries.
Inefficient Search Results Threshold, are the searches those return less than 10% of visited entries. The default visited entries threshold limit for inefficient query is 1000 which means if a query visit less than 1000 entries then it will not be consider inefficient query even though if it return no entry. So we set it to 0 to get all queries.
So now you can open the Event Viewer, go to Directory Services log and depending of the number of "bad" LDAP queries, you will see a lot of 1644 events. In this events you will get information like User,Filter,Client and the attribute that preventing Optimization. So with this values you can identify the source and fix it.
Find attached an example event:
Internal event: A client issued a search operation with the following options.
Client:
10.10.10.10:54601
Starting node:
dc=domain,dc=int
Filter:
( | (uid=Jon.Doe) (sAMAccountName=Jon.Doe) )
Search scope:
subtree
Attribute selection:
uid,sAMAccountName
Server controls:
Visited entries:
359807
Returned entries:
1
Used indexes:
DNT_index:662818:N;
Pages referenced:
2945008
Pages read from disk:
0
Pages preread from disk:
0
Clean pages modified:
0
Dirty pages modified:
0
Search time (ms):
4111
Attributes Preventing Optimization:
uid
User:
domain\serviceaccount.1
In this case you can contact the responsible admin for Client 10.10.10.10 and modify the query to use a better filter. For example if you don´t use the uid field in AD, you can remove it from the LDAP query and just search for teh samaccountname.
If you have enough logs collected, you can revert your changes using the following commands:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "0"
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold'
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold'
Remove-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)'
Labels:
Active Directory,
LDAP
Thursday, October 24, 2019
PowerShell Get a list of IPs from DNS Names
Requirements:
You need a file C:\temp\server.csv. This file have all names in it.
server1
server2
server3
server4
And the script to get all IPs.
$names = Get-Content C:\temp\names.csv
foreach ($name in $names )
{
[System.Net.Dns]::GetHostAddresses("$name") | select -ExpandProperty IPAddressToString
}
You need a file C:\temp\server.csv. This file have all names in it.
server1
server2
server3
server4
And the script to get all IPs.
$names = Get-Content C:\temp\names.csv
foreach ($name in $names )
{
[System.Net.Dns]::GetHostAddresses("$name") | select -ExpandProperty IPAddressToString
}
Labels:
DNS,
IP,
Powershell
Thursday, July 4, 2019
Get and copy LAPS generated Admin password to clipboard
Just a PowerShell script to get and copy LAPS generated Admin password to your clipboard
Check it out on TechNet
Check it out on TechNet
Labels:
Active Directory,
Computer Accounts,
LAPS,
Powershell
Tuesday, May 14, 2019
PowerShell 7 coming soon
In the following post Steve Lee explaining why Powershell 7 and not 6.3.
https://devblogs.microsoft.com/powershell/the-next-release-of-powershell-powershell-7/
They will remove Core from the name... It makes sense if you check the .net Core Version 3.0, that would be used for PS 7, it should have all the underlying APIs and a high compatibility with Windows PowerShell 5.1. So you don´t have to struggle with compatibility issues, like in previous PS Core versions. Sounds like it would be the perfect mix from Windows PowerShell and PowerShell Core.
Microsoft said that PowerShell 7 should be available May 2019!
https://devblogs.microsoft.com/powershell/the-next-release-of-powershell-powershell-7/
They will remove Core from the name... It makes sense if you check the .net Core Version 3.0, that would be used for PS 7, it should have all the underlying APIs and a high compatibility with Windows PowerShell 5.1. So you don´t have to struggle with compatibility issues, like in previous PS Core versions. Sounds like it would be the perfect mix from Windows PowerShell and PowerShell Core.
Microsoft said that PowerShell 7 should be available May 2019!
Labels:
Powershell
Subscribe to:
Posts (Atom)