@wrx7m said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

error 1612

Just to confirm, the share that the GPO is pointing to, has read permissions set for authenticated users all the way down to the msi file, right?

Using the files from the example GPO information I posted earlier:

Authenticated Users, Domain Computers, and even Everyone has read & execute set for the root folder (gposw). The share permissions are set to Everyone with Full Control

The subfolder eset is inheriting these permissions properly (at least per the Advanced Security Settings dialog box).

The file eea_nt64_enu_6.6.2089.2.msi is inheriting the expected permissions as well.

@wrx7m said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

@wrx7m said in GPO Software Deployment Woes:

Are your GPOs working now?

Nope, as that's the permissions I've had set when this started. I'm really pulling my hair out on this one...

What does the security filtering look like for the GPO? If you removed authenticated users from there, you need to make sure that you add it as read in the delegation tab.

The security filtering has both "Authenticated Users" and "Domain Computers" listed (I added Domain Computers after the fact in desperation). The Delegation tab has them both listed as well as "Read (from Security Filtering).

The GPOs are running, it's the install that fails with error 1612.

I need to figure out how to see if the GPO is actually trying to grab the files or not. And if it is and failing, why...

@wrx7m said in GPO Software Deployment Woes:

Are your GPOs working now?

Nope, as that's the permissions I've had set when this started. I'm really pulling my hair out on this one...

@wrx7m said in GPO Software Deployment Woes:

@anthonyh said in GPO Software Deployment Woes:

To add:

When using the Effective Access feature of Advanced Security Settings for the share, if I specify the user/group of "Authenticated Users", it shows success for the various execute and read permissions. If I do the same for "Domain Computers", it shows no access at all. Though my understanding is that "Authenticated Users" is supposed to encompass computer accounts as well and supersede "Domain Computers", but it is odd nonetheless since I explicitly give "Domain Computers" read/execute just like "Authenticated Users".

That is correct. Domain computers are included in Authenticated Users.

Thanks for the confirmation!

To add:

When using the Effective Access feature of Advanced Security Settings for the share, if I specify the user/group of "Authenticated Users", it shows success for the various execute and read permissions. If I do the same for "Domain Computers", it shows no access at all. Though my understanding is that "Authenticated Users" is supposed to encompass computer accounts as well and supersede "Domain Computers", but it is odd nonetheless since I explicitly give "Domain Computers" read/execute just like "Authenticated Users".

@anthonyh said in GPO Software Deployment Woes:

@Dashrender said in GPO Software Deployment Woes:

As for your issue - have you run gpresult on a client and looked at it's error - or is that where you got the 1612 error from?

I grabbed that from the Event Viewer. I'll see if gpresult returns anything different.

For all of the Software Installs GPOs it just shows a Deployment State of "Assigned" and AutoInstall "True". A sample of one is below:

        GPO: SW Distribution - ESET Endpoint AV
            Name:             ESET Endpoint Antivirus (6.6.2089.2)
            Version:          6.6
            Deployment State: Assigned
            Source:           \\filesrv02\gposw$\eset\eea_nt64_enu_6.6.2089.2.msi
            AutoInstall:      True
            Origin:           Applied Application

But in the Event Viewer it states:

The install of application ESET Endpoint Antivirus (6.6.2089.2) from policy SW Distribution - ESET Endpoint AV failed. The error was : %%1612

@Dashrender said in GPO Software Deployment Woes:

As for your issue - have you run gpresult on a client and looked at it's error - or is that where you got the 1612 error from?

I grabbed that from the Event Viewer. I'll see if gpresult returns anything different.

@Dashrender

@Dashrender said in GPO Software Deployment Woes:

Help yourself in the future - make a cname DNS record for the new server and use that. Then in the future, you just have to change the DNS record instead of changing the GPOs.

Ooo that's not a bad idea. I could create a CNAME of "gposhare". I may do this once I get this sorted out.

I am working on migrating a Server 2008 R2 domain controller pair over to Server 2016. I have demoted one of the 2008 DCs and promoted a Server 2016 DC in its place. For the most part, things seem good and happy, though I'm missing something I'm sure...

One oversight on my part was that when the Server 2008 DCs were built, I created a share on the DC itself to house files related to the Group Policies that I set up. This wasn't a big deal until it came time to retire that DC. I needed to modify all of the GPOs that point to files on that share to a new location. No big deal, right? So I copied the files to a new share on a Server 2016 file server in the environment, then edited all of the respective GPOs so that they point to the new share. All of the GPOs that reference files in the new share are happily using it, except for my Software Installation (MSI) GPOs. However, clients now now bomb on every Software Installation GPO with error 1612, which from what I understand is that the source is not available.

