Erik Price wrote: >>Because upon restarting the machine and booting back into Win2k, I >>discovered that I couldn't even log into the machine! It turns out >>that at my company, the login is controlled by something called a >>"domain", which is some kind of network-based authentication system. >>I >>don't really understand it myself. I ended up having to call tech >>support and they managed to help me get it all online, apparently by >>forcing the machine to accept DHCP again. >> >>Does anyone know how to get Linux to work cooperatively alongside >>this >>MS "domain" business? In other words, I could boot right back into >>Linux and execute "/etc/init.d/networking restart" again, and be >>using >>the web from Linux, but then when I go back to Windows I'm going to >>have a problem. And I can't keep calling tech support for this. >>Surely there is another on this list who knows how to handle these >>"domains".
In the domain model, the login athentication is not (usually) handled by the local Windows PC; rather, the local box passes the username/password to a domain controller (Primary Domain Controller (PDC) or Backup Domain Controller (BDC)) somewhere in the network. This Domain Controller (DC) is a server that the system administrators have set up somewhere on your network. The DC then checks to make sure you're an approved user and that your password is correct, then sends a signal back down to the local computer saying it's okay for the computer to let you log in and use that computer. It also manages such things as what rights you have to access certain network resources (shared directories, printers, etc). This way, instead of the tech support guys having to go to each machine that you might theoretically log into and add you as a valid user (and then go around and synch your password if you were to ever change it), they have a centralized database that keeps track of you and your password and your rights. Microsoft has moved from the Domain model to the Active Directory model, but much of the world has not yet made the transition. The same sort of thing can be done in a more standardized model with other tools, such as LDAP (of which Active Directory is supposedly compliant), but which method is used is determined by the system admins, not by the users, so you're stuck working in the Domain model. Nonetheless, that shouldn't be an issue. Your Windows side should be unaffected by anything you do on the Linux side, and your Linux side does not need to play with the Domain, inasmuch as you can set it up to let you log in locally, without authenticating through a centralized server. Of course, this means if you go to your neighbor's Linux box, you won't be able to log in there unless he has set you up to do so, whereas you could log into his Windows box, because he doesn't control that; the sys admins (via the domain) control it. Unless you gave the Linux box the same name as the Windows side, AND added it to the Windows domain (I'd guesstimate a 0.0002% chance that happened - in other words, it didn't), OR unless the Windows domain is doing something odd with the MAC address of your NIC (also highly unlikely), anything you do on the Linux side will have absolutely no affect on the Windows side. In other words, I can say with a high degree of confidence, your Windows problem was simply a coincidence. If it should happen again, I'll gladly retract this claim. Before trying it, add yourself a local account on the Windows box (assuming you're an Admin on the local box, and add your local account to the local Administrators group), so that if it does happen again, you can log in locally, bypassing the domain authentication. Then bring up a command prompt, and type "ipconfig" to see what your current IP settings are. If necessary, "ipconfig /release" followed by "ipconfig /renew" should renew your DHCP settings. (Depending on your version of Windows, it might be "winipcfg" instead of "ipconfig".) Kent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
