[KLUG Members] re: NTFS5

[Mike Williams]

>Message: 5
>Date: Sun, 05 Aug 2001 15:31:41 -0400
>From: "Bryan J. Smith" <b.j.smith@ieee.org>
>Organization: SmithConcepts, Inc.
>To: members@kalamazoolinux.org
>Subject: Re: [KLUG Members] NTFS5
>Reply-To: members@kalamazoolinux.org
>
>Mike Williams wrote:
>> Do you know if it can read any of the Active Directory
>> special folders?  Most of them require NTFS5, so they're
>> probably using the new tricks.
>
>God I'm so "out of the loop" these days.  I remember testing
>Microsoft's Distributed Filesystem (DFS) on NT 4.0 and seeing is
>crash my servers almost daily.  Supposedly it is much better in
>Win2K and you _can_ use it without ActiveDirectory(?).  Are those
>the "special files" you are talking about?  Samba 2.2 can implement
>DFS and uses such special files, but I have a feeling that you're
>talking about additional capabilities beyond just DFS.  Again, I
>haven't seriously messed with Win2K/AD since NT 5.0 beta 2.

Err, no, I wasn't even considering DFS.  There is a "Shared System Folder" named SYSVOL that holds the data that is replicated between domain controllers.  This folder requires NTFS 5.  There is also an AD database and log, but they can be on any filesystem.  

>> Unless you have access to a w2k Domain Controller hard drive,
>> though, you probably can't find out.
>
>It might be an interesting experiment to clone a W2K drive and toy
>with it under Linux.  I chucked NT Servers in mid-1999 (after 8
>years of supporting them, yes, before the original NT 3.1's release)
>so I wouldn't know anymore.

It definitely would.  I've got a practice W2k server here, with a Linux box next to it.  It would be pretty simple to move the hard drive and see what happens.  Since it's only a practice server I can do it without getting in too much trouble.  

>> I think the changes from NTFS 4 to NTFS 5 were fairly minor.
>> Added support for some new tricks like encryption, but when
>> they're not used the filesystem probably acts the same as
>> NTFS 4.  Read / write access would be probably be dangerous
>> to attempt yet.
>
>I think the "dangerous" part, at least with NTFS v4, was always the
>tying of attributes in the filesystem to the registry.  As such,
>even if Linux's NTFS support completely understands everything about
>the filesystem, you still have to tie various attributes and sectors
>to registry settings.  Touching the wrong thing can lead to a
>screwed up server and/or an unbootable one.

What sort of file system data is stored in the registry?  I remember OS/2's HPFS, which is a close cousin of NTFS, supported "extended attributes."  I always assumed that security data, compression flags, ACLs and such were stored in the NTFS equivalent of EA's.  As a useless aside, how is OS/2 HPFS support on Linux?

>> I'm going from memory here, but I think the key is only loaded
>> when needed.
>
>But the fact remains that that key is on disk.  Encrypted or not,
>you can still get to it, because there must be some key (or in a
>"plain area").  Unless it actually prompts you for it?

I haven't messed with it, but I believe it is automatic, so yes, the key is stored on some other area of the filesystem.  How else would you do it, though?  It's probably in a system-only area of the disk, for what that's worth.  See below, for details, but it can also be stored on smartcard or some other medium.

>> I think the key is related (if not identical) to the user's unique ID#.
>> This means that if you delete a user account, even if you remember his
>> name and password, any data in his encrypted folders are forever gone.
>
>Er, with NT through 4.0, I could find out even a user ID (UID) of a
>deleted user.  I know, I've done it several times to "resurrect" a
>user that some smuckie decided to permanently delete (never do that,
>even on UNIX -- always leave the account there).  You actually need
>a combination of the system ID, or SID, and the UID).  So unless the
>sysadmin or another key is chosen and all his files are
>re-encrypted, then it is possible to get at the files.

That's a neat trick.  Probably not worth cluttering the mail list for it, but I'd be very interested in knowing the details of that stunt.

>And were still not talking the "root" of the problem here. 
>Individual user passwords' "password equivalent" can be sniffed on
>the wire, unless you are using Win2K/AD in non-legacy mode.  If you
>are using Win2K/AD with "legacy NT/9x compatibility," then the
>password is sent over the wire as a 32-byte "password equivalent"
>that can be used to access any share where they have access.  Using
>Kerberos ticketing improves the security issues with this (as it
>allows trusts to be setup), but there are still ways about this. 
>And if you have "superuser" privaledges, UNIX or NT, you _can_ get
>at those files.
>
>But that's not really what I'm talking about, the "run-time"
>aspect.  What I'm talking about is the "down-time" aspect.  An
>unmounted, encrypted filesystem in Linux requires an user-specified
>key (at least when I've done it over the loopback device).  If that
>filesystem is not mounted, it is _very_difficult_ to get at that
>key.  In Win2K NTFS v5, the filesystem still uses an autonomously
>loaded key when it mounts an encrypted filesystem -- no user
>interaction, no key pair used.  As such, that key can be found and
>extracted eventually with analysis of the filesystem (or registry).
>
>But I've been "out of the loop" with Win2K for awhile, and I'm open
>to being proven wrong.  I just don't trust so-called "encrypted"
>filesystems when you don't provide a key (and it is stored on-disk).

Does it help if it's a public / private implementation?  The following snippets are quoted from my MCSE 2000 study guide:  "EFS is based on public key encryption, which encrupts each file with a randomly generated key that is separated from the user's pbulic/private key pair.  ... When a user opens an encrypted file, EFS automatically locates teh user's key from the system's key to store the decrypt file.  EFS is very difficult to decipher as it uses CryptoAPI architecture. CAPI ... permits applications to digitally sign or encrypt data while providing security for the user's private key data.  ... EFS users two pairs of keys for the recovery policy:   They user key pair, which is generated locally, and the recovery key pair that is issued by your CA."

Does this make sense to you guys?  I haven't actually gotten to that part of the book, so I didn't really absorb much of what I was typing there.  It looks like the keys used to crypt the files are themselves crypted with the user's public / private keys.  You can also store the encryption keys on smartcards or something rather than on the disk.