Re: Fast User Switching in Domain Member mode / Authentication Tic

From: Shurick (Shurick_at_discussions.microsoft.com)
Date: 09/26/05 

Date: Sun, 25 Sep 2005 20:28:02 -0700

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

Relevant Pages

  • Re: Help with SSL for Exchange 2003
    ... and Outlook, however, I cannot get SMTP to work properly. ... If I select SSL encryption the error I get is: "Your server does not ... Event Category: Authentication ...
    (microsoft.public.exchange.admin)
  • Re: Handheld device remote networking issues into RAS
    ... I set "Store password using reverisble encryption for all users in the ... This is off by default in server 2003. ... >> The user domain\user failed an authentication attempt due to the ... >> password policy or the password settings on the user account. ...
    (microsoft.public.windows.server.networking)
  • Re: Help with SSL for Exchange 2003
    ... and Outlook, however, I cannot get SMTP to work properly. ... If I select SSL encryption the error I get is: "Your server does not ... Event Category: Authentication ...
    (microsoft.public.exchange.admin)
  • Re: Machine Authentication not working with wireless clients and I
    ... authentication, just the same error as before, about invalid account. ... which communicates with an IAS server via Radius. ... Use your global user account or local user account to access this ... What I would do is create a group of wireless enabled computers. ...
    (microsoft.public.internet.radius)
  • Re: SMTP Access properties
    ... How to Prevent the IIS SMTP Virtual Server from Relaying E-mail Messages ... Click the Access tab, and then under Access control, click Authentication. ... Under Relay restrictions, click Relay. ... the Allow all computers which successfully authenticate ...
    (microsoft.public.inetserver.iis.smtp_nntp)