active directory

Useful registry keys to supplement settings not available in standard GPO templates

This blog entry will list some registry keys to control computer and user settings via GPO but aren’t available in the standard ADMX GPO templates.

Below you find always the same data format:

  • Computer Configuration or User Configuration
  • HIVE
  • Kay Path
  • Value Name
  • Value Type
  • Value Data
  • Short explanation
  • Link if available

Over the years I also always tried to leave a comment in the GPO’s, especially for the Registry Keys, so I could later identify them quickly and possibly even leaving a link so others could read up on these settings and options without doing long research.

Show Drive Letters first in Windows Explorer

This Registry value is set in two areas – Computer Configuration and User Configuration. See both keys below.

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
  • ShowDriveLettersFirst
  • REG_DWORD
  • 0x4 (4)
  • Defines if the drive letter is shown first in Windows Explorer
    • 0 = After
    • 1 = Mixed
    • 2 = No drive letter
    • 3 = Before
  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer
  • ShowDriveLettersFirst
  • REG_DWORD
  • 0x4 (4)
  • Defines if the drive letter is shown first in Windows Explorer
    • 0 = After
    • 1 = Mixed
    • 2 = No drive letter
    • 3 = Before

Support URL

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation
  • SupportURL
  • REG_SZ
  • URL to your support system
  • Set the Windows Support URL shown in the Computer Properties in the Support section – Link is behind the Online Support Website.

Support Hours

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation
  • SupportHours
  • REG_SZ
  • e.g.:  0800-1700 Pacific Time
  • Set the Windows Support Hours shown in the Computer Properties in the Support section.

Support Hours

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation
  • SupportPhone
  • REG_SZ
  • your helpdesk phone number
  • Set the Windows Support Phone Number shown in the Computer Properties in the Support section.

Support Manufacturer

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation
  • Manufacturer
  • REG_SZ
  • Suggest to put in your Company name here
  • Set the Manufacturer Name / Company Name shown in the Computer Properties in the Support section.

Hide Drives with no Media

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • HideDrivesWithNoMedia
  • REG_DWORD
  • 00000000
  • If set to 0x0 (0) it will not hide empty drives, if set to 0x1 (1) it will hide empty drive letters from Windows Explorer.

Expand folders to current folder

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • NavPaneExpandToCurrentFolder
  • REG_DWORD
  • 0x1 (1)
  • This will expand all folders to the current folder in the navigation panel of Windows Explorer, by default it will only navigate to the folder but not expand the path to it in the Navigation Panel. The behavior on this changed back in Windows Vista or Windows 7. This sets it back to a more Windows XP like behavior, what makes it easier to navigate Windows Explorer.

Fast Boot Enabled

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SYSTEM\CurrentControlSet\Control\Session Manager\Power
  • HiberbootEnabled
  • REG_DWORD
  • 0x0 (0)
  • Turns off Windows 10 Fast Startup – meaning a real reboot is done rather then a quick reboot that is actually not a real Windows reboot. A real reboot is slower, but much cleaner.

Office 365 – Update Channel

There is a settings in the Office ADMX files under Microsoft Office 2016 (Machine)/Updates for:

  • Enable Automatic updates
  • Update Channel
  • Update Deadline

Additionally this settings should be set to make sure everything is configured the same and installs the same:

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\Office\ClickToRun\Configuration
  • CDNBaseUrl
  • REG_SZ
  • http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60
  • This will set the Office 365 channel to current for the click to run installation.

Allow Print Driver Installation

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint
  • RestrictDriverInstallationToAdministrators
  • REG_DWORD
  • 0x0 (0)
  • Microsoft released KB5005652 which requires admin rights to install printers, and affects some existing printers that will require an admin to install driver update. Work around is to add the registry key below, which disabled this new security feature.
    • Value: 0
      • Allow non-admin users to install Point and Print printer drivers
    • Value: 1
      • Blocks non-admin users from installing Point and Print printer drivers. If this registry key does not exist, the default with KB installed will be same as Value 1, blocking non-admins from installing Point and Print printer drivers.
  • https://support.microsoft.com/en-us/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

Ensure Outlook is the default mail client

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Clients\mail
  • (Default)
  • REG_SZ
  • Microsoft Outlook
  • Ensures Microsoft Outlook is the standard mail client

Set Microsoft Teams as the default IM application

