Monday, January 25, 2010

mod_auth_vas woes

This last week I was assisting some application teams in setting up the Active Directory service account connection in mod_auth_vas. After messing around with some container permissions in AD, we were able to get a successful account created and everything working fine with the setup-mod_auth_vas script. The problem however is that creating accounts manually in AD is a big no-no here. We have an identity management system that requires users to request service accounts, which get tied into ownership and application records. So, after our success, we needed to delete the account and try again the "proper" way.

So we went about the proper process for account creation and moved it to a container, set up all the permissions for the person running the script, and the problems began. The script kept hitting an error of the object already existing. Digging around in the script code pointed to vastool service create. Checking this command only gave an option to create and remove, but not modify. Googling for an answer did not give up anything useful. Most of the discussion was related to the script and how to get it working in certain cases.

Eventually I ran into a document for another Vintella product documentation which had some more detail discussion about setting up the keytab. So after a few attempts, we found a working solution with this:

1) edit AD account UPN to use SPN format
2) setspn -A HTTP/fqdn.of.server Domain\AD-username
3) ktpass -princ HTTP/fqdn.of.server@DOMAIN.DOMAIN.DOMAIN -mapuser AD-username@DOMAIN.DOMAIN.DOMAIN -crypto RC4-HMAC-NT -pass -ptype KRB5_NT_PRINCIPAL -out HTTP.keytab -kvno 255
4) copy the keytab file over to your Vas configuration folder, chgrp daemon HTTP.keytab, chmod 640
5) Configure httpd.conf for mod_auth_vas if it is not done already.

Wednesday, January 13, 2010

Microsoft Annotated netmon traces for common activity

I was digging through my MS blog subscriptions and found a nice post from the Netmon team about the availability of annotated netmon captures for various Microsoft protocols (link to downloads). I would like to say thank you to all involved in collecting this type of information for everyone. I have done some captures of my own in a Vmware lab before for certain OS activities, and I know what a pain it can be to try to get a clean capture of a specific operation. This kind of information is quite useful for looking at low level operations. It helps to see what is normal and abnormal when you don't necessarily know what normal should look like.

This is a great time saver...so again, thanks.

Tuesday, January 12, 2010

TCP Traceroute in windows

Recently at the office, we ran into a typical problem of TCP ports on a few specific servers blocked by firewall or router ACL. Being the network curious guy that I am, it got me looking back into the use of programs that could traceroute to tcp ports. The problem though is every system available for testing is Windows based. My search for a good solution is still in progress, but I have gone in 5 directions so far.

1) Hping2 for windows. Tried the post xp sp2 version of this on both 2003 server and win 7 enterprise. For 2003 server it worked partially, but I couldn't get any options to run and it didn't seem to do anything other than resolving hostnames. For windows 7, it crashes regardless of any compatibility settings or rights. If there is some trick to getting it working, I didn't find it in brief googling for it. Perhaps there is some missing dependency or extra effort required to get this working, I only used the precompiled version that is in the windows version download.

2) .NET sockets. You can set TTL value on a socket object, but apparently the OS will ignore this when setting up a TCP connection.

From MSDN

"Setting this property on a Transmission Control Protocol (TCP) socket is ignored by the TCP/IP stack if a successful connection has been established using the socket."

From netmon it looks like the 3 way handshake goes by system default TTL and skips whatever you requested.

3) Registry hacking. In HKLM\System\CurrentControlSet\Services\Tcpip\Parameters, you can create a DWORD value called DefaultTTL which can change your OS default TTL. The obvious drawback would be that this is going to break your network connections to other systems while you try the traceroute. And if you are remotely connected to a machine you want to run traceroute from, then its not a viable option as you would probably get kicked off the system. Other cavaets are that in windows 2003 server, the setting does not appear to take effect immediately. In Windows 7 however, it does. So if you are at the console of a Win7 machine (maybe also 2008 srv/vista...didn't try that. 2003 server does not appear to update immediately.), you could have a script to update the reg value, make a connection attempt with any standard method of opening an arbitrary TCP connection that can show the IP that the "TTL expired in transit" result is coming from and incrementally up the DefaultTTL registry until you get this error. But overall, this doesn't seem like a practical approach.

4) Success at last, SCAPY for windows. Installation is pretty simple following the guide (http://trac.secdev.org/scapy/wiki/WindowsInstallationGuide).....BUT to get it working you need 7 different components installed on your system to run it. So if you are running from your workstation or a common source where you can have this set up in advance of the problem, it works great. If the network block you are looking for doesn't effect the machine you have it installed on, then it is much less practical and you have to rely on your firewall/network guys to find the cause of the block.

5) Nemesis. I tried to get a bit simpler than scapy with this one. Initially it failed on dll problems. This was fixed with a major downgrade of winpcap to ver 3.0 (http://www.security-forums.com/viewtopic.php?t=29485). Still on Win7, running the program fails when cmd is under admin privileges with unable to create raw socket error. Checking back on the project site shows nemesis hasn't been updated since 2004, so no surprise there.

So in the future, if I have enough time and dig around with programming some more, maybe there will be some simple script solution out there, but I suspect most avenues have been blocked off by restrictions on raw sockets.