Re: Fast User Switching in Domain Member mode / Authentication Ticket security risks

From: Steven L Umbach (n9rou_at_nospam-comcast.net)
Date: 09/22/05

  • Next message: MCSEGURU: "Re: Fast User Switching in Domain Member mode / Authentication Ticket security risks" 
    Date: Thu, 22 Sep 2005 10:53:18 -0500

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

  • Next message: MCSEGURU: "Re: Fast User Switching in Domain Member mode / Authentication Ticket security risks"

    Relevant Pages

    • Re: Encryption and authentication
      ... have encryption without authentication? ... it seems that encryption couldn't exist without authentication. ... and example is asymmetric key cryptography technology. ... http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked ...
      (comp.security.firewalls)
    • Re: Signatures and encryption headers
      ... breached when an attacker can modify the message received? ... But I see how the lack of authentication can cause the receiver to act ... not for the iv or other encryption ... A create a payload, S signs it with public key crypto (most likely ...
      (sci.crypt)
    • Re: Ciphers and their effect on the size of data
      ... We have a security-sensitive client that is wants common authentication between a J2EE environment and a "fat windows client". ... we'll also be facing 4/3 expansion of the payload after encryption. ... This password field will include a digital signature, or the digital signature will be in another XML element in that document. ...
      (sci.crypt)
    • Re: Ciphers and their effect on the size of data
      ... The user goes to the J2EE server, ... and submit them to the UNIX-hosted service for authentication. ... authenticate to the J2EE environment first, ... facing 4/3 expansion of the payload after encryption (for base64 ...
      (sci.crypt)
    • Re: Fast User Switching in Domain Member mode / Authentication Ticket security risks
      ... > understanding that the member computer had it's own authentication method ... No public key encryption is used. ... Kerberos would use public/private keys ... Kerberos tickets are encrypted and used only in an AD domain. ...
      (microsoft.public.platformsdk.security)