See this blog entry as well about this.

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\IM Providers
  • DefaultIMApp
  • REG_SZ
  • Teams
  • Sets Microsoft Teams as the default Instant Messenger Application.

Set Microsoft Office to read User information from Active Directory

Make sure you set both registry keys for this.

Set this to “Apply once and do not reapply” as well.

This will cause Microsoft Office applications read any user information fresh from Active Directory, as it cleans the current values.

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Office\Common\UserInfo
  • UserName
  • (not set)
  • (not set)
  • This will cause the first Office application to read the information from Active Directory and re-create it specifically for the user.
  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Office\Common\UserInfo
  • UserInitials
  • (not set)
  • (not set)
  • This will cause the first Office application to read the information from Active Directory and re-create it specifically for the user.

Disable the Network Sharing Wizard in Windows Explorer

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • SharingWizardOn
  • REG_DWORD
  • 0x0 (0)
  • Disables the Sharing Wizard in Windows Explorer.

Remove the Network form Windows Explorer

Probably one of the more important security measures you can do, to avoid the standard user browsing other systems on the network to much. It does not really prevent it, but makes it a lot less easy for regular end users, as the network area in Windows Explorer simply vanishes.

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • {F02C1A0D-BE21-4350-88B0-7367FC96EF3C}
  • REG_DWORD
  • 0x1 (1)
  • Remove Network from Windows Explorer.

Remove Administrative Tools from the Start Menu

This is made out of two combined registry keys. You will need to apply both for this to take affect.

Highly recommend to make sure it does not apply to any administrator accounts, as this can be contra productive.

  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • Start_AdminToolsRoot
  • REG_DWORD
  • 0x0 (0)
  • Removes administrative tools from the start menu.
  • User Configuration
  • HKEY_CURRENT_USER
  • Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
  • StartMenuAdminTools
  • REG_DWORD
  • 0x0 (0)
  • Removes administrative tools from the start menu.

Windows Update Restart Notifications for End Users

Please apply both Registry Keys for this to take affect.

  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\WindowsUpdate\UX\Settings
  • RestartNotificationsAllowed
  • REG_DWORD
  • 0x1 (1)
  • Will display Restart Notifications to End Users.
  • Computer Configuration
  • HKEY_LOCAL_MACHINE
  • SOFTWARE\Microsoft\WindowsUpdate\UX\Settings
  • RestartNotificationsAllowed2
  • REG_DWORD
  • 0x1 (1)
  • Will display Restart Notifications to End Users.

 

ActiveDirectory/LDAP result limits – MaxPageSize

ns a website from a systems administrator for systems administrators Home IT-Admins CMDB IT-Admins tool IT Search EOL Solutions Blog Contact Links ActiveDirectory/LDAP result limits – MaxPageSize

ActiveDirectory, respective LDAP, has a result limit setting, MaxPageSize. Those are set by default to 1000 rows per query.

This is primarily important if you use some kind of programming language to get results from LDAP, this code must compensate those limits and engage paging.

Your LDAP query does not need to provide the limit, only the code needs to do the paging as you always just get the max. amount of results set in the current settings.

In order to check your settings do the following commands in a command prompt / cmd window:

In theory you could set different values now as well, assuming you have the permission level to do so. But this is not recommended and you should engage paging instead, as you otherwise risk to overload your DCs – even if your commands won’t cause it, a possibly DoS attack could happen – malicious or not, so leave the limits, but be aware of them.

 

Auditing network users against HR lists etc.

Auditing network users against HR lists etc.

Auditing network users against HR lists – a topic that is often overlooked or causes some headache due to e.g. name variations, while it is so important to make sure that your Active Directory is a clean and up to date as possible.

There are big paid solutions out there, but unless you have the budget, resources and processes in place, you will need a simpler approach. Having worked in various sized businesses, let me make some suggestions here. Keep in mind, not all of it might be applicable or best for you, but I hope it will at least provide you some ideas and help to improve your network security.

Structured groups and rights

Before we begin – you should always make any effort to have a very well structured rights base. Avoid cross use of e.g. groups for mail distribution and NTFS file system access. It seems like a good idea until someone needs access to the NTFS path and boom he/she receives the group based communication as well. This is of course just one example. Structure your file systems and right assignments well. All of it can make all the difference. Don’t complicate things, keep it simple.

Monitoring Active Directory activity

