MCSEGURU
Tue Sep 27 18:42:59 CDT 2005
Theoretically, I see your point, and I think you're right.
However, that's a mighty powerful tool, for the desktop system. I'm all for
features, and at the least expensive price possible, but Terminal Services
is a very expensive software commodity. Your are talking about an enterprise
product there.
While I do concede that in theory, MS must feel from a security standpoint
it is safe to implement considering the technology exists on a Terminal
Server, getting such software at the desktop OS price may be very difficult
to demand until either the open source or 3rd Party community finds a
comparable solution. Please forgive me for siding with the GIANT, but in my
opinion it's not the code we pay for, it's their dedication to support it,
which 3rd Party and Open Source struggles to meet in terms of demand and
expectations.
I don't know if this means anything, but in "Fast User Switching" mode,
terminal services (or remote desktop) is disabled by default. I'm not sure
if it can be bypassed or not, but I would think the theory there is that a
system could easily be transformed into a Terminal Server if all of those
features were cohesively coexisting.
We'll keep our eyes open for the Vista debut.
"Shurick" <Shurick@discussions.microsoft.com> wrote in message
news:E9D2B0BD-1F33-462E-8ECF-F2D0DCAD18CF@microsoft.com...
> Theoretically it must be able in domain. For example, terminal server does
> it
> excelent.
> May be in Windows Vista this feature is working in domain?
>
> "MCSEGURU" wrote:
>
>> Very good detail Steve. I'm glad to have been so educated on the
>> subject.
>> I don't claim to know all.
>>
>> As for the reason for the post:
>>
>> Shurick,
>> As you can see from the efforts of many, unless you are concerned about
>> the
>> things you will lose out on by not being a member of a Domain, you can
>> still
>> somewhat seemlessly implement a workgroup mode computer, and use your
>> fast
>> user switching with very minimal risk to the novice network hacker that
>> may
>> happen to infultrate onto your local area network.
>>
>> I have no problems at all using my home network in this manner (with 6
>> desktop computers and 1 SBS Server)
>>
>> Enjoy,
>>
>>
>> "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message
>> news:%23wZvU34vFHA.1252@TK2MSFTNGP09.phx.gbl...
>> >
>> > "MCSEGURU" <mcseguruhere@aol.com> wrote in message
>> > news:eUxvBkkvFHA.908@tk2msftngp13.phx.gbl...
>> >> OK, I stand corrected (maybe).
>> >> I won't consider myself an expert in the LSA negotiations that take
>> >> place
>> >> between a domain controller and a workstation. However, it was always
>> >> my
>> >> understanding that the member computer had it's own authentication
>> >> method
>> >> to the domain controller which granted the computer access to the
>> >> directory objects, and then the user authenticated on top of that. I
>> >> also made the assumption that the computer authentication method
>> >> established a secure communication channel between the member computer
>> >> and the domain server for further RPC authentication communication.
>> >>
>> >> I workgroup mode, the requests are still tunneled across of the RPC
>> >> communications but do not have a pre-established communication
>> >> channel,
>> >> therefore a public/public encryption method is used (isn't this the
>> >> embedded nt hash algorithm?).
>> >
>> > The "secure channel" is used for among other things passthrough
>> > authentication which would only exist on a domain computer. Workgroup
>> > computers use a challenge/response with a nonce [random string of
>> > characters] that prevents passwords from being transmitted over the
>> > network. The nonce is encrypted by the password hash on both the client
>> > and server. The server compares the encrypted nonce from the client
>> > with
>> > it's own encrypted from the user's password hash it has and if they
>> > match
>> > the user is authenticated. No public key encryption is used. Kerberos
>> > uses
>> > secret keys created from user/computer passwords. Kerberos would use
>> > public/private keys only if smart card logons are enabled for domain
>> > use.
>> > Kerberos is considered more secure than downlevel authentication though
>> > if
>> > ntlmv2 is forced via security policy for lan manager authentication
>> > level
>> > you would have a robust authentication method for workgroup computers.
>> > Regardless of the authentication method the key to network security for
>> > passwords is password strength. A complex password of 15 characters ot
>> > longer is considered extremely secure and would not allow a lm hash to
>> > be
>> > created. If even more security is needed ipsec could be implemented
>> > between workgroup computers. Then computers would need to authenticate
>> > before communications are allowed and the ipsec would encrypt all
>> > unicast
>> > traffic between the computers including user authentication via ESP.
>> >
>> >
>> >> While the authentication ticket is usually the only thing that is ever
>> >> encrypted in both of these scenarios and all other communication
>> >> remains
>> >> un-encrypted in both environments, the authentication ticket between a
>> >> directory server and a member workstation I presume is more secure
>> >> than
>> >> the authentication ticket between two workgroup computers.
>> >
>> > Kerberos tickets are encrypted and used only in an AD domain. There are
>> > no
>> > similar authentication tickets used in a workgroup - only
>> > challenge/response authentication. The kerberos tickets make
>> > authentication more efficient and rely heavily on timestamps to deter
>> > replay attacks and limit the lifetime of the tickets. Klist and
>> > kerbtray
>> > can be used to view kerberos tickets. --- Steve
>> >
>> >
>> >> This is all my presumption and speculation on the little bit of
>> >> understanding I have, and did not mean for it to be percieved as
>> >> absolute
>> >> expert opinion, especially in terms of proper terminology. I do
>> >> challange any EXPERT to explain in detail the actuals pertaining to
>> >> this
>> >> particular part of this thread.
>> >>
>> >> Point to the requestor was that While domain membership has it's
>> >> advantages, if Fast User Switching was that important to him, there
>> >> would
>> >> be a risk involved, and the degree to which I was not absolutely
>> >> certain.
>> >>
>> >> Thanks,
>> >>
>> >>
>> >> "Paul Adare" <padare@newsguy.com> wrote in message
>> >> news:MPG.1d99b17acfee14f4989e8b@msnews.microsoft.com...
>> >>> In article <uZeLM0cvFHA.2568@TK2MSFTNGP10.phx.gbl>, in the
>> >>> microsoft.public.security news group, MCSEGURU <mcseguruhere@aol.com>
>> >>> says...
>> >>>
>> >>>> and therefore does not have the hightened security of a
>> >>>> computer certificate for Kerberos Authentication encryption, and
>> >>>> without
>> >>>> that trust, will send usernames and more importantly passwords
>> >>>> across
>> >>>> the
>> >>>> network much more frequently,
>> >>>>
>> >>>
>> >>> Sorry "guru" but you've got some technical inaccuracies here. A
>> >>> domain
>> >>> environment does not automatically provide certificates for use with
>> >>> Kerberos authentication. That requires a public key infrastructure to
>> >>> be
>> >>> in place, and even then, certificates are only involved in the user,
>> >>> not
>> >>> computer logon process, and only if using a smart card for logon.
>> >>> Secondly, even in a pass-through authentication environment,
>> >>> passwords
>> >>> are _never_ sent across the wire.
>> >>>
>> >>> --
>> >>> Paul Adare
>> >>> MVP - Windows - Virtual Machine
>> >>>
http://www.identit.ca/blogs/paul/
>> >>> "The English language, complete with irony, satire, and sarcasm, has
>> >>> survived for centuries without smileys. Only the new crop of modern
>> >>> computer geeks finds it impossible to detect a joke that is not
>> >>> clearly
>> >>> labeled as such."
>> >>> Ray Shea
>> >>
>> >>
>> >
>> >
>>
>>
>>