As part of some mail filter testing, I needed to install ESET Mail Security onto a Debian 4.0 Etch VPS running on Virtuozzo. As a side-note, I found that the install package for ESET’s Gateway Filter, Mail Security, and File Server Security for Linux is all the exact same package; the functionality is basically just controlled/activated by means of licensing the appropriate component.
Anyway, the download comes as an installation script called
esets.i386.deb.bin. Running that script outputs a license agreement that you have to accept, produces a .deb package called
esets.i386.deb, and outputs instructions on how to install the .deb package by using dpkg and import the license file. The .deb package installed just fine on another Debian test box, but when I attempted to run
dpkg –i esets.i386.deb on the Virtuozzo VPS, tar squawked at me that it could not open
/dev/stdin and the installation bailed:
hostname:/usr/local/src/eset# dpkg -i esets-3.0.11.i386.deb
Selecting previously deselected package esets.
(Reading database ... 24639 files and directories currently installed.)
Unpacking esets (from esets-3.0.11.i386.deb) ...
Setting up esets (3.0.11) ...
Unpacking esets modules ...
tar: /dev/stdin: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
dpkg: error processing esets (--install):
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
Lately, our company has started developing user web portals for our clients. The main goal is to provide a central reference point for common links (webmail, helpdesk, remote assistance links … ), howto documents, and other files and resources. A secondary goal was to also allow user administrators to perform basic user management through a web interface. This would include things like disabling/creating/unlocking user accounts, resetting passwords, and modifying group memberships for access reasons. Myself and the other admin tasked with setting up this portal are most familiar with PHP, and so we went of looking for the best means of interfacing with Active Directory through PHP. Read more…
If you’re looking for an easy online storage solution for Windows (and have a gmail account kicking around), check out the Gmail Drive by bjarke. It’s a free shell extension for Windows that basically adds a new drive to your computer. When you try to access the drive through Windows explorer, you are prompted for your gmail login details (you have the option of saving the details to avoid having to login each time you access the drive).
Part I demonstrated how to find aged or inactive accounts, and in Part II we will look at another lingering account type: disabled accounts.
Like inactive accounts, Directory Searchers also come in handy for disabled accounts. We can also, however, read an Active Directory account’s status directly from a hidden attribute on the ADSI object. Let’s start with the Directory Searcher method. This entry also draws from Bahram’s Blog. The code:
$adobjroot = [adsi]''
$objdisabsearcher = New-Object System.DirectoryServices.DirectorySearcher($adobjroot)
$objdisabsearcher.filter = "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1135126.96.36.1993:=2))"
$resultdisabaccn = $objdisabsearcher.findall() | sort path
We’ll start off with Inactive accounts first, and then work on the disabled accounts after that.
Active Directory in Server 2003 has a nice user/computer attribute called lastLogonTimeStamp that can help us keep track of inactive accounts. If you have ever tried to use that attribute, however, you might have come up with something like this…
As part of our process to disable user accounts, we take ownership of the user’s server-stored documents such as roaming profiles and redirected My Documents directories. We then either keep access restricted to the domain admins group or grant access to a replacement user who should receive access to the departed user’s files.
With an upgrade to Exchange 2007, we have taken advantage of the Powershell access to Exchange objects, and have scripted the mailbox provisioning and account disable processes. One of the sticking points in getting the disable script wrapped up was seizing control of the user’s directories. Now, Powershell does have the ability to modify ACL’s through the New-Acl and Set-Acl cmdlets (links below), but the users have exclusive access to their server-side directories. It is easy enough to take ownership of a directory through the Windows Explorer Security dialog, but the Powershell methods all presented some form of error when trying to set permissions or change ownership on a file system object to which you do not already have access to.
I had hoped to put this all in one post, but the thing would have gone on forever! Part I covered some basics in copying group memberships to an Active Directory user from another user, such as a template account, using Powershell. Part II will delve into my misadventures in gaining more control of user group memberships, including removing users from a group either by editing the group’s attributes or editing the user’s attributes. I was also looking for a way to change dial-in permissions on user accounts, and that will be covered by a similar strategy.
While these examples should be less dependent on the MS Exchange 2007 snap-in for Powershell and Powershell Community Extensions, please note that I have not checked through the code samples to confirm what is purely Powershell and what requires those snap-ins.