What you want is something that constantly looks for any changes to Active Directory, at a bare minimum new users and deleted users as well as group-membership changes. There is some software out there to do this, some is free, often with limited functionality, some you need to buy. Personally I was working on a Windows Service to monitor Active Directory changes, but my time is limited and to this day I did not finish it. Having said this, the IT-Asset Management Database on this website actually has a module that does just this, it monitors the most important activities while it does actually a compare of gathered SQL data against current Active Directory information and eventually sends you a daily report about changes.

Such reports might not be perfect, as they don’t real-time monitor such activity, rather then only send you daily summary reports. Paessler PRTG in combination with either some default sensors or custom scripts like Group Membership change and password reset monitoring or the more specific script for group-membership monitoring are more then helpful. Monitor especially e.g. Domain Admins groups and other groups that would allow access to sensitive areas and data of your network. Such active alerts due to a network monitoring solutions might give you the chance to act fast.

Auditing your user base against HR (Human Resources) data

Again, there is software and solutions out there that can do this automatically or help you with your efforts. But often HR is simply using their Payroll platforms and depending on what they have, it won’t have the functionality you need or they are reluctant to implement such processes or possibly provide you access after all.

The main issue I came across is that there is a difference between the HR data and what the full name in your Active Directory (e.g.) is. You can’t further not just automate user name prediction based on any HR export data you have, cause there likely will be duplicate names as well, depending on how you create user names.

HR normally has an employee number, they should be able to provide this in any employee export to you. Now, Active Directory has actually some attributes that you easily can engage: EmployeeID, employeeNumber and employeeType. PowerShell is your friend, if you want to set them. I highly recommend to use PowerShell to some extend if you create new users. Look at the CheckLists in combination with employees in the IT-Asset Management Database as well for some hints and automation. Microsoft’s Set-ADUser PowerShell command will be helpful as well.

Eventually use a tool like the IT-Admins tool to read your users from your Active Directory and export to Excel. Once you have this, you compare the HR list against the Active Directory export. Don’t bother with VLOOKUP – research the use of INDEX/MATCH in Excel. Format both tables as tables in Excel and document your process, as this might depend a bit on what tools you engaged and how the eventual data looks like. You should end up comparing the HR employee number against the HR employee number stored and exported from Active Directory. This should give you a quick and clean overview. What you should be on the lookout for are those N/A error in Excel in the compare column, as well as possibly HR data that indicates a termination or change. You can go as far as compare the department information, again there are Active Directory attributes for this as well. Department names and department IDs.

If you want to go another step, start comparing group-membership as well. Export all the groups and members, again the IT-Admins Tool can help you here. View it possibly from both sides, the group and members view as well as user is member of groups view. Have the department owners take a look at it as well, they might want to see this.

And step three will be an NTFS rights review. Never ever should there be a user account directly used to assign rights in NTFS. This always should be done via groups. How ever, to review this I again recommend using the IT-Admins Tool, as this is actually designed to help you with the process and is able to export the needed data rather quick and simple.

Don’t forget your ERP systems and systems with Active Directory independent user bases

It is not always possible to rely on Active Directory as only source for your user base. Even if you can, the right assignment in e.g. your ERP system to functions likely is independent from Active Directory. Look in to any possibility of your ERP, either API’s or possibly dig in to the database (or where ever the data is stored), to find out about right changes (groups) and review those lists as well against HR information periodically.

Office 365

Oh – it is synchronized with Active Directory, right? Well – review it anyways. There might be a user object that is not synchronized and exists only in Office 365, groups as well. Review the rights to access certain administrative areas within Office 365.

You should definitive review third party users – especially Microsoft TEAMS and sharing e.g. SharePoint or OneDrive files and folders with outside of the organization will likely create some guest accounts. Keep an eye on those.

And then the third party applications – you need to keep an eye on those, as they can cause possible harm or gain access to sensible data. Users/Employees often will install them without reviewing them thoroughly, or they simply don’t realize they might have been there and share confidential data.

Account breach / compromise and API keys in Office 365 should also be something you want to keep a good eye on. Clicking on the wrong link (it will happen!), entering the password and it is to late. Don’t think a simple password reset will solve the issue. Don’t only rely on your MFA. Review does API keys especially in Office 365. What can happen is that the password is used right away to install an API based access to Office 365 that will then independently from password changes have access to the data. Keep an eye on those things as well!

 

Office 365 licenses and activated features per user

Office 365 licenses and activated features per user

