Iszi's questions

We have a system that needs to provide both database and web services. We want to lock down the TLS security settings to the highest degree possible. It's running MS SQL 2008 on Windows Server 2008 R2.

I know that SQL Server 2008 does not support any protocol higher than TLS 1.0. However, I would still like the web service to reject incoming TLS 1.0 negotiation attempts. Best I can tell though, both seem to be controlled through the same SCHANNEL registry keys.

Is there any way to separately control TLS negotiation for MSSQL and IIS, on the same system, such that MSSQL is allowed to use TLS 1.0 but IIS is forced to only TLS 1.1/1.2?

I've been given a requirement to enforce a minimum password length of 15 characters on my Windows-based systems. Supposedly, this is possible and is being done on some other systems already. However, I can't seem to get it to work.

The key problem appears to be that the policy is normally limited to only accepting values of 0 to 14.

I've tried setting it higher, but it does not work.

How is anyone able to get around this?

I need a solution that will work both through domain-based GPO and on standalone systems. If possible, I need a fix that's backward-compatible down to XP/2003. Third-party tools are not an option.

I'm familiar with using the NET commands to get information for local users and groups in most scenarios. However, I'm running into a problem using it to get information for domain groups with long names. The output of NET USER appears to cap group names at around 20 characters, and I haven't found a way to use NET GROUP to get information about any groups that have names longer than that.

Certainly, from my own workstation I can use Remote Server Administration Tools utilities (e.g.: "ds..." commands, or the Active Directory module in PowerShell) to get the information I need. However, I also want to be able to look up domain group details from other systems which might not have RSAT and on which I may not be able/allowed to install additional tools.

While solving the problem with the NET GROUP command would be interesting, I'm not necessarily limited to that tool. However, I do need to limit myself to only the tools available in a core installation of the Windows 7 (or similar) operating systems so that I can easily port the solution across different computers where adding other tools might not be an option. If there's a way to do this with something like WMIC, or PowerShell without the additional RSAT modules, I'm definitely interested in hearing about it.

Example: "MyReallyLongDomainGroupName" is a member of the local Admins group. So, who has admin access to the system? Or "AnotherVerboseDomainGroupName" is in some file share permissions - who has access to that share?

I've recently come into a bit of confusion regarding PsExec and xCmd. It would be great if someone here could help clear this up, preferably with some form of external reference to given for validation.

I understand that PsExec and xCmd are tools that can be used to execute commands remotely on a system. However, not having much experience with these tools myself, I'm a bit confused as to their nature and capabilities.

• Does one tool need the other to function, or are they completely separate?
• How do they compare in terms of features?
• How do they compare in terms of security?
• How do they compare in terms of their method of operation?

A "client" system and a "server" system are connected via crossover cable. The "client" is running Windows Server 2003, and the "server" is running Windows XP Pro SP3.

The client and server ping fine both ways. When I try accessing file shares (i.e.: C$) on the client system, using the server, it works fine. My problem is that when I use the client to access files on the server, I get a "no logon servers available" error.

I'm logged on to each system using local accounts. This error generally occurs without prompting me for any credentials, but also will happen after credentials have been provided.

I've Googled this thing to death, and nothing's worked so far. What's most baffling is that it's happening at all, when I'm trying to use local accounts to connect. What could I be missing here?

I know there are several built-in tools (or tools available for download from Microsoft) that you can use to assess and modify the security policy applied to a system. A few I'm familiar with, to one degree or another, are:

• secpol.msc
• rsop.msc
• gpedit.msc

However, I've found that the results displayed by each of these will at times differ. secpol.msc may reflect a local policy, while gpedit or rsop.msc say that a GPO setting should be in place.

What I'd like to see is a comparison between the local policy, applied GPO(s), and the policy that is actually in effect on the system. At the very least, I need something that shows me the last of those - regardless of what policies are set locally or being pushed to the system, I need to know what the system is actually doing.

Is there a way I can get this comparison with one of the above tools, or another tool that's built-in or available from Microsoft? Where should I turn for an authoritative answer as to what policy the system is actually adhering to?

This is for systems running Windows XP, 2003, 7, and 2008.

Related: How can I enable domain authentication over wireless in Windows 7/2k8?

To test the domain login over wireless connection feature I'm trying to set up in the above question, I need an account that hasn't had its domain credentials cached on the local system. Unfortunately, there's only so many people in my office who might help me test this, and even then I'd rather not bother them for it. So, I'd like to be able to clear my own cached credentials after each login.

How can I clear the local cache, while still retaining the ability to cache credentials in the future?

I've got several domain-member laptops which commonly roam to places where there aren't any network ports available. Occasionally, during these times, the laptop may be used by someone who has not logged into it previously - therefore, they cannot rely on cached credentials to allow them onto the system.

We also have a fairly ubiquitous wireless network that allows us to connect using our domain accounts for 802.1X authentication. Under this configuration, the Dell WLAN Card Utility has a feature which allows the system to connect to the wireless network at logon (after the user has entered their credentials) prior to attempting authentication to the domain for local system access.

Here's the option in the configuration screen:

Here's the feature in action, just after submitting user credentials at the login screen. This occurs before allowing the user local access to the system. The computer initializes the wireless adapter, searches for the wireless network, authenticates to the wireless network (presumably with the supplied user credentials), grabs an IP address, and then searches for a Domain Controller. Once the Domain Controller is found, the user (if authenticated) is then logged in to the local system.

