Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
On Sat, 2003-03-22 at 06:15, Matt Peterson wrote: > Hi, > > In situations where people are operating in a "kerberized" environment where > Win2k is the KDC, machine objects will have already been created for machines > that are participating in the kerberos realm. > > Am I wrong in thinking that there is an interoperability problem with the > current "net" utility implementation? It appears as though the "net ads > join", and net ads chostpass" commands operate with out regard to the fact > that there may be other applications that rely on keytab files with host > principals and passwords that have already been set. > > Indeed, this is the case for installations where Win2k kerberos interop is > already being used. When trying to configure Samba 3.0 in these > environments, "net ads join", and net ads chostpass" will happily change the > machine account password with out allowing any way for keytab based > applications to update their keytab with tne new host principal password. Yes. This is a problem. In the past I have favored a 'krb5 keytab write' option that would write our password out into the standard keytab, but there were good reasons not to. The problem is, I can't remember what they were. Mostly 'if somebody changed our password under us' stuff. > Samba could allow for a much greater degree of interopablity with other > kerberized applications if there were some way of getting and setting the > machine account password in the secrets.tdb. This way host principal > passwords in external keytab files could be syncronized with the password > being used by samba from the secrets.tdb. > > Perhaps this is an overly simplistic approach, but it is possible that many > potential interoperablity conflicts could be solved by providing "net > getmachinepw" and "net setmachinepw" commands. Since the machine account > password is stored in clear text already, these new commands would be very > easy add. Patches welcome, the last 2 we should have, no matter the long term solution. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
>Yes. This is a problem. In the past I have favored a 'krb5 keytab >write' option that would write our password out into the standard >keytab, but there were good reasons not to. The problem is, I can't >remember what they were. Mostly 'if somebody changed our password under >us' stuff. Hmm, why would this be a problem? (I mean, I can understand it would be a problem if it happened while SAMBA was running, but keytabs tend to be fairly static...) -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
Andrew, On Friday 21 March 2003 03:12 pm, Andrew Bartlett wrote: > On Sat, 2003-03-22 at 06:15, Matt Peterson wrote: > > Hi, > > > > In situations where people are operating in a "kerberized" environment > > where Win2k is the KDC, machine objects will have already been created > > for machines that are participating in the kerberos realm. > > > > Am I wrong in thinking that there is an interoperability problem with the > > current "net" utility implementation? It appears as though the "net ads > > join", and net ads chostpass" commands operate with out regard to the > > fact that there may be other applications that rely on keytab files with > > host principals and passwords that have already been set. > > > > Indeed, this is the case for installations where Win2k kerberos interop > > is already being used. When trying to configure Samba 3.0 in these > > environments, "net ads join", and net ads chostpass" will happily change > > the machine account password with out allowing any way for keytab based > > applications to update their keytab with tne new host principal password. > > Yes. This is a problem. In the past I have favored a 'krb5 keytab > write' option that would write our password out into the standard > keytab, but there were good reasons not to. The problem is, I can't > remember what they were. Mostly 'if somebody changed our password under > us' stuff. One problem with this approach is the question of "where is standard keytab?". It turns out that with both MIT and Heimdal, the location of the "standard" keytab can be set with an environment variable and in the krb5.conf file. Is suppose that you could use the the MIT/Heimdal keytab APIs and allow the implementation to figure this out for you... > > Samba could allow for a much greater degree of interopablity with other > > kerberized applications if there were some way of getting and setting the > > machine account password in the secrets.tdb. This way host principal > > passwords in external keytab files could be syncronized with the password > > being used by samba from the secrets.tdb. > > > > Perhaps this is an overly simplistic approach, but it is possible that > > many potential interoperablity conflicts could be solved by providing > > "net getmachinepw" and "net setmachinepw" commands. Since the machine > > account password is stored in clear text already, these new commands > > would be very easy add. > > Patches welcome, the last 2 we should have, no matter the long term > solution. I will send the patch first on Monday. Cheers, -- Matt
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
On Sat, 2003-03-22 at 09:13, Luke Howard wrote: > > >Yes. This is a problem. In the past I have favored a 'krb5 keytab > >write' option that would write our password out into the standard > >keytab, but there were good reasons not to. The problem is, I can't > >remember what they were. Mostly 'if somebody changed our password under > >us' stuff. > > Hmm, why would this be a problem? (I mean, I can understand it would be > a problem if it happened while SAMBA was running, but keytabs tend to be > fairly static...) Yes - I think the benefit (getting real kerberos authentication working on unix in ADS) outweighs the 'risk' here. Now, all somebody needs to do is write up the patch or dig one up that's already done... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
>Yes - I think the benefit (getting real kerberos authentication working >on unix in ADS) outweighs the 'risk' here. > >Now, all somebody needs to do is write up the patch or dig one up that's >already done... Well, we've submitted read-only keytab patches on a few occasions, albeit as compile-time options. Adding support for writing to the keytab and/or runtime support for the keytab remains to be done... -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
I really don't think that putting keytab code in to Samba is the right answer. Do you really want to be in charge of modifying keytabs? This could get quite complicate -- especially when you multiply the effort by the number of possible encryption types... On Friday 21 March 2003 04:14 pm, Luke Howard wrote: > >Yes - I think the benefit (getting real kerberos authentication working > >on unix in ADS) outweighs the 'risk' here. > > > >Now, all somebody needs to do is write up the patch or dig one up that's > >already done... > > Well, we've submitted read-only keytab patches on a few occasions, albeit > as compile-time options. > > Adding support for writing to the keytab and/or runtime support for the > keytab remains to be done... > > -- Luke
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
>I really don't think that putting keytab code in to Samba is the right answer. >Do you really want to be in charge of modifying keytabs? This could get >quite complicate -- especially when you multiply the effort by the number of >possible encryption types... I don't think it's that complicated. It is not difficult to enumerate the supported encryption types. Moreover, there's no requirement that SAMBA use the same keytab as other applications, or that keytab support completely replace the secret store. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
On Tue, 2003-03-25 at 22:36, Luke Howard wrote: > > >I really don't think that putting keytab code in to Samba is the right answer. > >Do you really want to be in charge of modifying keytabs? This could get > >quite complicate -- especially when you multiply the effort by the number of > >possible encryption types... > > I don't think it's that complicated. It is not difficult to enumerate the > supported encryption types. Moreover, there's no requirement that SAMBA use > the same keytab as other applications, or that keytab support completely > replace the secret store. I agree that if Samba is changing the password for a particular kerberos principal, then it should store the hashes in the keytab. The idea of *finally* getting kerberos useful on real sites is just too appealing :-) Naturally, the original plaintext password should stay basically where it is. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
>I agree that if Samba is changing the password for a particular kerberos >principal, then it should store the hashes in the keytab. > >The idea of *finally* getting kerberos useful on real sites is just too >appealing :-) > >Naturally, the original plaintext password should stay basically where >it is. In that case, perhaps it *is* better just to provide a get/set command line tool for the secret store rather than trying to hook the keytab into SAMBA per se. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Machine account password interoperablity for Samba 3.0secrets.tdb and keytabs
On Tue, 2003-03-25 at 22:55, Luke Howard wrote: > > >I agree that if Samba is changing the password for a particular kerberos > >principal, then it should store the hashes in the keytab. > > > >The idea of *finally* getting kerberos useful on real sites is just too > >appealing :-) > > > >Naturally, the original plaintext password should stay basically where > >it is. > > In that case, perhaps it *is* better just to provide a get/set command line > tool for the secret store rather than trying to hook the keytab into SAMBA > per se. Well, I think we should provide both, but if Samba just changed the password for a principal, I see no harm in setting the password into the keytab, when selected by the admin. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