Ever wondered which user has what license activated and e.g. which specific feature is activated? Recently I was challenged to see who has the Exchange mailbox feature enabled and who not out of the active user base. Due to the huge user-base this would have taken hours to review manually. Using PowerShell for this, connecting to Office 365, exporting the data eventually to a CSV file and filtering it in Microsoft Excel made this way easier.

The challenge here is that Microsoft uses SKU’s – or licenses – that again can have various features enabled or disabled. Let’s say you have a E5 Plan (license) assigned to your user, you still can disabled various features within this plan, e.g. Microsoft Exchange.

If you take a look at the following website, you find a whole list of GUIDs / IDs of all those various features.

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/licensing-service-plan-reference

In case of the Microsoft Exchange Mailbox feature – we are talking about this GUID: efb87545-963c-4e0d-99df-69c6916d9eb0

Once I had identified the GUID the next step was to grab users from a specific on premise Active Directory OU and query them against Microsoft Azure on the Office 365 environment as for their assigned licenses/features. The results then are collected in a PowerShell object and eventually saved in a defined file name in a CSV format that you easily can filter in Excel afterwards.

Please keep in mind that you will need RSAT tools (PowerShell) and Azure/Office 365 connectivity, rights etc. in order for this to work.

 

Active Directory password reset events and group change events

Active Directory password reset events and group change events

The script below uses the security event log on defined DCs within your Active Directory to export events related to certain activities. Eventually the script will export this even to an email and send it to you as a report – if needed.

As is – the script will specifically look for those events

  • 4724 – a user password was reset by an administrator respective via Active Directory Users and Groups MMC (or similar)
  • 4728 – a user was added to a security group
  • 4729 – a user was removed from a security group

There are more events – specifically events related to adding/removing users from distribution groups etc. – for the purpose of for what I wrote the script, I did not need this. Still, I thought it is worth publishing this, as others might find it helpful.

To add more events – just adjust line 19 – eventually just add more “or EventID=1234” statements – should be rather easy… in theory you could build that out as a parameter as well and inject it via the script.

 

Updated domain join script including KeePass / Pleasant Password server entries for local admins

ns a website from a systems administrator for systems administrators Home IT-Admins CMDB IT-Admins tool IT Search EOL Solutions Blog Contact Links Updated domain join script including KeePass / Pleasant Password server entries for local admins

Today I post an updated version of the domain-join script I initially posted here.

In theory you can just replace the script with the new version – assuming you did not make any changes other then adjusting it to your domain / server-names.

What changed in the newer version:

  • the top lines in the script hold the basic configuration parameters
    • line 1: NetBIOS name of your Active Directory domain
    • line 2: your DNS domain name
    • line 3: your distinguished domain name / root DN of your domain
    • line 4: your default OU for new workstations
    • line 5: empty
    • line 6: KeePass / Pleasant Password Server URL
    • line 7: KeePass folder to store the password in
  • the script now relies on the above parameters rather then specifying them in various areas in the script, making the whole use / adjustment of the script way easier
  • advanced error handling
    • after the user entered the computer name and his domain admin credentials the systems checks if it can connect to the domain and if the computer name already exists
      • if the domain credentials are invalid (can be a non-admin – as long they are valid) you get a message explaining that the script will stop due to wrong credentials
      • if the computer name already exists in the domain, you get a message about it and the script stops
    • KeePass or Pleasant Password Server connection – if it fails to connect with the credentials provided, you get a message about it and the script will stop
  • adjusted messages with various colours
    • white text – standard as it was before
    • yellow text – highlighted information so it sticks better out for the end-user
    • magenta text – handled error / failure message – this is an explanation that something stopped the script from going further
    • red text – those are real PowerShell error messages – either due to not handled errors or if the error was handled plotted out to the screen as additional reference and help

For additional information, please look at the original post here.

This script is also mentioned on the API Examples page on the Pleasant Solutions web site here.

Monitor user accounts in Active Directory with PRTG

Monitor user accounts in Active Directory with PRTG

The following script will read through your current Active Directory and filter for user accounts with the following specific conditions:

  • Lockedout users – please read below for further information about this
    • all users that are lockedout
    • must be an enabled user
    • that is not expired
  • disabled users
    • all users that have been disabled
  • expired users
    • must be an enabled user
    • the expiration date is set and past the current date
  • users with password never expires set
    • must be an enabled user

This will give you a pure counter output per channel in an for PRTG Extended script sensor XML result.

