"auto" for Kerberos, a history

Rowland penny rpenny at samba.org
Thu Aug 20 07:08:10 UTC 2020

On 20/08/2020 07:53, Stefan Metzmacher wrote:
> Am 20.08.20 um 08:30 schrieb Rowland penny via samba-technical:
>> On 19/08/2020 23:10, Andrew Bartlett wrote:
>>> On Wed, 2020-08-19 at 22:13 +0100, Rowland penny via samba-technical
>>> wrote:
>>>>        -k KERBEROS, --kerberos=KERBEROS
>>>>                            Use Kerberos
>>>> If you check the code, 'KERBEROS' is actually 'yes', 'auto' or 'no'
>>>> What is 'auto' in this context ? surely using kerberos is binary,
>>>> you
>>>> either want to use it, or you don't, 'yes' or 'no', so what does
>>>> 'auto'
>>>> actually mean and do ?
>>>> Do we really need 'auto', can we not decide what the parameter
>>>> defaults
>>>> (for instance) should be and remove 'auto' ?
>>> In this context, the current code behaviour is to try and obtain a
>>> kerberos ticket, but to fall back to NTLM as 'good enough protection'
>>> if this fails, for example if no KDC can be reached, or this is an IP
>>> address, or if the server does not offer Kerberos as an authentication
>>> type.
>>> The idea (when this was written) was to at least try Kerberos, rather
>>> than continuing to default to NTLM only.  (And on the flip side, to
>>> continue to work in the many - at the time - networks where AD was
>>> functioning only with NTLM).
>>> Andrew Bartlett
>> Why not just set the default to 'yes' and if this fails, fall back to NTLM, this is what 'auto' seems to mean. To me, 'auto' is confusing and to top it off, it doesn't seem
>> to be documented anywhere.
> yes means no fallback to NTLM,
That makes sense
> Should we use "disabled", "if_available", "required"
> instead of "no", "auto", "yes"?
> metze

Why not just use 'if_available' instead of 'auto', it makes more sense. 
'auto' is short for 'automatic', but 'automatic' what ?

'no' == Never use kerberos

'yes' == Only use kerberos

'if_available' == Try kerberos, but fall back to NTLM if kerberos is not 


More information about the samba-technical mailing list