[KLUG Members] NTFS5

[Bryan J. Smith]

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.

> 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.

> 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.

> 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 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.

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).

-- TheBS

-- 
Bryan "TheBS" Smith     mailto:b.j.smith@ieee.org     chat:thebs413
Engineer   Absolute Value Systems, Inc.   http://www.linux-wlan.org
President     SmithConcepts, Inc.      http://www.SmithConcepts.com