Has anyone been using IIS FTP 7.5 with virtual directories? I've run into an interesting issue with Microsoft's latest FTP revision and there doesn't seem to be much documentation on it yet. I create an FTP user who has multiple virtual directories in their home directory. - Each virtual directory is mapped to a unique UNC path - Each directory uses alternate credentials. - Global virtual directories are disabled In the IIS FTP Manager I can successfully authenticate, connect, and browse to each virtual directory. However, when logging in as this user via FTP, I get the following error when performing a directory listing: Response: 550 Keyset does not exist Error: Failed to retrieve directory listing In attempting to locate the problem, I ran Procmon.exe to see what was causing the error and noticed an Access Denied while performing the CreateFile operation on the following location: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\6de9c.... I'm assuming this key is used for IIS authentiation. In viewing the Security ACLs for the 6de9c.... key, the IIS_IUSRS group is granted Read permissions. I'm suspecting when using alternate credentials in the scenario I'm attempting, those alternate credentials are being run against the 6de9c.... key, which doesn't have permissions by default because they're not running under the IIS_IUSRS group. (bug??) For a workaround, I created a local group containing all of the alternate credentials (from AD) and granted the group the Read permission to the 6de9c... key. Recap on the symptoms: - FTP users without virtual directories connect and are able to list directory without error - FTP users with virtual directories using pass through authentication works - FTP users with virtual directories using alternate credentials generates and error during list directory If anyone has better insight on this issue, feel free to drop a comment.
Whoa, it's summer already! No wonder there hasn't been too much activity in CMIT. So in the spirit of summer, I'd like to present a few handy security tips everyone should employ in their Active Directory (AD) environment:#1: Ensure you have a notification process in place whenever an account lockout occurs.A bit of an alarmist approach? What if you came home and noticed crowbar marks on your front door? Wouldn't you then presume the possibility of someone attempting to break into your home? Now let's take that methodology and apply it to domain security: A large amount of account lockouts presents the possibility of someone attempting to break into your domain.Account lockouts can be checked through your Domain Controller (DC) security logs via the event viewer. Set a filter for event ID 644 to quickly browse through all of your lockout events. If you have more than one DC (which you should for redundancy), make sure to check each of them, as the lockout event will only be generated on the DC where the authentication attempt took place.Easy enough? Yes. However, unless you plan on manually checking every DC's security logs on a daily basis, you'll never know about an account lockout until something breaks. A user calls in, an application stops working, a service doesn't start after a reboot, etc. And better yet, if you allow accounts to unlock automatically, you may never know about an account lockout unless you have a notification process in place. (although it's almost a guarantee users will call no matter how short of time period the unlock is...)Microsoft, in their infinite wisdom, provides no straight-forward answers for sending alerts based on generated events. Seriously, is a config tab in the event log properties too much to ask? Anyway, there's a few methods to go about doing this, and without touching on enterprise solutions, here's my recommendation:Typically, I have either used VBS, Powershell, or 3rd party products to scan the Windows Management Instrumentation (WMI) of each DC for new account lockouts (event ID 644) and send an email for each new event. In small environments, this approach works just fine, but how does it scale in a larger environment? Frequently scanning the WMI for event logs can be quite taxing on CPU resources, depending upon your DC's hardware configuration.Enter Microsoft's EvntWin and EvntCmd, which are included in Windows Server operating systems 2000 and later. These two programs will send an SNMP message containing the details of any desired event as soon as it's triggered by the OS. There's not much documentation, but they're simple enough to setup.Prior to configuring EvntWin, you should ensure you have SNMP installed and your traps configured correctly on the servers you're monitoring. Reference: http://support.microsoft.com/kb/324263In this example, we'll use EvntWin to generate an SNMP message whenever an account lockout is detected.Connect to each DC and perform the following:Start > Run > EvntWinConfiguration Type: Select CustomFrom the left menu, select Edit >>Browse Event sources: Security > SecurityLocate and select event ID 644Click AddNow the enterprise OID of the security log will be displayed. You'll need this to configure your SNMP monitor to listen for traps from this OID, so make sure to copy it.Add anything else you may find useful to be notified on and click Apply when done When you're finished, EvntWin should look like this:Side Note: You can use the Export button to create a file for use with EvntCmd and automate this process on multiple servers via a .BAT or script. Our final step is to configure your SNMP monitoring application to listen for the enterprise OID you copied earlier and send email notifications each time a trap is received.Don't have an SNMP monitoring solution yet? That's another topic for another day.Reference: http://www.microsoft.com/resources/documentation/windows/xp/all/pro...
In the last month I've had 5 requests to run a scheduled "hidden" NTBACKUP job on standalone XP workstations. Requirements were as follows:- Full backups to run Sunday @ 8pm - Differential backups to run Monday - Saturday @ 8pm- NTBACKUP must not be displayed while running.- Additional accounts cannot be added to the local system.- Save .BKF file to USB attached storageThe key to running an interactive task as a hidden process is running under alternate credentials. A simple method of accomplishing this is to create a local account with a strong password, grant appropriate permissions to the account (Backup Operators in this example), then assign the credentials to the scheduled task. However, in order to meet the requirements set above, we'll need to use the built in SYSTEM account instead.There's probably a few methods for setting this up, but here's what I've found to be the quickest and most reliable method (at least on XP) for me. Works great as a quick backup for home users too!For this scenario I'll be using the ancient AT command for simplicity. AT has been replaced with the more robust (and complex) schtasks command, so I'll include an example using this method also. Surprisingly, AT is still around in Windows 7.1. Open NTBACKUP, configure and schedule your task. Save .BKF to external storage.2. Open Scheduled Tasks, locate the NTBACKUP job you created, open Properties and copy the contents of the Run: field, then delete the scheduled task.3. Create a .BAT file and paste the contents from the NTBACKUP Run: field and save. In this example, we'll be using "C:\Backups\Differential Daily.BAT"4. Once you've saved the .BAT, open a command prompt and enter the following: at 20:00 /EVERY:M,T,W,Th,F,Sa "C:\Backups\Differential Daily.BAT"For the weekly full backup, repeat steps 1 - 3 and modify the AT cmd on step 4:at 20:00 /EVERY:Su "C:\Backups\Full Weekly.BAT" As I mentioned earlier, here's the schtasks version of step 4:schtasks /Create /SC WEEKLY /D MON,TUE,WED,THU,FRI,SAT /ST 20:00:00 /TN "Differential Daily Backup" /TR "\"C:\Backups\Differential Backup.BAT"" /RU "SYSTEM"andschtasks /Create /SC WEEKLY /D SUN /ST 20:00:00 /TN "Full Weekly Backup" /TR "\"C:\Backups\Full Backup.BAT"" /RU "SYSTEM"(Note the use of the override operator "\" in /TR "\"C:\Backups\Differential Backup.BAT"". This is required because there's a space in the execution path. Without the override operator, your task will fail with a "Could not start" message... Lovely.)Once completed, you can view the jobs in Scheduled Tasks. Notice the tasks you've created now run under NT AUTHORITY/SYSTEM, and will run silently in the background without user interaction. Keep in mind, scheduled tasks created with AT are unable to be managed via the Scheduled Tasks GUI. You'll need to use the AT command if you'd like to modify the task. These tasks can be deleted and renamed via the GUI, however, you'll lose the ability to manage them with the AT command unless you rename them back to the At# (At1, At2, etc.) naming standard.Now the real trick is getting your users to check these backups on a consistent basis... Good luck!AT reference: http://support.microsoft.com/kb/313565SCHTASKS reference: http://technet.microsoft.com/en-us/library/cc725744%28WS.10%29.aspx
Last week I received an HTC EVO running Android 2.2 from my workplace. I've had
an iPod Touch for the better part of a year, and I must say I'm quite impressed
with what they've expanded on in the post-iPhone world. Especially the
possibilities of widgets. Who knew? (Oh right, Microsoft did with Vista... and
arguably Windows 98 with active desktop, and I think KDE... and I'm sure plenty
of 3rd party developers before that...)
Last time I owned a smart phone was in 2006... I love IT, but I don't enjoy
carrying gadgets around to distract my every waking moment, unless I have a good
reason to do so. This coming from a guy who used to repair cell phones for a
living. --Meh.
There is, however, one obnoxious "feature" I've come across that seems to be a
common complaint with the HTC EVO keyboard:
Those of us using the pipe symbol: | be it to manage your favorite CLI
remotely, or—as I found—to enter a password, will find nothing but errors in
your ventures. The HTC EVO keyboard provides access to the ASCII 166 broken pipe
character: ¦ instead of the standard ASCII 124 pipe character: | as found on
your average desktop keyboard.
Is this by design? If it is, I don't understand using a symbol most people
never use. Or am I just missing something? Could be!
For a workaround, other than changing your passwords to not include a pipe
character (heaven forbid), the simplest method is to locate the ASCII 124 pipe
via a web browser or send yourself an e-mail including the character (from an
account with credentials that doesn't use the pipe, right??), and copy/paste
from the EVO. If you're a heavy pipe user, then you may want to look into
downloading a custom keyboard app from the Android market that provides this key
for you.
Happy piping!
Keeping an updated record of what credentials your service accounts run under is
crucial to maintaining security integrity of your AD environment. Too often
these accounts are configured and forgotten about.. That is, until you have to
change the password. This is especially true for the all powerful, and over used
Administrator account. When then leads to password changing apathy--a very
dangerous road to travel.
Think twice about using the Administrator account for *anything*, especially
automated processes, such as services and scheduled tasks. Changing the password
on the Administrator account can become a nightmare if you've assigned these
credentials to tasks and services, yet have no easy method of locating
them. Oh, and remember, after a password change, any dependent
service/scheduled task will fail to start the next time that service is
restarted, or the scheduled task needs to run unless you update them. Sounds
like fun!
So, in celebration of your decision to remove the Administrator account from
all services/scheduled tasks, let's take a look at a few methods we can utilize
to audit service credentials:
Objective: Query every server in our AD environment for their list of services,
and their credentials.
First up, let's take a look at the sc.exe command with the "qc" option.
Example: sc qc snmptrap >> C:\Results.txt
Output: C:\Results.txt
Exactly what we're looking for! Except... this command can only be run against
one service at a time, so in order to meet our objective, we'd need to first
collect all services via the "sc query" command, then parse that output to run
with this command... and once you're finished collecting info, we'll need to
parse results again to collect just what we need. Bleh. Sounds like a lot of
work to make this a useful auditing tool...
Next up, let's take a look at the new Microsoft poster child, Powershell!
Powershell allows you to query WMI directly, which will simplify your auditing
life immensely. Wait--Did you read that correctly? Allow me to restate: Windows
stores vast amounts of configuration data in the WMI. If you can query the WMI
easily, you can easily audit just about anything.
Example: Get-WMIObject win32_service -computername 127.0.0.1 | select
name,startname
Output:
Oh, you only care about the Administrator account? Try this one: Get-WMIObject
win32_service -computername 127.0.0.1 –filter "startname='Administrator'" |
select name,startname
Now let's collect our server hostnames and make some modifications to the
script to audit multiple devices.
1. Export a list of all servers (and workstations if you'd like) from Active
Directory. This can be done easily by creating an AD query > Define Query
> Computers > Name: Has a value. Run it, right click and Export List… to
.csv. Adjust query as necessary.
2. We're only interested in computer names, so we'll need to parse the results.
Open the .csv and copy only the hostnames to a txt file. In this example, we'll
save it to C:\hostnames.txt
3. Fire up powershell and run this command:
foreach ($i in Get-Content "C:\hostnames.txt")
{$i + "`n" + "=========================="; Get-WMIObject win32_service
-computername $i | select name,startname | Export-CSV "$i Results.csv"}
Output: HOSTNAME Results.csv
Easy! Simple! Or so says the programmers. Powershell is extremely power, yet a
monster to learn. Most admins don't have time and expertise to play around with
it. So fear not, we have a much simpler method of achieving the same results:
Microsoft introduced wmic.exe as a command-line method of accessing the WMI
back in Windows 2000. An excellent and much under used tool.
Example: wmic /node:"HOSTNAME" /output:results.csv service get name, startname
/format:csv
Output: results.csv
How's that for easy? By using the same steps listed above to collect hostnames,
you can parse a wmic command to include each of your hostnames, which then
merges them into a single csv: (This can be done with Powershell also)
wmic /node:"HOSTNAME1","HOSTNAME2","HOSTNAME3","HOSTNAME4","HOSTNAME5"
/output:results.csv service get name, startname /format:csv
Enjoy!
Reference: http://technet.microsoft.com/en-us/library/bb742610.aspx
|
In my last entry I had explained how to monitor security events via EvntWin to generate SNMP traps. This is a great starting point for small to midsized AD environments to enable proactive event notifications, but we're really only half way there. Even with all the proper notifications in place, you may not become aware of a critical security event for days, or weeks (months...) after the event has occurred. As an example, let's say our security event is a brute force attack against Active Directory (AD) and begins on Friday. It happens to be the Friday you're out of town on vacation and not checking mail. Sure, those notifications are flying into your inbox, but unless someone is there to receive them and take appropriate action, it's not going to do you much good. When you return, you may find your security logs overwritten due to the large amount brute force attempts. When did the attack start? Was it when you received the first e-mail notification? What events occurred immediately afterward? How many accounts were compromised? Unless you've enabled some form of log archiving, there's no easy way to determine this. An ideal solution would be a centralized reporting server to collect event logs where you can archive and report to your heart's content. Alas, in the 2003/XP world, we don't have that capability natively. I'll follow up with a few changes in 2008/Windows 7 at a later time. By default, Microsoft does not enable event log monitoring, and for good reason: Without proper pruning, your event logs will eventually fill up all available hard drive space, causing a potential system failure. This is especially important on a Domain Controller (DC), which could become corrupted if the AD database volume runs out of hard drive space. (I've never understood why Microsoft doesn't include a built-in option for pruning logs like almost any other log generator. If someone can fill me in on this, I'd greatly appreciate it.) Enabling Log Archiving:Log archiving can be enabled manually on each system, or managed via Group Policy. At a minimum, I recommend enabling some form of log archiving for the Security log on all Domain Controllers and any servers you consider to be "High Security" (HR, Payroll, etc..) GPO: Open GPMC.msc > Edit the Default Domain Controllers Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Event Log: * Maximum security log size: (Whatever you've determined to be appropriate for your domain) * Retention method for security log: Do not overwrite events (clear log manually) * Ensure a prune job is set for each Domain Controller (Very important!) You'll notice a warning with these 2 GPO settings referencing Q823659. Ensure your OS meets the minimum requirements before enabling these settings, or they won't be affected by the GPO Manually: Browse to the Event Viewer > Open Properties of Security log: * Change Log size to Do not overwrite events (clear log manually) * Change Maximum log size to something reasonable. * Ensure a prune job is set for each Domain Controller/Server (Very important!)  Start off with something like 20MB and adjust depending upon your preference. Two things to keep in mind: - Larger log size = More difficult to sift through many events; fewer log files are generated. - Smaller log size = Easier to sift through many events; more logs generated. After reviewing your logs for a few weeks, you'll get a handle on what works best for your environment. By default, event logs are located in %SystemRoot%\System32\config\. If you'd like to archive logs to another location, Microsoft article KB315417 provides instructions on how to do this. Pruning:When pruning, I typically run a simple VBScript** as a daily scheduled task on each system that requires it. Again, make sure to have some form of pruning enabled and verify it's working before enabling Microsoft log archiving, or your volume will eventually fill up completely.
'-------------------------------------------------- 'Prune.vbs
'Purges files older than 90 days
Dim objFSO, objFolder, objFile, objFileList
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder("C:\WINDOWS\system32\config\") 'Location of folder to prune
Set objFileList = objFolder.Files
For Each objFile in objFileList
If DateDiff("d", objFile.DateLastModified, Now) > 90 Then 'Set number of days before purged
objFile.Delete
End If
Next'-------------------------------------------------- **As with any script, make sure you test in a LAB environment first. Do not ever run a script in your production environment without having a FULL understanding of the processes taking place!** As a final note: With any form of logging, make sure you periodically check your logs! They do no good if you only check them during a crisis, only to find out they're corrupt, incomplete, or not configured properly.
| Posted by Clint L. on November 19, 2010 at 9:42 pm |
|
|
|
