binaryfactory.ca

Common sense regarding web security is to never use the same password on multiple sites. That way, when one password gets compromised, not all of them are.

I usually generate passwords for every single web site that requires a login. For some of them, I even generate the username. There is no way I can remember all of them by heart, it is simply impossible. However, I use a combination of Firefox, Truecrypt, and KeyPass to store my passwords in a secure way. The whole hard drive is encrypted with Truecrypt, low-security site passwords are stored in Firefox, and the important ones are stored in KeyPass, which is also encrypted.

The reason for KeyPass is that you can’t rely on Firefox to keep your passwords safe, it’s not meant to do that. It does fine for my Slashdot password though, as long as the hard drive is encrypted.

With the release of the latest round of Smartphones, more and more people are using an iPhone, an Android phone, and Windows mobiles phones too. Now, these phones often come with nice data plans and decent browsers that didn’t exist just a few years ago. Before using Opera Mini and Safari mobile, going to Slashdot on a mobile phone to post a few comments did not feel like an interesting way to waste 10 minutes at all. Now, it is doable in a comfortable way.

Except typing passwords. That is definitely a pain. I don’t want to remember that 16char. password every time I post a retarded comment on Fark. Yet, I don’t really want to save cookies and authenticated sessions either, because the iPhone is not very secure (understatement of the year). I am convinced that a lot of people who use mobile phones will set a lot of their online passwords to something short, simple, and sometimes maybe even numeric only.

What is the solution? Secure mobile devices and certificates? Possibly. Fingerprint protected certificates could be nice as well, leveraged by some kind of “OpenID” infrastructure maybe.

I guess with the latest iPhone firmware, it takes more than clicking emergency call or receiving a call to unlock it, at least.

Sometimes, it might be impossible to clean up all old domain accounts at the same time. Maybe you’re using Windows 2000 mixed mode and don’t have the LastLogonTimestamp field handy, maybe your users use some applications that don’t update it properly…there can be many reasons.

However, if it is a huge environment where there are a lot of administrators, and you know that the deprovisioning process is not always followed, you should at least disable the old accounts that are members of Domain Admin.

I use oldcmp by Joeware, maker of the greatest AD tools on Earth.

Oldcmp was originally designed to disable old computer accounts, but it’s also made to work with user accounts. It can use pwdLastSet and LastLogonTimestamp as attributes.

Check out the oldcmp usage first.

Then, it is a matter of running oldcmp with the proper switches, and filters. Always run it in reporting mode first.

oldcmp -users -report -af “memberof=CN=Domain Admins,CN=Users,DC=domain,DC=com” -llts -age 120 -format csv

oldcmp -users -report -af “memberof=CN=Administrators,CN=Builtin,DC=domain,DC=com” -llts -age 120 -format csv

This will output a CSV file with a list of Domain Admins that have not logged in for 120days+ according to the LastLogonTimestamp attribute. Of course, this attribute is not precise as it is replicated roughly every 2 weeks. However, this will give you a pretty good list of “old” admins.

Then, if you only want to remove them from the Domain Admins group, either do it manually or use admod to do it. If your domain is not totally insane, there should be few accounts to remove.

If you want to completely disable the accounts, you can use the same oldcmp string as above, with the safety and reporting removed. I’ll let you read the usage so you don’t blame me if you disable all your domain admins! If you are using pwdLastSet, watch out not to disable accounts that are set so that the password doesn’t expire..

You should do that on Enterprise Admins and other high privilege groups as well obviously, and also, on the whole domain.

When working a lot with Group Policy, one thing that I would love being able to do is merging user right assignments. If you’re aware of how to do it, be sure to post a comment (Workaround, 3rd party tool, etc).

Let’s say you have 500 servers. All servers run some agent service that must always be set to automatic, and for which you have customized ACLs. (You grant helpdesk the right to restart the service for example).

Well, this is pretty easy to handle as every service can be handled in different GPOs, so you just create a GPO with your settings, and you link it appropriately.

Now, what if you want to grant the service account that this service uses on every computer the right to “Log On as a Service” ? You could put that in the same GPO, but it would override any other policy that has “Log On as a service” defined and is applied before this one. Wouldn’t it be nice to be able to specify in a GPO that the service account must have “Log on as a service” while keeping the currently specified rights?

A limitation of Active Directory that I have always found to be extremely aggravating is the Password and Account lockout policy.

You could only set one for the domain..any other policy defined at the OU level would be applied to local accounts only.

How many times did I wish I could set a different password policy for service accounts ! I had to decide between relying on people to use good service account passwords or forcing end-users to use insane passwords. So we had to trust the people creating the service accounts..

Different departments requiring different policies for auditing purposes were also a reason to setup a separate domain. That means at least two new servers, more management time..ew!

In 2008, if you are running AD in Windows 2008 Native mode, you can now create PSOs (Password Settings Objects)  and therefore apply different password policies to different security groups!

This is absolutely awesome and is a very good argument to migrate to 2008.

See this Technet article about Password Settings Objects/Fine-grained password policies , and use this great tool (PSOMgr from Joeware) to play with the settings, instead of using Adsiedit.

I wonder when Microsoft will have a nice interface to create these..

Oh yeah, and my other favorite reason is Read-Only DCs..let’s say they both rank as #1 reasons

When hardening Windows servers through security templates or Group Policies, it is important to give the proper permissions to services. You might want to grant a helpdesk group the rights to stop, start and pause a service while not being able to change the parameters on the server, and most of all, without being a local admin of that server.

To do that, you create a new Group Policy, and under Computer configuration, you find the System Services section. Then you select your spooler service, you set its startup mode to automatic, and you specify the rights.

Now, the problem is that the default rights the GPMC console shows you is NOT aligned with the actual defaults of Windows !

Here you can see on the left, what GPMC is proposing. On the right, Default Windows 2003 settings.

Now, it is probably a very good thing to remove Power Users. The print spooler might be perfectly fine with what GPMC wants you to use + your own customizations.

However, it is very important to make sure that any service that depends on this service is able to read! For example, if only administrators can read the service, and you have a Fax server that depends on the Print Spooler , it will not be able to start unless the service account it uses is part of Administrators!

Just a thing to keep in mind when hardening a lot of services, or when troubleshooting service startup problems..