Ask Us About... Security, February 2001

by Joel Scambray

A quick "Happy February!" as we launch into another Q&A session about security in and around Microsoft products and technologies this month.

On This Page

What's the best tool to dump ACLs?

What's the best tool to dump ACLs?

Q: I was wondering if there were any tools or techniques to list existing permissions for a given group name across a Windows NT domain. Ours is a particularly large domain and we regularly review permissions using DumpACL, but I was looking for something a little more convenient than manually searching ACLs for an instance of a particular group name. A command line utility that could pipe the result to a text file would be nice.

A: There is a tool that will do exactly what you need, and it's surprisingly close at hand. By the wording of your question, I have to assume that you are using the graphical interface for DumpACL (now called DumpSec to manually search through file access control lists (ACLs) to identify the group in question. Many are not aware that DumpSec also operates in command-line mode and can generate reports in a number of text file formats. Using DumpSec in command-line mode is as simple as calling it from a command line rather than launching it from Windows Explorer. The following example will run DumpSec in batch mode (the command shown here is line-wrapped for legibility):

C:\dumpsec> dumpsec.exe /computer=\\server1 /rpt=allsharedirs

/outfile=c:\reports\output.txt /saveas= tsv

This report will dump the permissions for all non-administrative shares on \\server1, and it assumes you already have an existing network connection to \\server1 with appropriate privileges (for example, connect to \\server1\IPC$ as Administrator). The report will show owner and permissions but not audit settings, and it is saved as the tab separated value ("tsv") file c:\reports\output.txt. This command could easily be scripted to check a list of servers on a regular basis. Now all you have to do is findstr this output file for the group name that you are interested in, and all relevant references should pop up. For example, to find all occurrences of the "Power Users" group, you could use:

C:\ dumpsec>findstr /C:"Power Users" c:\reports\output.txt

\\server1\share1\ server1\Power Users RWXD RWXD

\\server1\docs\ server1\Power Users o all all

This pulls each line of the DumpSec output that contains "Power Users," as shown. I have not added the column headers from the original DumpSec report here, but from right to left they are: shared directory/file, Account, Owner, Directory Permissions, and File Permissions. So from the findstr output, we see that for the \\server1\docs share, Power Users are the owner, and they have all permissions for the directory and files therein.

I hope this gets you started on automating the process of reviewing permissions. Don't forget that DumpSec can also probe many other aspects of Windows NT/Windows 2000 security in the same way, including users, groups, the Registry, printers, policies, rights, and services.

Forcing Kerberos authentication

Q: Under Windows NT 4.0, in order to force a particular type of authentication, you need to tweak the registry. How do you force Kerberos-only authentication on a member sever?

A: I assume you are referring to the Windows NT 4.0 LMCompatibilityLevel Registry setting discussed in Knowledge Base articles 147706 and 239869. (This setting is accessible in the Windows 2000 user interface under Security Policy.) I am not aware of a similar Registry "tweak" that will force Kerberos authentication, but here are a couple of thoughts that may clarify how to accomplish what you're striving for.

Even though Kerberos cannot be forced, if it is available, then it must be used. Therefore, if you are logging on to a Windows 2000 domain and access Windows 2000 services via your domain account, you will be using Kerberos, like it or not. If you are able to tolerate some non-Kerberos authentication, you could set the LMCompatibilityLevel setting to enforce NTLM v2 across your domain. Thus, all clients will be forced to use a strong authentication protocol, whether Kerberos or NTLM v2. This is probably your smartest option.

If you want to make things Kerberos-only, then you have a few alternatives. First of all, make sure all domain controllers in the authentication environment are running Windows 2000. Once this is accomplished, one thing to try is disabling LM/NTLM authentication on the domain controllers by unbinding Microsoft file and print sharing from the appropriate network transport. To do this, open Network and Dial-up Connections in Control Panel, pull down the Advanced menu, and select Advanced Settings. Then select the appropriate network connection in the upper window, and uncheck the box next to "File and Printer Sharing for Microsoft Networks." This will block downlevel LM/NTLM clients from authenticating to the domain, but Windows 2000 clients will first try Kerberos authentication and should be able to authenticate and obtain a Ticket Granting Ticket (TGT). Note that all file and print sharing services on the domain controllers will become unavailable in this configuration (obviously). Instead of outright disabling LM/NTLM services on domain controllers, you could create an IPSec filter that either restricted (by IP address) or blocked access to the services entirely.

The next important step to take is to set access control rules based on Windows 2000 domain accounts, as per standard best practices. This ensures that clients attempting to access resources on member servers will need to authenticate to the domain first, using Kerberos. If you set up ACLs using local machine accounts, clients could log on to a member server using the local credentials via LM/NTLM. Once again, you could disable LM/NTLM logon to member servers that you wanted to be accessible only via Kerberos authentication. Note that folks who log on to the domain using their Universal Principal Name (UPN, e.g., joel@domain.com), rather than their plain old user name, will also force Kerberos authentication.

Another idea is to assign the IPSec policy "Secure Server (Require Security)" on those member servers that you are trying to protect. This will force clients to first authenticate to the domain using Kerberos before communicating via IP with these servers.

Also be aware that IIS 5 can use Kerberos for authentication, a feature that did not exist in previous versions. IIS 5 supports the "Negotiate" HTTP header, which will allow Internet Explorer 5.0 or greater clients to choose between Kerberos and NTLM authentication. (Before IIS 5, if an object was secured via Windows Integrated Authentication, only NTLM was available.) To ensure that Kerberos is available for authentication to your IIS 5 servers, make sure the Metabase Key w3svc/NTAuthenticationProviders contains the value "Negotiate" (no quotes). By default, it is set to "Negotiate,NTLM," which is fine. As always, be careful when editing the Metabase – I like to use the graphical Metaedit tool from the Microsoft® Windows® 2000 Server Resource Kit. (It is an optional install and is only available in the Server kit, not the Professional kit.)

One last tip – if you're going to experiment with Kerberos authentication, do yourself a favor and install the Windows 2000 Server Resource Kit kerbtray utility. It shows what Kerberos tickets a Windows 2000 client possesses, and it was invaluable in helping me test some of the scenarios I have proposed here.

If you can require Kerberos at the server using the methods described above and you have all Windows 2000 clients, you should be able to accomplish your goal. Good luck!

PuTTY does work on Windows 2000!

Before I close up shop for this month's column, I wanted to thank the helpful soul who wrote into the AUAS mailbox and pointed out an error in my September column in which I erroneously stated that the Win32 Telnet/SSH client puTTY did not work on Windows 2000. I just verified that puTTY and its companion pscp do indeed function just fine on my Windows 2000 Professional SP1 system connecting to a UNIX SSH server, and I apologize for any confusion I may have caused to readers and any ire I may have provoked with the puTTY development effort. Keep up the great work, folks!

See you next month!

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets & Solutions, Second Edition, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.