The above screenshots are from Server 2003, but I'm upgrading the laptops to Server 2008 and would rather not install the vendor-specific utility if it is not needed. Is this a feature that is built-in to newer versions of Windows? If so, how do I enable it without having to use the vendor-specific configuration utility? Could the configuration be pushed through a GPO?

The title pretty much covers it all. There is a Windows XP system on the network which is currently in use by another user. Since XP only allows one active user session at a time, I cannot use RDP and run appwiz.cpl to view installed programs because this would result in the local user's session being locked or terminated. So, how can I get a list of installed programs from this system remotely without inconveniencing the user?

Presume the following:

• Remote system is running Windows XP SP3.
• Local system is running Windows XP SP3 or Server 2003 SP2.
• Both systems are running practically bone-stock setups.
  • Do not presume any extra tools (MS or third-party) are installed, or non-default services enabled, unless otherwise specified here.
  • Remote Registry is enabled on the target system.
  • SNMP is disabled on the target system.
• I have a user account in the Administrator group on both systems.
• I am using an Active Directory domain account.
• I am not permitted to install any additional software, or enable any additional services on either system.
• I need a reliable list of all software which might be registered as installed.
  • The list should effectively reflect the same information which is available via appwiz.cpl.
  • Any form of dir "C:\Program Files\" is not acceptable.
• Both systems, and my user account, are members of the same Active Directory domain.
• The systems are on an isolated network, without Internet connectivity.

I've never seen this before, and hope someone here can help explain this.

The following screenshots were taken on a computer that is not a member of any domain, and therefore not having any Group Policy imposed. The logged in account at the time was the built-in Administrator. The system is running Windows XP SP3.

From secpol.msc in Security Settings -> Local Policies -> Security Options:

Usually these settings are Enabled or Disabled. I've seen some policies as "Not Defined" before, but that's usually when it is the default for that item. For these, the defaults are Enabled for Administrator and Disabled for Guest. I've never seen "Not Applicable" in a security policy setting, let alone would I expect to see it in one as basic as this.

What could have caused this, and how can I make the policy changeable again without having to re-build or restore from backup?

I'm running Windows XP Professional SP3 x86, trying to connect to a system with Windows 7 Ultimate SP1 x64.

Recently, I updated the Remote Desktop Connection software on the XP system in hopes of using Network Level Authentication (NLA) for my connections to the Windows 7 box. After the update, I connected to the Windows 7 box over RDP and enabled NLA believing that the updated client should support it.

After disconnecting and attempting to reconnect, I'm presented with the following error:

The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support.

So, I checked the About page in Remote Desktop Connection to make sure the update had applied. This is what I see.

Remote Desktop Connection
Shell Version 6.1.7600
Control Version 6.1.7600
© 2007 Microsoft Corporation. All rights reserved.
Network Level Authentication not supported. Remote Desktop Protocol 7.0 supported.

I thought NLA was supposed to be a part of RDP 7.0 clients. Is there a component I'm missing somewhere?

In Communicator, there are a few logging options available in the Options dialog.

• Under Personal:
  • Save my instant message conversations in the Outlook Conversation History folder.
  • Save my call logs in the Outlook Conversation History folder.
• Under General:
  • Turn on logging in Communicator
  • Turn on Windows Event logging for Communicator

The first two options are fairly straightforward - they do what they say they do.

The last two are a bit more ambiguous. Here's my questions:

• What "logging" does "Turn on logging in Communicator" enable exactly, and where is it stored?
• I presume "Turn on Windows Event logging" sends some logs to the Event Viewer (eventvwr.exe) but what gets logged there?
• How do these options differ from each other, in data collection and storage terms?

The General tab has a "More Information..." button in the Logging section, but that only takes you to a Privacy Statement - this tells you what Microsoft will and won't do with the information that is collected, but doesn't tell you what information is collected by which specific feature.

As I understand it, the terms Classless Inter-Domain Routing (CIDR) and Variable-Length Subnet Masking (VLSM) effectively refer to the same thing. Is there any noteworthy difference between the proper definitions of these terms? What is the history or relation between the two?

The usability of the /console and /admin switches for Remote Desktop sessions has been removed after Windows XP/2003. Microsoft claims that the functionality of connecting to a local session in newer versions of Windows should be enabled by restricting users to a single session.

Because the physical console session is never session 0, you can always reconnect to your existing session on the physical console. The Restrict Terminal Services users to a single remote session Group Policy setting determines whether you can connect to your existing physical console session. This setting is available in the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections node of the Local Group Policy Editor. You can also configure this setting in Terminal Services Configuration. The Restrict each user to a single session setting appears in Edit settings in the General section. http://support.microsoft.com/kb/947723

Is there any way - for those who don't want to generally impose this restriction, or in organizations with existing GPOs that just don't - to work around this?

I'd like to be able to connect to a specific session that is already open (i.e.: a local session left open at the physical console) on a system that does not restrict users to single sessions.

In Windows XP or Windows Server 2003:

I have a laptop configured with software for network-based vulnerability scanning of systems. The reason this is put on a laptop instead of a desktop or server, is to check systems that normally operate independently of a network, or are on remote isolated networks.

Since this laptop's primary purpose entails travel between networks, all users of the system will need access to change the TCP/IP configuration. Within our department, that's not an issue. We're all Administrators on this system for maintenance purposes anyway.

However, we plan on loaning this system out to other departments or organizations from time to time. Obviously, we do not want these other groups to have full privileges on the system if they don't need them. As far as I can tell, the only Administrator-like privilege they should need is to change the IP Address, Subnet Mask, Gateway, and DNS Servers.

How can this be done for Limited Users, without giving them any more privileges from the higher groups?