But there is a theoretical flaw in one of the methods – the locked out users. Now, user accounts get locked out in Active Directory due to too many logon attempts with an invalid password. This causes Active Directory to set the lockedout bit in the object properties. The issue here is that this bit will not be set back to 0 after the defined lockout duration (GPO) is past, the property will only be set back to 0 once the lockout duration is passed and he successfully logged on.

This means, the counter might give you more results then currently true, it might count users that have been locked out but the lockout-duration passed – but they did not yet logon successfully. This is somehow a false positive, while not totally false. In any case, you need to be aware of this.

The script could be more efficient as well in the way it filters a few things, so far I optimized it as far as I could – the LockedOut value can not be set as a -Filter, in theory it might be possible to speed it up with a -Filter to the UserAccountControl (if that is even possible – not tested) – but I am not certain this would work. If you really want to speed it up you would need to work with -LDAPFilter – but this actually needs to completely replace the internal filter capabilities of Get-ADUser – you can’t use both – it is one or the other.

This script updated with a corrected version as of February 2019 and was also posted in the PRTG knowledge base here.

Automate Outlook signature roll outs while pulling the information from Active Directory / LDAP

Automate Outlook signature roll outs while pulling the information from Active Directory / LDAP

The Outlook signature script you will find below is a bit more complicated then most other scripts I post, cause you might need to adjust a bit more. I used it for several years (as you can see in the script when it comes to Outlook versions and registry keys) in many networks and in most cases it worked just flawless once it was set up.

What does this script do exactly?

Good question – it actually writes every time a user logs on a signature file to his profile. The information in the file are pulled from Active Directory – where you are able to e.g. change the phone number, cell phone number or e.g. last name because the employee married. The signature file will automatically update. Even more important is the onboarding process, you actually can forget about setting up the signature. Assuming you don’t use roaming profiles, well – no worries – the signature will auto create everywhere, if you call it via a login script / logon script. In theory you could call it via a GPO as well.

What you need to do – simply said

  1. get an approved example signature from HR or marketing or who ever can provide you the signature and actually put it in your Outlook as signature.
  2. then replace names, phone numbers with variables (I come to that) and save it in your Outlook.
  3. go to your %appdata%\Microsoft\Signatures folder and grab the three files (.txt / .htm / .rtf) and the sub-folder with the name of the signature you saved
  4. copy them to your \\mydomain\netlogon\signatures folder (you might need to create it – any other location would need some adjustment in the script)
  5. you will need to open the all three file formats (.txt / .htm / .rtf) in a regular text editor – plain text editor like NOTEPAD.EXE (Windows) or Notepad ++
  6. make sure the variables are a complete word and not somehow divided or have characters replaced – if something is not how it should be, adjust it and save the files
  7. Copy the OutlookSignatures.vbs file to the same path and adjust it especially in the header-section with your domain information and execute the script in a CMD / command prompt via \\mydomain\netlogon\signatures\OutlookSignatures.vbs “my signature” 1 1
  8. Now go back to your Outlook (probably close and re-open) and create a new email – you should see your signature was auto-generated and the variables have been replaced with you user-specific values from Active Directory / LDAP.
  9. you should switch your email format to all three formats – HTML / Plain Text / RTF and check the signature in all three formats – to make sure all three files where generated correctly
  10. If something is not as expected, check the source-signature files and their variables and if needed adjust the variable-replacement section of the script

What you gain from this

The signatures will auto-generate and you actually have a cheap way to roll out corporate identity conform signatures, without spending a lot of money for tools that might provide you an easier to use configuration and some more fancy features – but if you don’t need those features and you can live with a more technical way to approach this you actually have a cheap way to implement this.

The variables

The script will pull certain properties / attributes from the currently logged on user object from Active Directory – those are configured in line 33 and if you need more you will need to add them here.

Between the lines 145 and 181 you see that the script is replacing place-holder variables in the source files (.TXT / .HTM / .RTF) with the information pulled from Active Directory – all those place holders in your source files need to be @@AnyName@@ – this is to make sure you have a unique definition of what the script will replace.

Example:

This does nothing else then:

  1. replace the variable strCurrentLine with
    1. search in variable strCurrentLine
    2. for the value @@GivenName@@
    3. replace it with LDAP attribute “givenName

