For Windows 2008, I need to create a script that will show whether connected RDP sessions are set at "high" encryption or something else (e.g., "compatible").
Does anyone know of a way to get this without going through the GUI?
I investigated wmic and powershell, but was unable to locate anything. I found a .net Powershell module for Terminal Services, but all it would do was display the status (i.e., list sessions). I actually need to see the encryption level.
Supposedly there is a "Windows Components" option under Advanced Settings when you run the Setup Manager (included in the \Tools\Deploy.cab from a Windows 2003 CD).
I can't get this to show up.
Is there a special trick?
Here is a screenshot of what it is supposed to look like:
When I run it, it looks exactly the same except there is no "Windows Components" option above Telephony.
I'm trying to make an unattend.txt-style file to use with sysocmgr.exe to verify certain Windows 2003 R2 components are uninstalled.
I've been able to find most of them, but I can't find any reference to the proper [Components] entry for "DFS Replication Diagnostic and Configuration Tools." The only two entries I have seen for DFS are DFSR and DFSRSUI, which are for different components.
in other words, is the command:
unset interface ethernet1/1 ip manageable redundant?
I was thinking that for security purposes, it would probably make sense for Netscreens to only enable management on the mgt port, but I can't find any reference to this in the Netscreen manual. Actually, I couldn't even find a reference to the "manageable" command in the Juniper Netscreen Screen OS CLI guide: http://www.juniper.net/techpubs/software/screenos/screenos5x/screenos5xidp1/CLI_5.0.0-IDP1.pdf
The config file I'm looking at will have a command like:
set interface ethernet1/1 manage-ip XXX.XXX.XXX.XXX
and then
unset interface ethernet1/1 ip manageable
I know the first command will set the ip of the management port on that interface, but I'm not sure if the next command is actually necessary, because I see later that the net admin did something like:
set interface ethernet1/1 manage ping
set interface ethernet1/1 manage ssh
set interface ethernet1/1 manage snmp
set interface ethernet1/1 manage ssl
...I'm not sure why they would bother doing that, if management on that interface is enabled by default. But if it isn't enabled by default, why bother with the "unset" command?
If this varies depending on the Netscreen device, please let me know so I can be more specific.
How do you set up egress rules using iptables on Ubuntu?
What are the steps you need to take to set up SSL on a Ruby on Rails app that is hosted on Apache2/Ubuntu?
I was playing with a lab setup recently (Windows 2003 R2 x32 SP2, Windows XP SP3, Active Directory) and noticed that if I locked the workstation, the following strange behaviour appeared:
I have a lockout policy that says that an account is locked after three invalid attempts. When trying this when unlocking the workstation, the workstation correctly says the account is locked after three invalid attempts, but it lets me continue trying passwords. If I eventually type in the correct password, it unlocks the workstation.
If I change the user's password while the workstation is locked, both the old and new password will unlock the workstation.
If I disable the user's account while the workstation is locked, they can still log in and continue to access resources.
Is this behaviour correct or just a bug in my setup? Any pointers on how to mitigate this problem?
The attack vector to exploit #1 would be if the hacker has a set list of maybe 200 or so possible passwords based on combinations of the user's birthday, kids names, whatever. They then try each of these passwords, in turn, to see if they are right (maybe using a USB keyboard wedge to automate it).
Because they are not locked out after three attempts, they can keep trying until they get the password. Once they have the password, they just wait for the user to get their account unlocked by the admin, then they can login as the user.
The issue with #2 and #3 would be if, say, someone just got fired and you wanted to prevent them from taking files with them, and disabled their account/changed their password, they could still access the files if their workstation was locked (or I assume if they were already logged into their computer).
I'm having problems giving a Domain Local group permissions to a mandatory user profile with Windows Server 2003 R2 SP2 and Windows XP SP3.
I've created a Global group called Sales, and put John and Mary in that group. I then created a Domain Local group called Sales Local and put the Sales group into that. I want John and Mary to use the same mandatory profile.
I logged in as Administrator and went to copy the profile to the appropriate folder \server01\profiles\sales and also assign the Domain Local group Sales Local permissions to use the profile.
I entered the appropriate path to the new profile location, and then clicked Change on Permitted to Use and selected the Sales Local Domain Local group (Note: I had to click on Object Types and check off Groups to do this).
On the server side, I renamed ntuser.dat to ntuser.man, then tried to log in as John.
The problem is that John doesn't see all of the profile. For example, he will see a text file I placed on the desktop, but he doesn't see the My Documents folder icon that I added to the desktop. Also, if you go to Desktop->Properties, you just see a black screen instead of theme selections, and if you try to add a My Documents folder to the desktop you get an error message that the visual style could not be set.
None of these problems exist if I make Sales a Global group, but I thought with A-G-DL-P, it wasn't "best practice" to give resources permissions based on a Global group. Also, why do I have to take the extra step of checking of "Groups" to give a group permissions to a profile? I saw a "howto" article that mentioned giving "BUILTIN\Users" access to the mandatory profile. That doesn't sound very secure.
What am I missing? Is this a configuration error on my part? A known limitation?
I had kind of a weird setup today where I wanted to enable Windows Firewall on a Windows 2003 R2 SP2 computer that would act as an Active Directory Domain Controller.
I didn't see one resource on the Internet that listed what would be required to do this, so I thought I'd list them here and see if anyone has anything to add/sees something that isn't necessary.
Ports to Open with "subnet" scope:
Ports to Open with "Any" Scope (for DHCP)
ALSO You need to restrict RPC to use fixed ports instead of everything > 1024. For that, you need to add two registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: <-- pick a port like 1600 and put it here
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: DCTcpipPort
Value type: REG_DWORD
Value data: <-- pick another port like 1650 and put it here
...don't forget to add entries in the firewall to allow those in (TCP, Subnet scope).
After doing all that, I was able to add a client computer to the AD domain (behind Windows Firewall) and log in successfully.
Is there a way to set the default UPN suffix for creating new users an Active Directory?
For example, if I have corp.mydomain.com as my AD domain, and I've added an alternate UPN suffix under Domains and Trusts that is just mydomain.com, is there any way to have that domain be the default when creating new users?
I know I can just create a template user and then when I copy it, it will have the right default suffix, but just curious as to whether there was a hidden setting that would control this.
I was wondering if anyone has a way to install Active Directory on a Windows 2003 R2 Server, without any tricks, and have no errors/warnings in the event log.
I have traditionally used an about 15 step "manual" process for installing AD, but I was doing a new server with Windows 2003 R2 and thought I'd try the "Server Manager" way. So after I installed a clean copy of Windows 2003 R2 and loaded SP2, I clicked on Add Role from the Manage Your Server window and ran the Configure Your Server wizard. I chose Typical Configuration for a First Server.
After restarting, I noticed a few issues in the event logs (some familiar):
The DSRestore Filter failed to connect to local SAM server. Error returned is <id:997>. Fixing this involved removing "dsrestor" from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Notification Packages, then resetting the Directory Services Restore Mode Administrator Account per Q322672 and rebooting.MS DTC could not correctly process a DC Promotion/Demotion event. MS DTC will continue to function and will use the existing security settings. This is related to KB923977 and involved just going into Component Services->MyComputer->Properties->MSDTC->Security Configuration->Click OK then stopping and restarting MSDTC.Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. Fixing this involved a lengthy process outlined in this article. I didn't see the DNS error that I usually see that makes you set HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations to 0, which was nice, but, still, 3 issues with a clean install "by the book".
EDIT: The DNS Error just appeared (Error 6702 DNS server has updated its own host (A) records...) so I had to implement the above fix. So that makes FOUR issues.
So my thought was...Windows 2003 has been around since, well 2003...so over six years ago. It has had innumerable patches, two service packs, even an R2 update. Is it really not possible to have an error free install of Active Directory without tricks? What am I missing?
I would like to make sure that my Windows 2008 servers are hardened against DDOS attacks.
There is a Microsoft Technet article on Hardening the TCP/IP stack, but it was last revised in January 2006. There is another article (somewhat duplicative) specifically for Windows Server 2003, but I can't find one for Windows Server 2008.
Does anyone know if these protections are already in place in Windows Server 2008's TCP/IP stack or if they are still relevant?
I found a portion of a book on Safari called Windows Server 2008 TCP/IP Protocols and Services that read:
TCP in Windows Server 2008 and Windows Vista use SYN attack protection to prevent a SYN attack from overwhelming the computer.
and
TCP in Windows Server 2008 and Windows Vista no longer supports the TcpMaxConnectResponseRetransmissions, SynAttackProtect, TcpMaxHalfOpen, and TcpMaxHalfOpenRetried registry values.
...but I can't find a mention of the other registry values nor a second source for this information.
One of our clients has a Windows 2008 Hyper-V instance hosted by CrystalTech, and sometimes the parent Hyper-V server is restarted without the child VM's being shut down properly.
As a result, when the server comes back online, the SQL Server Express service in the VM does not start, even though it is set for Automatic. There are no error entries in the event log. If you reboot the server normally, SQL Server Express starts itself just fine.
Has anyone had this issue? Any tips for resolving it?
On a side note, does anyone have any nice scripts/methods for notifications to be emailed when the server shuts down unexpectedly?
On another side note, does anyone know any good hosts for Hyper-V VM's?
Followup to Identifying DDOS Attacks on Windows 2008 Servers.
What steps are people taking to prevent DDOS attacks against their Windows 2008 Servers in a hosted environment?
I'm particularly interested in ways that don't involve a separate hardware firewall, but rather things that can be done with software or configuration of the server itself.
MS has an article called How To: Harden the TCP/IP Stack. Does anyone have experience (or thoughts) on the success of those steps?
I recently was notified by my monitoring service that a few Windows 2008 servers (hyper-v instances) were down.
I logged into the Hyper-V box and noticed everything was super slow. I opened task manager and saw that while CPU and RAM were fine, network utilization on our "Public" NIC was at 99%.
This lasted for about 10 minutes, during which time I found that disabling inbound connections for one of the servers caused the network saturation to drop to normal levels. I disabled that server's inbound connections to allow the other servers to operate, and eventually the traffic went away.
I suspect this was a DDOS or regular Denial of Service attack, but it seems pretty random. The server in question is very low visibility and not a lot of value would come from someone taking it down.
What would be the best way to tell if I am experiencing a DDOS attack? Is there anything else that you could think of that would cause this, and, if so, what should I look for?
EDIT: This happened again. I tried netstat -noa but didn't see anything useful. I was hoping there was some command or program I could run that would show me how much bandwidth each IP is using (i.e., it says network utilization is 100%, but how does that add up). Does anything like that exist?
I have a corrupt VHD that I need to get data off of. It is a Windows 2003 x32 Hyper-V Virtual Machine (NTFS). I have a nearly identical version of that VM without the data on it that works.
Using a hex editor, I tried inserting the old vhd into the working one after a few pages (randomly trying to compare), but I can't seem to get it to work.
It would be ideal to know the VHD file structure, so that I could know where the FAT is, where the VM header is, etc, so I can insert the bytes intelligently.
Anyone have any experience with this?
We have a few VM's on a Windows 2008 Server (Hyper-V) and are having a problem with routing between them.
The setup is that the Hyper-V server runs RRAS and maps IP's on its NIC to internal IP's (192.168.1.X) that the VMs use. The VMs use the hyper-V server as their gateway for outbound traffic. The reason for this setup is that our ISP assigns IP's by MAC address, so otherwise the VM's couldn't use the external IP's assigned to the server.
The issue is that the VM's cannot talk with each other using their external IP address. For example, if Server A is 4.2.2.1 (external IP)/192.168.1.1 (internal IP) and Server B is 4.2.2.2 (external IP)/192.168.1.2 (internal IP), you cannot ping 4.2.2.2 from 4.2.2.1. You CAN ping 192.168.1.1 from 192.168.1.2. We also have a Server C that is 4.2.3.1 (a different subnet), and that machine has no problem pinging Server A or Server B. So essentially unless the machines are on separate subnets, they can't talk with each other.
The reason we just don't use 192.168.1.X to communicate is that for this particular purpose we are setting up a monitoring server. This monitoring server will use a FQDN (like servera.myservers.net) to try to ping Server B. So we need to know if there is a DNS failure or something.
One weird thing is that if you do a tracert from Server A to Server C, you get a timeout for the first two attempts, and then a connection, but you don't see it going through a gateway.
We are having a weird issue with a Windows 2008 DCE Server running a Windows 2003 R2 SP2 x32 Server in a Hyper-V instance behind RRAS.
Essentially, this server stops receiving inbound traffic through RRAS periodically. Connecting to the server via Hyper-V manager and disconnecting and reconnecting the NIC allows inbound traffic to work again.
More details on the setup: The server is a Windows 2008 Data Center Edition x64 with SP1. This server has a number of external IP's associated with it by our ISP. Because the ISP ties IP's to MAC's, we use RRAS with NAT to map the external IP to an internal IP on a Hyper-V server. For example, we have a Hyper-V Virtual Network on 192.168.1.X, with the server being 192.168.1.1 and a hyper-V instance having an IP of 192.168.1.11. Then in RRAS, we create a reservation through NAT to map the external IP to that internal IP.
Although it may not be relevant, there is also a separate 192.168.0.X network that links this server with another server (a private network through the ISP). We use the 192.168.0.X network for fast communication between the VM's on both Hyper-V servers.
This setup has been working fine for the rest of the VM's (including another Windows 2003 x32 setup), but for some reason this particular Windows 2003 VM likes to stop accepting inbound traffic through RRAS every so often (about every 10 hours, but not regularly).
When this happens, the VM is still pingable from the Hyper-V server using the 192.168.1.X, but it is not pingable from the outside. So I suspect the conflict has something to do with RRAS in this setup.
I've Googled various related keywords, and found some posts referencing issues with Windows 2003 SP2 and RRAS, specifically with security settings in TCP/IP. Supposedly there are some advanced security features in SP2 where it is extra careful with how it treats routed traffic. I have installed the related hotfix and double-check the registry setting, but this does not seem to fix the issue.
Any ideas?