password

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.

September 6, 2018 by recommendations scripts server solutions web

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.

June 22, 2018 by recommendations scripts security server solutions

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 KeePass / Pleasant 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 KeePass / Pleasant 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 KeePass / Pleasant 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.

June 15, 2018 by configuration recommendations scripts security server solutions windows

Blog Archives