There are a few special examples for putting e.g. a HTML conform line-break after Job-Title in the .HTM file only in the script (I had situations where only the HTML signature did not do a Line-Break, or the Text-Version alone was not doing something, etc..) – in the end this allows you to adjust something in a one of the three signature formats.

Another example in the script writes an additional line with the cell phone / mobile number if available. If the number is set in the user object, a new line will be created depending on the file format – if the number is not set the search-variable will be removed from the signature (you off course don’t want it there) instead of writing the information out. In this case we add a “Cell: ” as prefix before the number so the signature indicates clearly what this number is about. Simply said, since we replace a variable and not a whole line – we have to write out more then just the number – in this case we want to add text.

Can you execute the script with various signatures per department?

Yes – you actually can – but you would need to do this with an additional script and e.g. IFMEMBER from Microsoft or group based GPOs etc…

Can you create more then one signature?

Yes – you can execute the script in various ways – you can roll out a NEW MAIL signature (full length signature) and a second version for REPLIES (short signature) and additional signatures that the user could choose from that aren’t set as either NEW MAIL or REPLY signature. The script header explains how to call the script and what parameters it will expect and how to set them.

Feel free to use the script below, adjust it for your needs. I know some of the stuff like your domain-name could be searched automatically instead of putting it hard-coded in the script – even the reg-keys could be more advanced, feel free to do so – but in the end it is not that much work and it does its job either way.

Debugging the script

At line 79 the statement “On Error Resume Next” avoids that you see errors that might arise. This is good for production so that the client/user does see as little as possible messages due to timeouts or special circumstances – but if you want to debug something or in the process to test the script itself, please remark the line so errors actually occur. They might not mean much in some cases, but they might also give you the hint you need to see what is going wrong.

Password expiration notifications for end users

Password expiration notifications for end users

Today I wanted to share a script with you that allows you to inform your users per email that their password will expire or even is expired and reminds them about your password policies like complex passwords and how to chose a password. This is a simple VBScript and can easily be adjusted. The email will be generated from a file, in this case a HTML file that you provide. You can adjust the content of this HTML file as you need it. There are sure many commercial solutions out there that can do more then this script, but if you want to save the money and are satisfied with the provided options, this sure can be a good alternative.

Let me mention one thing about passwords first – most of us live with the usual policy that passwords should be changed periodically and need to be of a certain length and complexity. We all live with the daily calls of the help-desk about forgotten passwords, not changed passwords (pretty much why I wrote the script) and so on – what changed was a new recommendation in late 2017 or early 2018 that actually is based on statistics and data and now says – yes – complex passwords and certain lengths – but do not enforce periodic changes of those passwords due to this actually resulting in to less secure passwords while users might only change a number or even write those passwords more likely down and therefor compromising the whole attempt to secure the system.

Anyways – the next few lines will explain the parameters you can adjust in the top section of the VBS script – further below I will post the script and an example HTML file so you can start right away.

The options are between the lines 7 and 61 – don’t be scared – most of them are pretty simple to understand and are actually explained in the script itself. You should not need to modify anything outside those two lines.

About the parameter naming convention and possible values:

  • starting with str as strings – those expect text-markers and alphanumeric values “text”
  • starting with int as integer values – those are direct numeric values – e.g. 123
  • starting with bol are boolean values – those can be either TRUE or FALSE – meaning on or off