I've checked the source path on the GPOs multiple times and it is correct. I've checked the permissions on the share and they should be good. The share permissions are set to Everyone with Full Control, Change, and Read all checked. The NTFS permissions are set so that Everyone, Authenticated Users, and Domain Computers can Read and Execute everything within the folder, subfolders, and files. But yet, no dice.

Something I just thought of while typing this out is to perhaps try to specify the FQDN of the file server in the UNC path. For reference, the share is \\filesrv02\gposw$ Not that it should matter, but perhaps \\filesrv02.domain.org\gposw$ will make a difference? I'll try it for the heck of it I suppose...

Any clue what I'm missing?

@scottalanmiller said in Zimbra, fail2ban, CentOS 7, and firewalld:

@anthonyh said in Zimbra, fail2ban, CentOS 7, and firewalld:

@scottalanmiller said in Zimbra, fail2ban, CentOS 7, and firewalld:

https://arstech.net/zimbra-fail2ban-setup/

I came across that article and it's the most promising. Though it's still a iptables based fail2ban configuration. I'm not sure if it's as simple as changing the references to iptables or if tweaking it to work with firewalld is more involved.

I suppose an option is to disable firewalld and install iptables. I've done that before in the past.

Hmm...

Not sure why they use iptables in that example, since it is a CentOS 7 example.

Yeah. Though perhaps calls to iptables are automatically translated to firewalld? I'm going to give it a try anyway. We'll see how it goes...

@scottalanmiller said in Zimbra, fail2ban, CentOS 7, and firewalld:

https://arstech.net/zimbra-fail2ban-setup/

I came across that article and it's the most promising. Though it's still a iptables based fail2ban configuration. I'm not sure if it's as simple as changing the references to iptables or if tweaking it to work with firewalld is more involved.

I suppose an option is to disable firewalld and install iptables. I've done that before in the past.

Hmm...

Well, in examples I've seen, fail2ban is watching /var/log/zimbra as well as /opt/zimbra/mailbox.log for failed login attempts. So I was kind-of hoping for that.

This server in particular was seeing repeated postfix SASL login attempts. From what I gather foreign hosts were trying to authenticate to use it as a mail relay. The traffic has since gone away, but it triggered a wave of "my account is locked out" IT tickets.

I think in this case, with fail2ban tuned right, it would've stopped the noise.

I have Zimbra running on a CentOS 7 VM and am looking to implement fail2ban. However, the guides I'm finding are 1) dated and 2) are assuming the host is using iptables.

If anyone has any experience setting up fail2ban for Zimbra using firewalld, I'd love some pointers. If you've set it up yourself and are willing to share your configs, I'd be forever grateful to that as well.

Thanks!

I've been playing around hard with my home lab Asterisk build the past few months and have been testing various SIP trunk providers. My preferred provider is Flowroute with VoIP.ms coming in as a close second.

What I like about Flowroute is that they pass you the media stream from the media gateway that is terminating the call. So, in theory, you have the most direct audio path possible. In my testing, this seems to be true. When comparing latency with Flowroute vs VoIP.ms. In most cases Flowroute's latency is lower. In cases where it's not lower, it's unnoticeable equal to VoIP.ms (to my ear at any rate).

