[Freeipa-users] cannot access to freeipa client's linux share from windows

Fujisan fujisan43 at gmail.com
Fri Dec 2 10:28:49 UTC 2016


Ok so why is it still not working?
Any suggestion?

On Fri, Dec 2, 2016 at 11:20 AM, Alexander Bokovoy <abokovoy at redhat.com>
wrote:

> On pe, 02 joulu 2016, Fujisan wrote:
>
>> I'm not sure my problem is linked to this 'dedicated keytab file' with
>> FILE: before the path to keytab file.
>>
> Yes, it does. Your client log below reports that the server cannot
> communicate with you because _the_server_ is unable to read its keytab
> when initializing GENSEC backed gssapi_krb5 and thus client switches to
> SPNEGO which also fails as the server cannot work without proper keytab
> using kerberos and password-based auth is not possible.
>
>
>
>> # smbclient -d3 -L \\10.0.21.200  -U smith
>> lp_load_ex: refreshing parameters
>> Initialising global parameters
>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
>> Processing section "[global]"
>> lp_load_ex: changing to config backend registry
>> Initialising global parameters
>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
>> lp_load_ex: refreshing parameters
>> Initialising global parameters
>> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
>> Processing section "[global]"
>> added interface eno1 ip=10.0.21.18 bcast=10.0.21.31
>> netmask=255.255.255.240
>> Client started (version 4.5.1).
>> Enter smith's password:
>> Connecting to 10.0.21.200 at port 445
>> Doing spnego session setup (blob length=74)
>> got OID=1.3.6.1.4.1.311.2.2.10
>> got principal=not_defined_in_RFC4178 at please_ignore
>> GENSEC backend 'gssapi_spnego' registered
>> GENSEC backend 'gssapi_krb5' registered
>> GENSEC backend 'gssapi_krb5_sasl' registered
>> GENSEC backend 'spnego' registered
>> GENSEC backend 'schannel' registered
>> GENSEC backend 'naclrpc_as_system' registered
>> GENSEC backend 'sasl-EXTERNAL' registered
>> GENSEC backend 'ntlmssp' registered
>> GENSEC backend 'ntlmssp_resume_ccache' registered
>> GENSEC backend 'http_basic' registered
>> GENSEC backend 'http_ntlm' registered
>> Got challenge flags:
>> Got NTLMSSP neg_flags=0x628a8215
>> NTLMSSP: Set final flags:
>> Got NTLMSSP neg_flags=0x62088215
>> NTLMSSP Sign/Seal - Initialising with flags:
>> Got NTLMSSP neg_flags=0x62088215
>> SPNEGO login failed: Logon failure
>> session setup failed: NT_STATUS_LOGON_FAILURE
>>
>> On Fri, Dec 2, 2016 at 10:57 AM, Alexander Bokovoy <abokovoy at redhat.com>
>> wrote:
>>
>> On pe, 02 joulu 2016, Fujisan wrote:
>>>
>>> Alexander,
>>>>
>>>> I have now in my conf on server A and client B
>>>>
>>>> dedicated keytab file = /etc/samba/samba.keytab
>>>>
>>>> instead of
>>>>
>>>> dedicated keytab file = FILE:/etc/samba/samba.keytab
>>>>
>>>>
>>>> But unfortunately, it did not solve the problem.
>>>>
>>>> It did solve for me. The offending commit in Samba is c2f5c30b
>>>
>>> $ git tag --contains c2f5c30b|grep samba
>>> samba-4.5.0
>>> samba-4.5.0rc1
>>> samba-4.5.0rc2
>>> samba-4.5.0rc3
>>> samba-4.5.1
>>>
>>> It has following code:
>>> +krb5_error_code smb_krb5_open_keytab(krb5_context context,
>>> +                                    const char *keytab_name_req,
>>> +                                    bool write_access,
>>> +                                    krb5_keytab *keytab)
>>> +{
>>> +       if (keytab_name_req != NULL) {
>>> +               if (keytab_name_req[0] != '/') {
>>> +                       return KRB5_KT_BADNAME;
>>> +               }
>>> +       }
>>> +
>>> +       return smb_krb5_open_keytab_relative(context,
>>> +                                            keytab_name_req,
>>> +                                            write_access,
>>> +                                            keytab);
>>> +}
>>>
>>> It is the check for keytab_name_req[0] not starting from '/' what causes
>>> the break.
>>>
>>>
>>>
>>>
>>>>
>>>> On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy <abokovoy at redhat.com
>>>> >
>>>> wrote:
>>>>
>>>> On to, 01 joulu 2016, Fujisan wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>>
>>>>>> I have upgraded a client and a freeipa server from Fedora 24 to 25
>>>>>> recently.
>>>>>> And I *cannot* access linux shares located on the F25 freeipa client
>>>>>> from
>>>>>> a
>>>>>> windows desktop.
>>>>>> But I can access linux shares located on the F25 freeipa server from
>>>>>> that
>>>>>> windows desktop.
>>>>>> And I can access linux shares located on the F24 freeipa client from
>>>>>> that
>>>>>> windows desktop.
>>>>>>
>>>>>> To be clear, I have:
>>>>>>  A/ 1 F25 freeipa server
>>>>>>  B/ 1 F25 freeipa client
>>>>>>  C/ 1 F24 freeipa client
>>>>>>  D/ 1 windows desktop
>>>>>>
>>>>>> I can access linux shares of A from D.
>>>>>> I can access linux shares of C from D.
>>>>>> I *cannot* access linux shares of B from D.
>>>>>>
>>>>>> I get these messages on B in /var/log/samba/log.10.0.21.247 :
>>>>>>
>>>>>> [2016/12/01 11:42:19.218759,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed
>>>>>> (Key
>>>>>> table name malformed)
>>>>>> [2016/12/01 11:42:19.218800,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:627(gse_krb5_get_server_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem
>>>>>> keytab
>>>>>> - -1765328205
>>>>>> [2016/12/01 11:42:19.218823,  1] ../auth/gensec/gensec_start.c:
>>>>>> 698(gensec_start_mech)
>>>>>>  Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR
>>>>>> [2016/12/01 11:42:19.261611,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed
>>>>>> (Key
>>>>>> table name malformed)
>>>>>> [2016/12/01 11:42:19.261638,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:627(gse_krb5_get_server_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem
>>>>>> keytab
>>>>>> - -1765328205
>>>>>> [2016/12/01 11:42:19.261653,  1] ../auth/gensec/gensec_start.c:
>>>>>> 698(gensec_start_mech)
>>>>>>  Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR
>>>>>> [2016/12/01 11:42:19.263330,  2] ../source3/auth/auth.c:315(
>>>>>> auth_check_ntlm_password)
>>>>>>  check_ntlm_password:  Authentication for user [smith] -> [smith]
>>>>>> FAILED
>>>>>> with error NT_STATUS_NO_SUCH_USER
>>>>>> [2016/12/01 11:42:19.263380,  2] ../auth/gensec/spnego.c:720(
>>>>>> gensec_spnego_server_negTokenTarg)
>>>>>>  SPNEGO login failed: NT_STATUS_NO_SUCH_USER
>>>>>> [2016/12/01 11:42:19.270531,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed
>>>>>> (Key
>>>>>> table name malformed)
>>>>>> [2016/12/01 11:42:19.270562,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:627(gse_krb5_get_server_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem
>>>>>> keytab
>>>>>> - -1765328205
>>>>>> [2016/12/01 11:42:19.270586,  1] ../auth/gensec/gensec_start.c:
>>>>>> 698(gensec_start_mech)
>>>>>>  Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR
>>>>>> [2016/12/01 11:42:19.313479,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed
>>>>>> (Key
>>>>>> table name malformed)
>>>>>> [2016/12/01 11:42:19.313506,  1] ../source3/librpc/crypto/gse_
>>>>>> krb5.c:627(gse_krb5_get_server_keytab)
>>>>>>  ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem
>>>>>> keytab
>>>>>> - -1765328205
>>>>>> [2016/12/01 11:42:19.313523,  1] ../auth/gensec/gensec_start.c:
>>>>>> 698(gensec_start_mech)
>>>>>>  Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR
>>>>>> [2016/12/01 11:42:19.315256,  2] ../source3/auth/auth.c:315(
>>>>>> auth_check_ntlm_password)
>>>>>>  check_ntlm_password:  Authentication for user [smith] -> [smith]
>>>>>> FAILED
>>>>>> with error NT_STATUS_NO_SUCH_USER
>>>>>> [2016/12/01 11:42:19.315291,  2] ../auth/gensec/spnego.c:720(
>>>>>> gensec_spnego_server_negTokenTarg)
>>>>>>  SPNEGO login failed: NT_STATUS_NO_SUCH_USER
>>>>>>
>>>>>> Also from the F25 server, I have the following when I run smbclient
>>>>>>
>>>>>> f25server # smbclient -k -L f25desktop.mydomain
>>>>>> lp_load_ex: changing to config backend registry
>>>>>> session setup failed: NT_STATUS_LOGON_FAILURE
>>>>>>
>>>>>> But if i run it with a F24 desktop, it works:
>>>>>>
>>>>>> f25server # smbclient -k -L f24desktop.mydomain
>>>>>> lp_load_ex: changing to config backend registry
>>>>>> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7]
>>>>>>
>>>>>>    Sharename       Type      Comment
>>>>>>    ---------       ----      -------
>>>>>>    IPC$            IPC       IPC Service (Samba Server Version 4.4.7)
>>>>>>    data            Disk      /data on f24desktop
>>>>>>    data2           Disk      /data2 on f24desktop
>>>>>>    data3           Disk      /data3 on f24desktop
>>>>>>    backup          Disk      /backup on f24desktop
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>> net conf list on the f25desktop gives:
>>>>>>
>>>>>> f25desktop # net conf list
>>>>>> [global]
>>>>>>    workgroup = MYDOMAIN
>>>>>>    realm = MYDOMAIN
>>>>>>    netbios name = F25SERVER
>>>>>>    server string = Samba Server Version %v
>>>>>>    kerberos method = dedicated keytab
>>>>>>    dedicated keytab file = FILE:/etc/samba/samba.keytab
>>>>>>
>>>>>> There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab
>>>>>>
>>>>> file' value as it is when constructing a memory keytab. As result,
>>>>> libkrb5 is confused and does not know which keytab processing routine
>>>>> to
>>>>> use (MEMORY:FILE:/etc/samba/samba.keytab is invalid).
>>>>>
>>>>> You can replace the value by removing FILE: right now:
>>>>>
>>>>> net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab
>>>>>
>>>>> When no prefix is used, libkrb5 will default to FILE: itself.
>>>>>
>>>>> We are going to look at changing the Samba code to strip the prefix
>>>>> from
>>>>> the 'dedicated keytab file' when applying it to memory-based keytabs.
>>>>>
>>>>> --
>>>>> / Alexander Bokovoy
>>>>>
>>>>>
>>>>> --
>>> / Alexander Bokovoy
>>>
>>>
> --
> / Alexander Bokovoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20161202/192fd181/attachment.htm>


More information about the Freeipa-users mailing list