|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Can i run more then one session on the computer?Multiple sessions is pretty feature of XP. In domain environment its not
working by default. How can i use this feature in domain environment? May be Vista can help me? Hello Shurick,
you mean fast user switching? this is disbled domain environments - yes in Vista this works. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Multiple sessions is pretty feature of XP. In domain environment its > not working by default. How can i use this feature in domain > environment? May be Vista can help me? > You can't. By default, Fast User Switching is administratively disabled by
the OS when you join a domain. MS will not allow this service to run when in "Domain" mode. The theory is that network connections may be able to be shared across the different users, using the computer, and this weakens the client/server security. However, you can do what I do. Leave your computer's in workgroup mode, just as long as their workgroup is the exact same name as the domain you would be joining them to. Ensure all the local passwords on the PC's match the passwords on the Domain Server, and it works wonderfully. Now I wouldn't take this solution to the bank just yet. There are risks associated with this solution. The security between client and server is weakened with this solution, as the client computer is no longer an Active Directory object, 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, however you are never prompted, and if on the wire security is not a huge issue for you, I would think you could accept these risks and implement the solution. I myself accept the risk, cause I don't see how anyone's going to sniff me out. I'd have to let them in the door first, ya know. The old pysical security vs. data security argument. As far as the shared network access thing why the service is disabled win Domain mode, I myself have not seen the network connections security contexts to be a problem, when my wife uses my computer, she definately doesn't have access to my porn, I've tried, so maybe MS has another reason for disabling it. I really don't know. Show quoteHide quote "Shurick" <Shur***@discussions.microsoft.com> wrote in message news:E74C501D-4D6D-451A-867D-0C1DE8030EC9@microsoft.com... > Multiple sessions is pretty feature of XP. In domain environment its not > working by default. How can i use this feature in domain environment? May > be > Vista can help me? In article <uZeLM0cvFHA.2***@TK2MSFTNGP10.phx.gbl>, in the
microsoft.public.security news group, MCSEGURU <mcseguruh***@aol.com> says... > and therefore does not have the hightened security of a Sorry "guru" but you've got some technical inaccuracies here. A domain > computer certificate for Kerberos Authentication encryption, and without > that trust, will send usernames and more importantly passwords across the > network much more frequently, > 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 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?). 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. 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, Show quoteHide quote "Paul Adare" <pad***@newsguy.com> wrote in message news:MPG.1d99b17acfee14f4989e8b@msnews.microsoft.com... > In article <uZeLM0cvFHA.2***@TK2MSFTNGP10.phx.gbl>, in the > microsoft.public.security news group, MCSEGURU <mcseguruh***@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
Show quote
Hide quote
"MCSEGURU" <mcseguruh***@aol.com> wrote in message The "secure channel" is used for among other things passthrough 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?). 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 Kerberos tickets are encrypted and used only in an AD domain. There are no > 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. 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 Show quoteHide quote > 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" <pad***@newsguy.com> wrote in message > news:MPG.1d99b17acfee14f4989e8b@msnews.microsoft.com... >> In article <uZeLM0cvFHA.2***@TK2MSFTNGP10.phx.gbl>, in the >> microsoft.public.security news group, MCSEGURU <mcseguruh***@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 > > 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, Show quoteHide quote "Steven L Umbach" <n9rou@nospam-comcast.net> wrote in message news:%23wZvU34vFHA.1252@TK2MSFTNGP09.phx.gbl... > > "MCSEGURU" <mcseguruh***@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" <pad***@newsguy.com> wrote in message >> news:MPG.1d99b17acfee14f4989e8b@msnews.microsoft.com... >>> In article <uZeLM0cvFHA.2***@TK2MSFTNGP10.phx.gbl>, in the >>> microsoft.public.security news group, MCSEGURU <mcseguruh***@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 >> >> > > 
Other interesting topics
Importance of salt
xml based AzMan and ActiveDirectory Is WindowsPrincipal is Remotable ? Unable to run c++ .net executable from a network drive hooked to server Windows Security pops up when executing javascript in an asp.net p .NET 2.0: code access security / authentication data size and RSA encryption Delegation across trusted domains Problems trying to write to Custom Eventlog must use weak key in 3des |
|||||||||||||||||||||||