Pricing wise they are pretty similar. Flowroute is slightly cheaper outbound, but their inbound rate and monthly DID rates are higher (not by much, but depending on your usage could be exponential). Also, VoIP.ms has a lot more rate centers to choose from when buying DIDs via the web portal. Flowroute's can be limited depending on the NPA you desire, but I haven't reached out to their support (which is really good, as is VoIP.ms') to see if you can request rate centers in NPAs not listed on the portal.

I ported my home number to Flowroute and the process went without a hiccup. Was completed on the date and within the time window they provided.

A decent provider to play around with if you want something cheap and/or as backup is DID Logic. Their inbound/outbound rates are around $0.005/min and the cal quality/latency is good. However establishing an account is tough as they have this "anti fraud" process you have to hoop through.

Another revision.

Added logic for when "lastlogontimestamp" does not exist. This indicates the account has never logged in. So now if "lastlogontimestamp" doesn't exist it checks the account's creation date and disables the account if the creation date is past the expiration threshold.

Also added basic email reporting.

param (
    [string]$group,
    [string]$days = 30,
    [string]$test = "y"
)

# This script will search AD for eligible accounts to disable if they have either
# 1) never logged in and are older than the expration, or 2) if the last login is older than the expiration.

$emailAddrTo = "[email protected]"
$emailAddrFrom = "[email protected]"
$emailSMTP = "mail.domain.org"

$logStart = get-date -format g
$hostName = $env:COMPUTERNAME
$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$scriptName = $MyInvocation.MyCommand.Name
$log = "$scriptPath\$scriptName.log"
$delimitedList = "$scriptPath\$scriptName.delimited.txt"

# If the group parameter is not specified, throw an error and short script usage example.

if ( -not ($group)) {
    echo "Group parameter missing."
    echo "Script usage: $scriptName -group `'AD Group`' -days 30 -test NO"
    echo "If `"-days`" isn't specified the default is 30."
    echo "If `"-test NO`" isn't specified, no changes will be made."
    exit
}

echo "Disabling accounts in group $group that have no logged in for more than $days day(s)."
if ( $test -ne "NO") { echo "Running in **TEST** mode.  No changes will be made!" }

import-module activedirectory

# Select AD accounts based on group parameter

if ( $group -eq "All") {
    echo "Group All specified, grabbing all Active Directory users"
    $disableList = @(get-aduser -filter * | select -expandproperty SamAccountName)
}
else {
    echo "Grabbing Active Directory users that are a member of $group"
    $disableList = @(get-adgroupmember $group | select -expandproperty SamAccountName)
}

# Set expiration threshold based on days parameter

$expiration = (get-date).adddays(-$days)

# Define arrays to log eligible accounts

$noLogons = @()
$expiredLogons = @()

# Loop through accounts

foreach ($acct in $disableList) {

    # Reset $lastLogonTS to accomodate for null results.

    $lastLogonTS = ''

    echo "Processing account $acct"

    # Get user's distinguished name

    $acctDN = get-aduser $acct -properties distinguishedname | select -expandproperty distinguishedname

    # Check if account is disabled.  If disabled, skip account.

    $isEnabled = get-aduser $acct -properties enabled | select -expandproperty enabled

    if ( $isEnabled -eq $false) {
        echo "$acct is already disabled, skipping."
    }
    else {

        # Get the last logon timestamp for user.  If user has no timestamp, this will error (which means user has never logged in)
    
        $lastLogonTS = get-aduser $acct -properties lastlogontimestamp | select -expandproperty lastlogontimestamp -ErrorAction SilentlyContinue
    
        # If last logon timestamp does not exist, check when the account was created.  If the account is older than the threshold, disable.
    
        if (!$lastLogonTS) {
            $acctCreation = get-aduser $acct -properties whencreated | select -expandproperty whencreated
            if ( $acctCreation -lt $expiration) {
                echo "$acct has no recorded login and was created more than $days ago (created $acctCreation) which makes it eligible for deactivation."
                if ($test -eq "NO") {
                    disable-adaccount -identity $acct
                    echo "$acct disabled"
                    $noLogons += "$acct | $acctDN | Created: $acctCreation"
                }
                else {
                    $noLogons += "$acct | $acctDN | Created: $acctCreation | TEST ONLY"
                }
            }
        }
        else {
    
            # Convert last logon timestamp from file time to date time     
        
            $lastLogon = [datetime]::FromFileTime($lastLogonTS)
        
            # If last logon timestamp is older than the threshold, disable account.
        
            if ($lastLogon -lt $expiration) {
                echo "$acct's last logon was more than $days days ago ($lastLogon) and is eligible for deactivation."
                if ($test -eq "NO") {
                    disable-adaccount -identity $acct
                    echo "$acct disabled"
                    $expiredLogons += "$acct | $acctDN | Last Logon: $lastLogon"
                }
                else {
                    $expiredLogons += "$acct | $acctDN | Last Logon: $lastLogon | TEST ONLY"
                }
         
            }
        }
    }
}

# Compile report

    # Start log file
    $logEnd = get-date -format g
    write-output "Log for $scriptName`r`nExecuted on $hostName`r`nScript started $logStart`r`nScript ended $logEnd`r`n" | out-file $log

    # Generate list of users removed from group, if any.
    if (!$noLogons) {
        write-output "Accounts older than $days days with no logon were not found (this is good!).`r`n" | out-file -append $log
        }
    else
        {
        write-output "The following accounts have been disabled because they are older than $days days and have never been used:" | out-file -append $log
        write-output $noLogons | out-file -append $log
        write-output "" | out-file -append $log
        }

    # Generate list of users added to the group, if any.
    if (!$expiredLogons) {
        write-output "Accounts with the last logon older than $days days were not found (yay!)." | out-file -append $log
        }
    else
        {
        write-output "The following accounts have been disabled because their last logon was more than $days days ago:" | out-file -append $log
        write-output $expiredLogons | out-file -append $log
        }

    # Dump account information to text file to be attached to the email.

    write-output $noLogons | out-file $delimitedList
    write-output $expiredLogons | out-file -append $delimitedList


    # Send log to $emailAddr if variable is set.
    if (!$emailAddrTo) {
        write-output "`r`nNo email address specified, no report sent." | out-file -append $log
        }
    else {
        $emailBody = get-content -path $log | out-string
        send-mailmessage -from "$hostName <$emailAddrFrom>" -to $emailAddrTo -subject "$scriptName Report" -body $emailBody -smtpserver $emailSMTP -attachments $delimitedList
        }

Fixed! Now using lastLogonTimestamp.

param (
    [string]$group,
    [string]$days = 30,
    [string]$test = "y"
)

if ( -not ($group)) {
    $scriptName = $MyInvocation.MyCommand.Name
    echo "Group parameter missing."
    echo "Script usage: $scriptName -group `'AD Group`' -days 30 -test NO"
    echo "If `"-days`" isn't specified the default is 30."
    echo "If `"-test NO`" isn't specified, no changes will be made."
    exit
}

echo "Disabling accounts in group $group that have no logged in for more than $days day(s)."
if ( $test -ne "NO") { echo "Running in **TEST** mode.  No changes will be made!" }

import-module activedirectory
$disableList = @(get-adgroupmember $group | select -expandproperty SamAccountName)

$expiration = (get-date).adddays(-$days)

foreach ($acct in $disableList) {
    $lastLogonTS = get-aduser $acct -properties lastlogontimestamp | select -expandproperty 
lastlogontimestamp
    $lastLogon = [datetime]::FromFileTime($lastLogonTS)
    if ($lastLogon -lt $expiration) {
        echo "$acct's last logon was on $lastLogon which was more than $days days ago and is eligible 
for deactivation."
        if ($test -eq "NO") {
            disable-adaccount -identity $acct
            echo "$acct disabled"
        }
    }
}

@anthonyh said in Active Directory - Disable users in a group after an elapsed time of inactivity:

@anthonyh said in Active Directory - Disable users in a group after an elapsed time of inactivity:

@thwr said in Active Directory - Disable users in a group after an elapsed time of inactivity:

Same here - take care. Last logon normally won't be synced between DCs. You need to loop through Get-ADDomainController results and query each DC individually.

I will look into this. Thanks!

Looks like I need to use LastLogontimestamp as this is replicated among DCs.

https://blogs.technet.microsoft.com/askds/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works/

@anthonyh said in Active Directory - Disable users in a group after an elapsed time of inactivity:

@thwr said in Active Directory - Disable users in a group after an elapsed time of inactivity:

Same here - take care. Last logon normally won't be synced between DCs. You need to loop through Get-ADDomainController results and query each DC individually.

I will look into this. Thanks!

Looks like I need to use LastLogontimestamp as this is replicated among DCs.

@thwr said in Active Directory - Disable users in a group after an elapsed time of inactivity:

Same here - take care. Last logon normally won't be synced between DCs. You need to loop through Get-ADDomainController results and query each DC individually.

I will look into this. Thanks!

Ok, another improvement. Parameter-ized the variables. You would run it like so:

script.ps1 -group 'AD Group' -days 8675309 -test NO

If days isn't specified the default is 30. If "-test NO" is not specified, it will print the eligible accounts but not disable them.

param (
    [string]$group,
    [string]$days = 30,
    [string]$test = "y"
)

if ( -not ($group)) {
    $scriptName = $MyInvocation.MyCommand.Name
    echo "Group parameter missing."
    echo "Script usage: $scriptName -group `'AD Group`' -days 30 -test NO"
    echo "If `"-days`" isn't specified the default is 30."
    echo "If `"-test NO`" isn't specified, no changes will be made."
    exit
}

#####

echo "Disabling accounts in group $group that have no logged in for more than $days day(s)."
if ( $test -ne "NO") { echo "Running in **TEST** mode.  No changes will be made!" }

import-module activedirectory
$disableList = @(get-adgroupmember $group | select -expandproperty SamAccountName)

$expiration = (get-date).adddays(-$days)

foreach ($acct in $disableList) {
    $lastLogon = get-aduser $acct -properties lastlogondate | select -expandproperty lastlogondate
    if ($lastLogon -lt $expiration) {
        echo "$acct's last logon was more than $days days ago. Account selected to be disabled."
        if ($test -eq "NO") {
            disable-adaccount -identity $acct
            echo "$acct disabled"
        }
    }
}