Absolutely - I never said it was impossible, but the options to do so had their downsides.
-------------------------------------------------------------- Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: Patrick R. Sweeney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2003 10:56 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] downlevel client authentication > > > SetPrfDc can be used to force the secure channel to certain > machines. It doesn't particularly make sense to run on client > machines, but it was useful in an NT 4.0 Master Domain > environment to keep the secure channels between resource > domain Dcs and master Domain DCs site-specific. > > Forcing local authentication is definitely much easier in AD, > but was not impossible in NT 4.0. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Roger Seielstad > Sent: Wednesday, April 02, 2003 10:28 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [ActiveDir] downlevel client authentication > > > You are correct on both counts. > > Terminology-wise, I consider non-AD aware clients as > downlevel, whereas older OS's with the DSClient installed > really aren't downlevel anymore. > > As far as DC order, it will try each of the returned DCs. > There still is no rhyme nor reason to the order in which they > are returned however, so there is little that can be done to > manage which DC authenticates. Frankly, that's one of my > favorite benefits of AD. > > -------------------------------------------------------------- > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis Inc. > > > > -----Original Message----- > > From: Rick Kingslan [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 02, 2003 9:31 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] downlevel client authentication > > > > > > Yes - in reality, it does. > > > > However, I just want to point out the difference when downlevel > > clients have the DS Client applied. It can now change passwords at > > ANY DC. Not just the PDC-E. So, does AD aware in your example > > include those with the DS Client? > > > > And, Roger - correct me if I'm wrong, if the first DC in > the list of > > returned DCs does NOT answer (down, busy), it then moves to > the next > > one in the list. Hence, the behavior that we saw in NT domains is > > still accurate - the PDC didn't do much authentication. Unless, of > > course, if it was the only DC. ;-) > > > > Rick Kingslan MCSE, MCSA, MCT > > Microsoft MVP - Active Directory > > Associate Expert > > Expert Zone - www.microsoft.com/windowsxp/expertzone > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger > > Seielstad > > Sent: Wednesday, April 02, 2003 6:49 AM > > To: '[EMAIL PROTECTED]' > > > > Well, you're all partially correct. > > > > AD (whether mixed mode or not) appears the same as a "straight" NT4 > > domain to all downlevel (i.e. non-AD aware clients). What > that means > > is that the PDC emulator is the only place passwords can be > changed by > > these clients. It also means that any DC can authenticate users. > > > > The thing to keep in mind is how NT4 style domains actually > > authenticate. Assuming WINS is available, a client queries WINS for > > domain controllers who can service the domain to which the > client is > > trying to authenticate (looking for 1Ch records in WINS). > WINS returns > > up to 25 domain controllers > > - in NO particular order - to the client. There is no > > guarantee that the DCs returned will be local to the client. > > > > Does that help at all? > > > > -------------------------------------------------------------- > > Roger D. Seielstad - MCSE > > Sr. Systems Administrator > > Inovis Inc. > > > > > > > -----Original Message----- > > > From: Mike Baudino [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, April 01, 2003 6:23 PM > > > To: [EMAIL PROTECTED] > > > Subject: [ActiveDir] downlevel client authentication > > > > > > > > > All, > > > > > > Please help me resolve a "discussion" with some strong opinions on > > > both sides of the camp. You see, our reading on the role > > of the PDC > > > Emulator in regard to a mixed-mode domain with downlevel clients > > > (we're not upgrading the NT4.0 client > > > software) has left us with differing interpretations. > > > > > > We agree and understand that the PDC Emulator is > contacted directlry > > > > by the downlevel clients to change their passwords. We also > > > understand and agree that the PDC Emulator is the > > source of > > > SAM replication. > > > > > > Our disagreement is in authentication. Some folks are > reading it as > > > > all downlevel client activity, including authentication, > is done at > > > the PDC emulator. Others read this as the downlevel client is > > > authenticated by the domain controller that responds > first (or the > > > last time the client was authenticated [we're also a bit > unclear on > > > that concept]). > > > > > > To me, this is very clear (but I could be the cause of the > > confusion). > > > In a branch office environment running mixed mode we would have a > > > combination of Win2k and NT4.0 domain controllers in the field > > > offices. The NT4.0 BDC's are not aware of the fact that they're > > > really part of an AD domain and nor would the clients. > > Thus, if the > > > client's don't know about AD, and the BDC doesn't know > > about AD, how > > > would the client know that it had to contact the PDC > emulator to be > > > authenticated? It wouldn't. Hence, downlevel client > > authentication > > > must occur at any domain controller (again, the one that responds > > > first [or the last one]). > > > > > > > > > Please help clear this up and please include a link to something > > > that helps clear this up. > > > > > > > > > Thanks, > > > Mike Baudino > > > > > > > > > > > > ******************* PLEASE NOTE ******************* > > > This E-Mail/telefax message and any documents accompanying this > > > transmission may contain privileged and/or confidential > information > > > and is intended solely for the addressee(s) named above. > If you are > > > > not the intended addressee/recipient, you are hereby notified that > > > any use of, disclosure, copying, distribution, or reliance on the > > > contents of this E-Mail/telefax information is strictly > prohibited > > > and may result in legal action against you. Please reply to the > > > sender advising of the error in transmission and immediately > > > delete/destroy the message and any accompanying documents. > > Thank you. > > > > > > > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > > > > > > List info : > > http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > > > List info : > http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%> 40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
