RE: [e-smith-devinfo] My Samba howtos
Greg, I don't quite understand this concept of Samba removing a machine account from the domain when that machine leaves the domain. I may be on thin ice here to some extent David. I read this some time ago in a series of posts on the Samba development mailing list and later in a tech doc written by a member of the samba team. The issue centered around a machine leaving a domain, then trying, unsuccessfully, to rejoin the domain. The problem was then when a machine joins a domain, a random machine password is created and stored in the client Win registry (for samba clients, this password is stored in MACHINE.SID) and the smbpasswd file. When the machine leaves the samba domain and then tries to rejoin again, it regenerates a new random machine password that doesn't match the machine password in smbpasswd database. What you end up having to do is open the smbpasswd file in an editor and delete the machine password by hand(note, you leave the machine account in the passwd file), then attempt the joing. As I understand the direction that Samba is headed, I believe t they are working on a mechanism to automate the process. That is what I was referring to by removing machine accounts. I figured, how would the server know that the machine had left the domain. Good point... However,some type of transfer must take place in order for machine passwords to be reset on a Win NT PDC. I think this is part of the battle that the Samba team has had to deal with in reverse engineering Windows RPC calls. Another thing to consider is that Samba is using scripts for users to control both user and machine accounts, so I'm not sure what would prompt samba to execute a delete user script. I'm not sure of the mechanism for doing this either. Again, as the Samba guys continue to figure out the Win RPC this will likely become clear. All of this happens under the hood on a win domain, so it must be possible. Have a good one. Greg -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
On Friday, September 28, 2001 7:47 AM, Greg Zartman wrote: When the machine leaves the samba domain and then tries to rejoin again, it regenerates a new random machine password that doesn't match the machine password in smbpasswd database. snip Good point... However,some type of transfer must take place in order for machine passwords to be reset on a Win NT PDC. I guess this is where I am getting confused. I did some testing with a Win2000 Service Pack 2 client to confirm my thoughts, and here's what I found: With Samba as the PDC running with Dan Brown's How-To 2, you can join the domain, which created the unix and samba passwords, as well as adding the machine account in the e-smith accounts database. When you leave the domain and change to a workgroup, nothing is changed on the server side. When you re-join the domain, samba re-generates a different random password that it stores in smbpasswd, overwriting the previous password, and things proceed as normal. Presumably, some form of this new password is stored in the windows registry in the place of the previous one, since I had no trouble logging on with my domain user accounts. Next, I tried changing the computer name and joining the domain, which simply created a different machine account, as well as new unix and samba passwords. Again, I changed to a workgroup and then re-joined the domain, with the same results. Nothing was ever removed (at least to my knowledge) in the form of user accounts or passwords. Now for a *little* background on WinNT/2000 SIDs as I understand them. WinNT/2000 machines generate partial SIDs at install time that are based on who knows what, but they are intended to be somewhat unique. I say partial because the final piece of a SID is generated when the WinNT/2000 machine connects to a primary domain controller, and that final piece is generated by the server, not the client. This final SID is unique across space and time according to Microsoft. This is why cloning of WinNT/2000 machines (using Ghost, etc.) is much better before the original machine has connected to a domain. Otherwise, all the clones have to have major registry tweaks to make them unique. It looks like samba is simply re-generating this key portion of the SID and giving this back to the client to replace the original one. I may be over simplifying this whole issue, but the basics are accurate. Based on all this, I think that there is no real need to delete the machine accounts from the domain, except to keep the appropriate files and databases clean. David M. Brown Frick, Frick Jetté Architects [EMAIL PROTECTED] -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
When you leave the domain and change to a workgroup, nothing is changed on the server side. When you re-join the domain, samba re-generates a different random password that it stores in smbpasswd, overwriting the previous password, and things proceed as normal. Presumably, some form of this new password is stored in the windows registry in the place of the previous one, since I had no trouble logging on with my domain user accounts. Very good, looks like my information is out of date.. Good experiment!! I was drawing from David Bannon's documentation on Samba 2.2.0 and the NT Domains artical by Jeremy Allison (and some personal experience of having to modify my smbpasswd file when I first started using samba). Looks like they implemented the plan. I guess this explains why I haven't seen many posts on the Samba Domains mailing list for awhile from people having a problem re-joining a domain after leave... :o) Now the fun part is going to be chucking all of this out the door when WinBind hit the street. Have a good one. Greg -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
I don't think this is correct. The biggest danger I see is that the e-smith manager would (try to) create a regular user account with the same name as a machine account, and only be able to partially create that account. I stand to be corrected, but machine accounts registered in the unix and samba password databases are appended with a $ at the end of the machine name. This design feature of samba was created to avoid the situation you describe. In fact, in my samba network, my login name is greg and my workstation's netbios name is greg. Both exist in the appropriate username databases without issue because my machine name is listed as greg$ (not greg). Further, I think that integrating the Samba machine account process with e-smith way of doing things is only asking for further development to SME in the future. In the near future, Samba will likely have the ability to remove machine accounts when a machine leaves the domain, thus creating a hole in the SME user account structure. Regards, Greg J. Zartman -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
Greg, I don't quite understand this concept of Samba removing a machine account from the domain when that machine leaves the domain. From what I have observer with a small WinNT domain with a WinNT 4.0 Server acting as the PDC, client machines can leave the domain i.e. change to a workgroup, but the computer account is still listed under the Server Manager, and that same computer can re-join the domain as if nothing had been changed. While I was looking for info on Samba's add user script to get it working, I came across the delete user script, which I figured could be useful tool to clean up the machine accounts on the Samba server when computers leave, but then I figured, how would the server know that the machine had left the domain. AFAIK, there isn't any communication between the client leaving the domain and the server controlling the domain. Another thing to consider is that Samba is using scripts for users to control both user and machine accounts, so I'm not sure what would prompt samba to execute a delete user script. Also, as a side point, it is not Samba that adds the trailing $, but Windows. This is how they designate hidden shares, and the %u value samba uses is taken directly from the information supplied to it by Windows. The trouble we've been having is that the machine-account-create script was adding a trailing $ to the entry in smbpasswd, giving us machinename$$. Now that some of these issues are worked out the e-smith way, you should be able to have user greg and machine greg$ without any trouble. Just some food for thought. David M. Brown Frick, Frick Jetté Architects [EMAIL PROTECTED] -Original Message- From: Greg J. Zartman [mailto:[EMAIL PROTECTED]] Sent: Friday, September 28, 2001 5:19 AM To: Dan Brown Cc: e-smith-devinfo Subject: RE: [e-smith-devinfo] My Samba howtos In the near future, Samba will likely have the ability to remove machine accounts when a machine leaves the domain, thus creating a hole in the SME user account structure. -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 From: Greg J. Zartman [mailto:[EMAIL PROTECTED]] Further, I think the bypass approach is the better one as it seems more I don't think this is correct. The biggest danger I see is that the e-smith manager would (try to) create a regular user account with the same name as a machine account, and only be able to partially create that account. By adding the account to the e-smith user database, this is avoided. add machines accounts, but I would hate for these accounts to show up in the server manager along with user accounts (as often happens with X They shouldn't--there's an entry in the accounts database that identifies them as machine accounts, and I expect the user accounts panel skips those. So long as it can be made to work properly, which I think is now the case with David's suggestions, it seems that there's nothing to lose by going the e-smith way, and possibly something to gain. -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBO7PvMX6CI7gsQbX8EQIAgwCgj09PH7bcj/mbdkQUjqVRn1WvpHwAoPct 19uTPd7omSY1/5xpGUtZUeFl =5TsJ -END PGP SIGNATURE- -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
RE: [e-smith-devinfo] My Samba howtos
Second, the add user script on the first completely bypasses the normal e-smith mechanisms and works for some users, while the add user script from the second one tries to use the e-smith way and doesn't seem to work for anybody. The method that you outline in your howto that bypasses the e-smith way of doing things should work for 95%+ of users provided Samba is in fact running as a PDC and two things happen on the client machine when joining the domain: 1. The user MUST be logged on the Win NT/2000 machine as the administrator. 2. When prompted to authenticate addition the machine to the domain, the user MUST input the root username and password. The e-smith admin account, or any other for that matter, will not work. If the user neglects to do either of the above, Windows will report a totally unrelated error message and the machine will not be added to the domain (This error message reported will likely get better over time as the Samba team reverse engineers more and more of the Win 2000 RPC specs) Further, I think the bypass approach is the better one as it seems more inline with my understanding of the development path of Samba. It's my understanding that the Samba team plans to build functionality into Samba to remove machine accounts from smbpasswd and passwd when a machine leaves the domain. I'm not very familiar with the scripts that Mitel has developed to add machines accounts, but I would hate for these accounts to show up in the server manager along with user accounts (as often happens with X Window user account apps). It would really clutter things. Regards, Greg J. Zartman, P.E. Vice-President Logging Engineering International, Inc. 1243 West 7th Avenue Eugene, Oregon 97402 541-683-8383 Fax 541-683-8144 Web: www.leiinc.com -Original Message- From: Gordon Rowell [mailto:[EMAIL PROTECTED]] Sent: Friday, 21 September 2001 2:55 PM To: Smith, Jeffery S (Scott) Cc: Darrell May; Dan Brown; e-smith-devinfo Subject: Re: [e-smith-devinfo] SME5 breaks RAV for some users On Fri, Sep 21, 2001 at 05:42:30PM -0400, Smith, Jeffery S (Scott) [EMAIL PROTECTED] wrote: Question: Does the qmail license allow for differentiation between distribution/installation and configuration? IANAL, yes. If I install qmail as per make install and sell or distribute a system, this is obviously not a license violation. IANAL, correct. Now, what happens if once this system is installed at a user's site, the user then elects to modify it so that qmail is not in a make install state? Has the user violated the license? Is this not allowed, perhaps to replace a script or binary with one of their own making, or to relocate a utility to another path? Yes, users are completely at liberty to modify their own systems. The restriction is on _distributing_ a modified qmail. If the above is not disallowed, then is it a license violation for an application installed by the user subsequent to qmail to make a similar modification? I don't believe so. I believe that what RAV is doing is fine, as long as the end-user chooses to install it. Bundling RAV (and thus bundling a modification to qmail) would be a problem. If qmail is installed, and RAV is installed, and then the system delivered, and then the user chooses to run an RPM that makes the two work together -- I fail to see how this is a problem. I can see the problem if the two packages and installed and integrated prior to distribution, but one in the user's possession it seems odd that it would be any kind of license violation. IANAL, but correct. The issue is _user_ choice. If a user chooses to install something which modifies qmail, that is their choice. And, of course, I could be wrong. I'm mostly just curious as I've heard many times how restrictive the qmail license is. Gordon -- Gordon Rowell[EMAIL PROTECTED] VP Engineering Network Server Solutions Group http://www.e-smith.com Mitel Networks Corporation http://www.mitel.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