Here are the options you can set:

  • strSMTPServer: SMTP mail server DNS name or IP address
  • intSMTPServerPort: SMTP mail server port – normally 25
  • strFrom: SMTP mail from address
  • strToAdmin: SMTP mail to address for administrator emails
  • strAdminMailSubject: subject for mail to administrators
  • strUserMailSubjectExpired: subject for mails to user when password is expired
  • strUserMailSubjectWillExpire: subject for mail to user when password will expire – the exact word REPLACEWITHDAYS will be replaced by the days left value so mention it in the subject line if you want to see the value there
  • strBodyURL: URL or full file-path (HTML file path e.g. file://) to import for body, the entire content of this URL/FILE will be imported to the body of the email and should explain ways how to change the password
  • strAttachment: full file-path to an attachment for the email to the users / leave empty if no attachment
  • strLDAPSortColumn: per default: pwdLastSet / sort column for LDAP query
  • intStartWithPWexpiresInDays: If the passwords expires in days N or less, the script will inform the user – keep in mind – if you run the script daily, those users will get an email every day once their password will expire in less then the indicated days. 5 is sure a good start.
  • bolIgnoreDisabledAccounts: Disabled accounts should always be ignored
  • bolInformAdminAboutPWexpires: this will inform the admin about expiring passwords
  • bolInformAdminAboutPWisExpired: this will inform the admin about accounts with expired passwords
  • bolInformAdminAboutPWneverExpires: this will inform the admin about accounts with password set to never expire
  • bolInformAdminAboutUserCantChangePW: this will inform the admin about users who are not allowed to change their password
  • bolInformAdminAboutAccountDisabled: this will inform the admin about disabled accounts found – this would have been done in ADS by an administrator
  • bolInformAdminAboutExpiredUserAccount: this will inform the admin if the user account has an expiration date and the account is expired
  • bolInformAdminAboutAccountWithoutEMail: this will inform the admin about accounts without a set email address
  • bolInformAdminAboutStillGoodPasswords: this will inform the admin about users/passwords that are still valid
  • bolInformAdminAboutIgnoredUsersExcludedByGroup: this will inform the admin about users that have been ignored by the strGroupsExclude filter
  • Please Note: the status account locked will not be checked, this should be corrected automatically by the default security GPO instead (will be in most cases by default)
  • strSearchOUs: Filter Priority 1 – only users in those OU paths will be processed. Use LDAP DN like: “OU=Folder,OU=Folder,DC=Domain,DC=local”, you do not need to include the DC=Domain,DC=local – the script will add this information if necessary. Use | (pipe) if you want to add more then one LDAP DN path. Leave empty (“”) to disable this filter
  • strGroupsExclude : Filter Priority 2 – if the user object is still not excluded, this group exclude filter will be applied. If the user is member of one of those groups (if multiple groups are defined), he will be ignored. Use | (pipe) if you want to add more then one GroupName. Leave empty (“”) to disable this filter. Example: “Group Number1|GroupNumber2”
  • strGroupsInclude: Filter Priority 3 – if the user object is still not excluded, this group Include filter will be applied. The user has to be a member of one of those groups (if multiple groups are defined). Use | (pipe) if you want to add more then one GroupName. Leave empty (“”) to disable this filter. Example: “Group Number1|GroupNumber2”
  • bolDebug: set TRUE for script-output, highly recommended to execute the Script in CMD with CSCRIPT <ScriptName> so you see it in a command window instead of dialog boxes.
  • bolAttachDebugToAdminMail: the debug output will be attached to the admin-mail (independent from bolDebug)
  • bolTestDebugOutputToConsoleOnly: this will disable the mail.send – only output to the CMD will be generated, please enable bolDebug
  • bolRedirectMailToAdmin: this will redirect all mails to the admin, instead of sending them to the user – the subject line will include the user-mail address in this case – this allows you to do a real test and actually see what would be send out to whom – without actually sending the emails to the end user
  • bolAdminMailOnly: this will send the admin-mail only, no user mail will be generated

As always – feel free to reach out to me if you have any questions or comments.

Join systems to a domain and create KeePass server entries for local admin’s

Join systems to a domain and create KeePass server entries for local admin’s

Please note – this script was updated – you find the updated post here.

One of the challenges in most daily IT operations is onboarding of workstations and servers (respective domain join). Over the years I came across and tried many ways to accomplish this. Today I wanted to share a script and solution others might find helpful, but first lets get down to some theory and background.

The goals and challenges:

  • simple domain join after a system was imaged
    • this is in theory possible in a fully automated process via various imaging solutions – I found that WDS (Microsoft Windows Deployment Services are in most cases the easiest way to accomplish this while having the possibility to use this in consulting for various clients, in enterprise for various departments etc. Since Windows 10 came in to the equation some of the automation with WDS became more challenging – so keeping it simple with some additional manual labor is often the easiest way to accomplish this – to simplify the process a PowerShell script became a perfect solution).
  • systems should have a local admin account (not administrator / SID 500 / who should remain disabled) with an individual password
    • typing this manual you always risk that the password is misspelled either in your password database or on the actual operating system
    • if you think it is a good idea to have the same password on all your clients I actually suggest you do some security related research!

The PowerShell script below will do the following for you:

  1. Ask for the name of the system (this will change the hostname/computername)
  2. Ask for credentials for KeePassPleasant Password Server
  3. Ask for credentials to join the system to the domain
  4. Create a local admin user account on the system
  5. Generate a password for this account
  6. Check if there is an existing KeePassPleasant Password Server entry for this system
  7. If not – it will proceed and create a entry with the machine name, username, password and various additional information like
    1. manufacturer
    2. model
    3. serial number / service tag
    4. UEFI BIOS Windows license key
    5. MAC addresses of all network cards Windows knows about
  8. And finally it will join the domain and put the system right away in to the defined OU

The whole script is only an example – you don’t have to use KeePassPleasant Password Server nor is the script perfect for any situation – you can take it and modify it as you need it – point it to various IT Asset databases or let you chose from predefined OUs etc. – adjust it as you needed – in general it is a very useful baseline and I wanted to share it.

One of the challenges is to execute the script as administrator (elevated rights) and as well bypass the script execution restrictions without compromising them in a default image, like disabling this important security feature on the image itself. To accomplish this, a simple CMD-Script actually will execute the PowerShell script. CMD-Script can right-clicked and executed as administrator and gain elevated rights. This is as of today not possible by default with PowerShell scripts (.ps1).

Create the following two files “Execute-DomainJoin.cmd” and “Execute-DomainJoin.ps1” and save them in the same directory or e.g. a portable flash drive. Adjust the PowerShell script so it connects to your domain and local systems.

Please note – this script was updated – you find the updated post here.

Explaining, adjusting and guiding your through the PowerShell script

It is important that you understand the script so you can make adjustments to it. I will try to explain everything that is important and reference some line-numbers while doing so.

  1. Lines 1-30 are just a general introduction and show some generic information
  2. Lines 31-76 hold some functions to generate a password, to bypass some certificate issues etc
    1. Lines 35-38 are worth taking a look at, here are all the characters of the four categories that will be used to generate a password. Excluded are already usually hard to read characters in some fonts and other characters that might cause issues – of course, adjust especially line 38 to your preferences and add more symbols or remove what you don’t want to use
  3. Lines 77-89 are just informational
  4. Lines 90-96 expect some user-input
    1. new computername
    2. get credentials for the domain join (admin)
      1. the script will not validate the credentials, in theory this could be done but I never found it that important
    3. get credentials to read/write on the password database server (often not the actual admin-credentials, therefor I separated those two)
      1. the script will not validate the credentials, in theory this could be done but I never found it that important
    4. the local admin username that will be created
      1. $localAdminUser = $(“$ComputerName” + “_Admin”)
      2. the above line will create a hostname_admin account – you can adjust this to your preferences
    5. 94-95 will generate a password and encrypt it so it can be used to create the local account
  5. Lines 97-103 are just informational
  6. Lines 104-216 – this is actually the whole password server communication and entry check and generation
    1. 104-115 those lines gather various information from your current system like serial number, UEFI Windows keys, etc. – you can keep em as is
    2. 116 – please enter the URL to your password server here 
    3. 117 – here your need to enter the folder where the generated credentials are going to be put in on your password server
    4. 118 – this is the subject of the entry that will be generated – adjust this to your preferences
    5. 119-120 – those are username/password for the entry – you should leave this as is
    6. 121-134 – those lines are the details in your password server entry – adjust them to your likes
    7. 135-165 – this actually will execute the following on the REST API on your password server
      1. connect to it
      2. check if a entry with the same username already exists
    8. 166-189 – this will raise an alert that this user already exists on your password server – 189 will actually exit the whole script
    9. 190-216 – this block will write to the password server – cause it did not find an entry with the new username
  7. Lines 217-241 this shows the new created username and password – it actually suggests you compare the entries on your password server to the information shown to make sure everything is correct
  8. Lines 242-251 will create the new local admin account on the system and set the password
  9. Lines 252-267 are informational
  10. Line 268 will execute the actual domain join
    1. please adjust the -Domain and the -OUPath parameter to your specific needs
    2. note that the command will automatically restart the system
  11. Lines 269-282 Those lines are informational – actually – if anything would go wrong those lines would be shown and help to take further steps after the failed domain join – in most cases those suggestions will help – in the end the error output shown by the command for the domain join (line 268) would indicate what went wrong. The restart of the system actually would bypass this message in the end (more or less)

If you have any questions, feel free to reach out to me. The script could be cleaned up more – but I wanted to provide a working version of it – so I just did a quick clean up or some special stuff and posted it here. Personally I like things a bit more structured, but as said – this is just a general example.

Please note – this script was updated – you find the updated post here.

This script is also mentioned on the API Examples page on the Pleasant Solutions web site here.