6:44 a.m.
Hi all,
I've been having this issue with my configuration for ages, and I've
just been working around the problem rather than fixing it.
I have a CentOS 6.8 server running sssd 1.13.3 and Samba 3.6.23.
The server is joined to an AD domain, I've tried using both adcli and
"net ads", it doesn't seem to matter which one I use.
Initially both normal authentication and access to the server via
Samba works with AD users, but after a certain period of time (it
seems to be in the region of a month or two), Samba access to the
server stops working.
Running smbclient on the server shows the problem as well as normal
access from a Windows workstation, and smbclient says:
$ smbclient //myserver/johnb
Enter johnb's password:
session setup failed: NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE
My workaround has been to rejoin the server to the domain, which
clears the issue.
Any idea what could be causing this?
Obfuscated config files:
/etc/samba/smb.conf:
[global]
workgroup = AD
password server = dc1.example.com dc2.example.com *
realm = EXAMPLE.COM
security = ads
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
idmap config * : backend = tdb
idmap config * : range = 10000 - 19999
/etc/sssd/sssd.conf:
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = AD
[domain/AD]
# Base configuration
cache_credentials = True
#debug_level = 9
#debug_level = 0x97e0
#debug_level = 0xfff0
debug_level = 4
dyndns_update = false
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
refresh_expired_interval = 4050
# AD specific options
ad_enable_dns_sites = true
ad_server = _srv_,dc1.example.com,dc2.example.com
ad_backup_server = example.com
ad_domain = example.com
# ID mapping
ldap_id_mapping = false
# Sudo
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
7:03 a.m.
What version of adcli? Before 0.8.1 I think it did not renew the machines Kerberos ticket
or manage the machine password. I had to use a cron job to renew the ticket. Adcli 0.8.1
does that by itself now.
Todd
Sent from my Windows 10 phone
From: John Beranek<mailto:john@redux.org.uk>
Sent: Wednesday, March 8, 2017 6:45 AM
To: End-user discussions about the System Security Services
Daemon<mailto:sssd-users@lists.fedorahosted.org>
Subject: [SSSD-users] Samba issue using sssd and AD authentication
Hi all,
I've been having this issue with my configuration for ages, and I've
just been working around the problem rather than fixing it.
I have a CentOS 6.8 server running sssd 1.13.3 and Samba 3.6.23.
The server is joined to an AD domain, I've tried using both adcli and
"net ads", it doesn't seem to matter which one I use.
Initially both normal authentication and access to the server via
Samba works with AD users, but after a certain period of time (it
seems to be in the region of a month or two), Samba access to the
server stops working.
Running smbclient on the server shows the problem as well as normal
access from a Windows workstation, and smbclient says:
$ smbclient //myserver/johnb
Enter johnb's password:
session setup failed: NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE
My workaround has been to rejoin the server to the domain, which
clears the issue.
Any idea what could be causing this?
Obfuscated config files:
/etc/samba/smb.conf:
[global]
workgroup = AD
password server = dc1.example.com dc2.example.com *
realm = EXAMPLE.COM
security = ads
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
idmap config * : backend = tdb
idmap config * : range = 10000 - 19999
/etc/sssd/sssd.conf:
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = AD
[domain/AD]
# Base configuration
cache_credentials = True
#debug_level = 9
#debug_level = 0x97e0
#debug_level = 0xfff0
debug_level = 4
dyndns_update = false
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
refresh_expired_interval = 4050
# AD specific options
ad_enable_dns_sites = true
ad_server = _srv_,dc1.example.com,dc2.example.com
ad_backup_server = example.com
ad_domain = example.com
# ID mapping
ldap_id_mapping = false
# Sudo
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
7:25 a.m.
On 8 March 2017 at 13:03, Mote, Todd <moter(a)austin.utexas.edu> wrote:
What version of adcli? Before 0.8.1 I think it did not renew the
machines
Kerberos ticket or manage the machine password. I had to use a cron job to
renew the ticket. Adcli 0.8.1 does that by itself now.
adcli 0.8.1 (in fact from Fedora Project COPR (jhrozek/SSSD-6.8-preview))
Not sure how it'd renew tickets though, as the package itself has no
service/cron...does sssd call out to adcli on RHEL/CentOS 6.8?
Cheers,
John
7:40 a.m.
Does on my rhel 6 boxes. I'm not in front of a computer at the moment, but there is a
log where you can see it. Sssd_domain.log I think. I'll look when I get to work and
let you know. Might search the list archive too I'm pretty sure I asked about it when
adcli was still in the .7’s.
Sent from my Windows 10 phone
From: John Beranek<mailto:john@redux.org.uk>
Sent: Wednesday, March 8, 2017 7:32 AM
To: End-user discussions about the System Security Services
Daemon<mailto:sssd-users@lists.fedorahosted.org>
Subject: [SSSD-users] Re: Samba issue using sssd and AD authentication
On 8 March 2017 at 13:03, Mote, Todd <moter(a)austin.utexas.edu> wrote:
What version of adcli? Before 0.8.1 I think it did not renew the
machines
Kerberos ticket or manage the machine password. I had to use a cron job to
renew the ticket. Adcli 0.8.1 does that by itself now.
adcli 0.8.1 (in fact from Fedora Project COPR (jhrozek/SSSD-6.8-preview))
Not sure how it'd renew tickets though, as the package itself has no
service/cron...does sssd call out to adcli on RHEL/CentOS 6.8?
Cheers,
John
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
8:09 a.m.
On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu> wrote:
Does on my rhel 6 boxes. I'm not in front of a computer at the
moment, but
there is a log where you can see it. Sssd_domain.log I think. I'll look
when I get to work and let you know. Might search the list archive too I'm
pretty sure I asked about it when adcli was still in the .7’s.
Hmm, just reading a list thread from September 2016 where it's
suggested that adcli doesn't get on well with Samba,entitled "samba
4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
I wonder if having adcli installed, but using "net ads join" to join
the domain is still troublesome...
John
8:32 a.m.
Ah, that may be, I use adcli to join. The tries are in sssd_<domain>.log you'll
see lines like this, you may need to turn up logging though, if I recall mine was on
'9' when I found this. This was with a version prior to 0.8.1. The thread on the
list was subjected "I'm new to everything!" from me.
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [be_ptask_execute] (0x0400): Task [AD
machine account password renewal]: executing task, timeout 60 seconds
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [child_handler_setup] (0x2000): Setting
up signal handler up for pid [51099]
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [child_handler_setup] (0x2000): Signal
handler set up for pid [51099]
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [child_sig_handler] (0x1000): Waiting
for child [51099].
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [child_sig_handler] (0x0020): child
[51099] failed with status [2].
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]] [read_pipe_handler] (0x0400): EOF
received, client finished
(Fri Feb 5 14:08:54 2016) [sssd[be[domain.com]]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: 'update' is not a valid adcli command. See 'adcli --help'
---adcli output end---
-----Original Message-----
From: john.redux(a)gmail.com [mailto:john.redux@gmail.com] On Behalf Of John Beranek
Sent: Wednesday, March 8, 2017 8:09 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Samba issue using sssd and AD authentication
On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu> wrote:
Does on my rhel 6 boxes. I'm not in front of a computer at the
moment, but there is a log where you can see it. Sssd_domain.log I
think. I'll look when I get to work and let you know. Might search
the list archive too I'm pretty sure I asked about it when adcli was still in the
.7’s.
Hmm, just reading a list thread from September 2016 where it's suggested that adcli
doesn't get on well with Samba,entitled "samba 4.2.11, 4.2.14 and sssd?"
http://bit.ly/2n60x4r
I wonder if having adcli installed, but using "net ads join" to join the domain
is still troublesome...
John
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
8:59 a.m.
On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu>
wrote:
> Does on my rhel 6 boxes. I'm not in front of a computer at the moment, but
> there is a log where you can see it. Sssd_domain.log I think. I'll look
> when I get to work and let you know. Might search the list archive too I'm
> pretty sure I asked about it when adcli was still in the .7’s.
Hmm, just reading a list thread from September 2016 where it's
suggested that adcli doesn't get on well with Samba,entitled "samba
4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
I wonder if having adcli installed, but using "net ads join" to join
the domain is still troublesome...
Maybe adcli does not lead to the expected result because you use
'kerberos method = secrets and keytab'. adcli can only update the keytab
but not the host password stored in Samba's secrets.tdb. So chances are
that even if the keys in the keytab are updated Samba will still use the
old one from secrets.tdb. Have you tried to use 'kerberos method =
system keytab'?
HTH
bye,
Sumit
>
> John
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
10:07 a.m.
On 8 March 2017 at 14:59, Sumit Bose <sbose(a)redhat.com> wrote:
On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
> On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu> wrote:
> > Does on my rhel 6 boxes. I'm not in front of a computer at the moment, but
> > there is a log where you can see it. Sssd_domain.log I think. I'll look
> > when I get to work and let you know. Might search the list archive too I'm
> > pretty sure I asked about it when adcli was still in the .7’s.
>
> Hmm, just reading a list thread from September 2016 where it's
> suggested that adcli doesn't get on well with Samba,entitled "samba
> 4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
>
> I wonder if having adcli installed, but using "net ads join" to join
> the domain is still troublesome...
Maybe adcli does not lead to the expected result because you use
'kerberos method = secrets and keytab'. adcli can only update the keytab
but not the host password stored in Samba's secrets.tdb. So chances are
that even if the keys in the keytab are updated Samba will still use the
old one from secrets.tdb. Have you tried to use 'kerberos method =
system keytab'?
Thanks Sumit, no change with just the config change, would I need to
clear out the Samba database after the change?
John
10:09 a.m.
On 8 March 2017 at 16:07, John Beranek <john(a)redux.org.uk> wrote:
On 8 March 2017 at 14:59, Sumit Bose <sbose(a)redhat.com> wrote:
> On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
>> On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu> wrote:
>> > Does on my rhel 6 boxes. I'm not in front of a computer at the moment,
but
>> > there is a log where you can see it. Sssd_domain.log I think. I'll
look
>> > when I get to work and let you know. Might search the list archive too
I'm
>> > pretty sure I asked about it when adcli was still in the .7’s.
>>
>> Hmm, just reading a list thread from September 2016 where it's
>> suggested that adcli doesn't get on well with Samba,entitled "samba
>> 4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
>>
>> I wonder if having adcli installed, but using "net ads join" to join
>> the domain is still troublesome...
>
> Maybe adcli does not lead to the expected result because you use
> 'kerberos method = secrets and keytab'. adcli can only update the keytab
> but not the host password stored in Samba's secrets.tdb. So chances are
> that even if the keys in the keytab are updated Samba will still use the
> old one from secrets.tdb. Have you tried to use 'kerberos method =
> system keytab'?
Thanks Sumit, no change with just the config change, would I need to
clear out the Samba database after the change?
Getting the following, which may answer that question:
[2017/03/08 16:04:56.947025, 0] libads/kerberos_util.c:101(ads_kinit_password)
kerberos_kinit_password SERVER$(a)EXAMPLE.COM failed: Preauthentication failed
[2017/03/08 16:04:56.947192, 3]
printing/nt_printing_ads.c:639(check_published_printers)
ads_connect failed: Preauthentication failed
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
10:28 a.m.
On 8 March 2017 at 16:09, John Beranek <john(a)redux.org.uk> wrote:
On 8 March 2017 at 16:07, John Beranek <john(a)redux.org.uk>
wrote:
> On 8 March 2017 at 14:59, Sumit Bose <sbose(a)redhat.com> wrote:
>> On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
>>> On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu> wrote:
>>> > Does on my rhel 6 boxes. I'm not in front of a computer at the
moment, but
>>> > there is a log where you can see it. Sssd_domain.log I think. I'll
look
>>> > when I get to work and let you know. Might search the list archive too
I'm
>>> > pretty sure I asked about it when adcli was still in the .7’s.
>>>
>>> Hmm, just reading a list thread from September 2016 where it's
>>> suggested that adcli doesn't get on well with Samba,entitled "samba
>>> 4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
>>>
>>> I wonder if having adcli installed, but using "net ads join" to
join
>>> the domain is still troublesome...
>>
>> Maybe adcli does not lead to the expected result because you use
>> 'kerberos method = secrets and keytab'. adcli can only update the keytab
>> but not the host password stored in Samba's secrets.tdb. So chances are
>> that even if the keys in the keytab are updated Samba will still use the
>> old one from secrets.tdb. Have you tried to use 'kerberos method =
>> system keytab'?
>
> Thanks Sumit, no change with just the config change, would I need to
> clear out the Samba database after the change?
Getting the following, which may answer that question:
[2017/03/08 16:04:56.947025, 0] libads/kerberos_util.c:101(ads_kinit_password)
kerberos_kinit_password SERVER$(a)EXAMPLE.COM failed: Preauthentication failed
[2017/03/08 16:04:56.947192, 3]
printing/nt_printing_ads.c:639(check_published_printers)
ads_connect failed: Preauthentication failed
Cleared all Samba databases and re-joined the domain with adcli.
I can now access the server via SMB from Windows, and also with
smbclient, but only by using '-k'.
Using Username/Password I get:
session setup failed: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
In the Samba log:
Connecting to 10.20.30.40 at port 445
[2017/03/08 16:25:57.230010, 0]
rpc_client/cli_pipe_schannel.c:54(get_schannel_session_key_common)
get_schannel_session_key: could not fetch trust account password for
domain 'EXAMPLE'
[2017/03/08 16:25:57.230740, 0]
rpc_client/cli_pipe_schannel.c:184(cli_rpc_pipe_open_schannel)
cli_rpc_pipe_open_schannel: failed to get schannel session key from
server DC1.EXAMPLE.COM for domain EXAMPLE.
[2017/03/08 16:25:57.230827, 0]
auth/auth_domain.c:193(connect_to_domain_password_server)
connect_to_domain_password_server: unable to open the domain client
session to machine DC1.EXAMPLE.COM. Error was :
NT_STATUS_CANT_ACCESS_DOMAIN_INFO.
[2017/03/08 16:25:57.231268, 0] auth/auth_domain.c:292(domain_client_validate)
domain_client_validate: Domain password server not available.
[2017/03/08 16:25:57.231362, 2] auth/auth.c:330(check_ntlm_password)
check_ntlm_password: Authentication for user [johnb] -> [johnb]
FAILED with error NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2017/03/08 16:25:57.231419, 3] smbd/error.c:81(error_packet_set)
error packet at smbd/sesssetup.c(124) cmd=115 (SMBsesssetupX)
NT_STATUS_CANT_ACCESS_DOMAIN_INFO
[2017/03/08 16:25:57.231670, 3] smbd/server_exit.c:181(exit_server_common)
Server exit (failed to receive smb request)
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
11:13 a.m.
On Wed, Mar 08, 2017 at 04:28:06PM +0000, John Beranek wrote:
On 8 March 2017 at 16:09, John Beranek <john(a)redux.org.uk>
wrote:
> On 8 March 2017 at 16:07, John Beranek <john(a)redux.org.uk> wrote:
>> On 8 March 2017 at 14:59, Sumit Bose <sbose(a)redhat.com> wrote:
>>> On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
>>>> On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu>
wrote:
>>>> > Does on my rhel 6 boxes. I'm not in front of a computer at the
moment, but
>>>> > there is a log where you can see it. Sssd_domain.log I think.
I'll look
>>>> > when I get to work and let you know. Might search the list archive
too I'm
>>>> > pretty sure I asked about it when adcli was still in the .7’s.
>>>>
>>>> Hmm, just reading a list thread from September 2016 where it's
>>>> suggested that adcli doesn't get on well with Samba,entitled
"samba
>>>> 4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
>>>>
>>>> I wonder if having adcli installed, but using "net ads join"
to join
>>>> the domain is still troublesome...
>>>
>>> Maybe adcli does not lead to the expected result because you use
>>> 'kerberos method = secrets and keytab'. adcli can only update the
keytab
>>> but not the host password stored in Samba's secrets.tdb. So chances are
>>> that even if the keys in the keytab are updated Samba will still use the
>>> old one from secrets.tdb. Have you tried to use 'kerberos method =
>>> system keytab'?
>>
>> Thanks Sumit, no change with just the config change, would I need to
>> clear out the Samba database after the change?
>
> Getting the following, which may answer that question:
>
> [2017/03/08 16:04:56.947025, 0] libads/kerberos_util.c:101(ads_kinit_password)
> kerberos_kinit_password SERVER$(a)EXAMPLE.COM failed: Preauthentication failed
> [2017/03/08 16:04:56.947192, 3]
> printing/nt_printing_ads.c:639(check_published_printers)
> ads_connect failed: Preauthentication failed
Cleared all Samba databases and re-joined the domain with adcli.
I can now access the server via SMB from Windows, and also with
smbclient, but only by using '-k'.
Using Username/Password I get:
session setup failed: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
ok, for this the plain text host password form secrets.tdb is needed.
The only way I can see now is to enhance adcli to update the password in
secrets.tdb as well if requested. Feel free to open an RFE either with
adcli itself or on bugzilla.redhat.com for the adcli component.
bye,
Sumit
>
> In the Samba log:
>
> Connecting to 10.20.30.40 at port 445
> [2017/03/08 16:25:57.230010, 0]
> rpc_client/cli_pipe_schannel.c:54(get_schannel_session_key_common)
> get_schannel_session_key: could not fetch trust account password for
> domain 'EXAMPLE'
> [2017/03/08 16:25:57.230740, 0]
> rpc_client/cli_pipe_schannel.c:184(cli_rpc_pipe_open_schannel)
> cli_rpc_pipe_open_schannel: failed to get schannel session key from
> server DC1.EXAMPLE.COM for domain EXAMPLE.
> [2017/03/08 16:25:57.230827, 0]
> auth/auth_domain.c:193(connect_to_domain_password_server)
> connect_to_domain_password_server: unable to open the domain client
> session to machine DC1.EXAMPLE.COM. Error was :
> NT_STATUS_CANT_ACCESS_DOMAIN_INFO.
> [2017/03/08 16:25:57.231268, 0] auth/auth_domain.c:292(domain_client_validate)
> domain_client_validate: Domain password server not available.
> [2017/03/08 16:25:57.231362, 2] auth/auth.c:330(check_ntlm_password)
> check_ntlm_password: Authentication for user [johnb] -> [johnb]
> FAILED with error NT_STATUS_CANT_ACCESS_DOMAIN_INFO
> [2017/03/08 16:25:57.231419, 3] smbd/error.c:81(error_packet_set)
> error packet at smbd/sesssetup.c(124) cmd=115 (SMBsesssetupX)
> NT_STATUS_CANT_ACCESS_DOMAIN_INFO
> [2017/03/08 16:25:57.231670, 3] smbd/server_exit.c:181(exit_server_common)
> Server exit (failed to receive smb request)
>
> John
>
> --
> John Beranek To generalise is to be an idiot.
> http://redux.org.uk/ -- William Blake
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
4:29 a.m.
So, an update on this - I left the server for a day, and Samba has
stopped authenticating. Samba log says:
[2017/03/09 10:21:48.814799, 3] smbd/process.c:1609(process_smb)
Transaction 9 of length 2670 (0 toread)
[2017/03/09 10:21:48.814904, 3] smbd/process.c:1414(switch_message)
switch message SMBsesssetupX (pid 20958) conn 0x0
[2017/03/09 10:21:48.814945, 3] smbd/sesssetup.c:1347(reply_sesssetup_and_X)
wct=12 flg2=0xc807
[2017/03/09 10:21:48.814973, 2] smbd/sesssetup.c:1293(setup_new_vc_session)
setup_new_vc_session: New VC == 0, if NT4.x compatible we would
close all old resources.
[2017/03/09 10:21:48.815008, 3]
smbd/sesssetup.c:1074(reply_sesssetup_and_X_spnego)
Doing spnego session setup
[2017/03/09 10:21:48.815040, 3]
smbd/sesssetup.c:1116(reply_sesssetup_and_X_spnego)
NativeOS=[] NativeLanMan=[] PrimaryDomain=[]
[2017/03/09 10:21:48.815093, 3] smbd/sesssetup.c:662(reply_spnego_negotiate)
reply_spnego_negotiate: Got secblob of size 2524
[2017/03/09 10:21:48.817915, 3]
libads/kerberos_verify.c:297(ads_keytab_verify_ticket)
libads/kerberos_verify.c:297: krb5_rd_req failed for all 40 matched
keytab principals
[2017/03/09 10:21:48.817969, 3] libads/kerberos_verify.c:638(ads_verify_ticket)
libads/kerberos_verify.c:638: krb5_rd_req with auth failed (Success)
[2017/03/09 10:21:48.818024, 1] smbd/sesssetup.c:344(reply_spnego_kerberos)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
sssd shows that adcli has been run:
(Wed Mar 8 16:18:26 2017) [sssd[be[AD]]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output
start---
* Found realm in keytab: EXAMPLE.COM
* Found computer name in keytab: SERVER
* Found service principal in keytab: host/SERVER
* Found service principal in keytab: host/server.example.com
* Found host qualified name in keytab: host/server.example.com
* Found service principal in keytab: RestrictedKrbHost/SERVER
* Found service principal in keytab: RestrictedKrbHost/server.example.com
* Using fully qualified name: server.example.com
* Using domain name: example.com
* Calculated computer account name from fqdn: SERVER
* Using domain realm: example.com
* Sending netlogon pings to domain controller: cldap://10.20.30.40
* Received NetLogon info from: dc1.example.com
* Wrote out krb5.conf snippet to
/tmp/adcli-krb5-m5MrZa/krb5.d/adcli-krb5-conf-FYuKkI
* Authenticated as default/reset computer account: SERVER
* Looked up short domain name: EXAMPLE
* Using fully qualified name: server.example.com
* Using domain name: example.com
* Using computer account name: SERVER
* Using domain realm: example.com
* Using fully qualified name: server.example.com
* Enrolling computer name: SERVER
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for SERVER$ at:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
* Retrieved kvno '32' for computer account in directory:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
* Password not too old, no change needed
* Modifying computer account: userAccountControl
! Couldn't set userAccountControl on computer account:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com: Insufficient
access
* Updated existing computer account:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
---adcli output end---
So, adcli updated the keytab, but Samba auth still stopped working?
Cheers,
John
On 8 March 2017 at 17:13, Sumit Bose <sbose(a)redhat.com> wrote:
On Wed, Mar 08, 2017 at 04:28:06PM +0000, John Beranek wrote:
> On 8 March 2017 at 16:09, John Beranek <john(a)redux.org.uk> wrote:
> > On 8 March 2017 at 16:07, John Beranek <john(a)redux.org.uk> wrote:
> >> On 8 March 2017 at 14:59, Sumit Bose <sbose(a)redhat.com> wrote:
> >>> On Wed, Mar 08, 2017 at 02:09:09PM +0000, John Beranek wrote:
> >>>> On 8 March 2017 at 13:40, Mote, Todd <moter(a)austin.utexas.edu>
wrote:
> >>>> > Does on my rhel 6 boxes. I'm not in front of a computer at
the moment, but
> >>>> > there is a log where you can see it. Sssd_domain.log I think.
I'll look
> >>>> > when I get to work and let you know. Might search the list
archive too I'm
> >>>> > pretty sure I asked about it when adcli was still in the .7’s.
> >>>>
> >>>> Hmm, just reading a list thread from September 2016 where it's
> >>>> suggested that adcli doesn't get on well with Samba,entitled
"samba
> >>>> 4.2.11, 4.2.14 and sssd?" http://bit.ly/2n60x4r
> >>>>
> >>>> I wonder if having adcli installed, but using "net ads
join" to join
> >>>> the domain is still troublesome...
> >>>
> >>> Maybe adcli does not lead to the expected result because you use
> >>> 'kerberos method = secrets and keytab'. adcli can only update
the keytab
> >>> but not the host password stored in Samba's secrets.tdb. So chances
are
> >>> that even if the keys in the keytab are updated Samba will still use
the
> >>> old one from secrets.tdb. Have you tried to use 'kerberos method =
> >>> system keytab'?
> >>
> >> Thanks Sumit, no change with just the config change, would I need to
> >> clear out the Samba database after the change?
> >
> > Getting the following, which may answer that question:
> >
> > [2017/03/08 16:04:56.947025, 0] libads/kerberos_util.c:101(ads_kinit_password)
> > kerberos_kinit_password SERVER$(a)EXAMPLE.COM failed: Preauthentication failed
> > [2017/03/08 16:04:56.947192, 3]
> > printing/nt_printing_ads.c:639(check_published_printers)
> > ads_connect failed: Preauthentication failed
>
> Cleared all Samba databases and re-joined the domain with adcli.
>
> I can now access the server via SMB from Windows, and also with
> smbclient, but only by using '-k'.
>
> Using Username/Password I get:
>
> session setup failed: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
ok, for this the plain text host password form secrets.tdb is needed.
The only way I can see now is to enhance adcli to update the password in
secrets.tdb as well if requested. Feel free to open an RFE either with
adcli itself or on bugzilla.redhat.com for the adcli component.
bye,
Sumit
>
> In the Samba log:
>
> Connecting to 10.20.30.40 at port 445
> [2017/03/08 16:25:57.230010, 0]
> rpc_client/cli_pipe_schannel.c:54(get_schannel_session_key_common)
> get_schannel_session_key: could not fetch trust account password for
> domain 'EXAMPLE'
> [2017/03/08 16:25:57.230740, 0]
> rpc_client/cli_pipe_schannel.c:184(cli_rpc_pipe_open_schannel)
> cli_rpc_pipe_open_schannel: failed to get schannel session key from
> server DC1.EXAMPLE.COM for domain EXAMPLE.
> [2017/03/08 16:25:57.230827, 0]
> auth/auth_domain.c:193(connect_to_domain_password_server)
> connect_to_domain_password_server: unable to open the domain client
> session to machine DC1.EXAMPLE.COM. Error was :
> NT_STATUS_CANT_ACCESS_DOMAIN_INFO.
> [2017/03/08 16:25:57.231268, 0] auth/auth_domain.c:292(domain_client_validate)
> domain_client_validate: Domain password server not available.
> [2017/03/08 16:25:57.231362, 2] auth/auth.c:330(check_ntlm_password)
> check_ntlm_password: Authentication for user [johnb] -> [johnb]
> FAILED with error NT_STATUS_CANT_ACCESS_DOMAIN_INFO
> [2017/03/08 16:25:57.231419, 3] smbd/error.c:81(error_packet_set)
> error packet at smbd/sesssetup.c(124) cmd=115 (SMBsesssetupX)
> NT_STATUS_CANT_ACCESS_DOMAIN_INFO
> [2017/03/08 16:25:57.231670, 3] smbd/server_exit.c:181(exit_server_common)
> Server exit (failed to receive smb request)
>
> John
>
> --
> John Beranek To generalise is to be an idiot.
> http://redux.org.uk/ -- William Blake
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
6:06 a.m.
On 9 March 2017 at 10:29, John Beranek <john(a)redux.org.uk> wrote:
So, an update on this - I left the server for a day, and Samba has
stopped authenticating. Samba log says:
[2017/03/09 10:21:48.814799, 3] smbd/process.c:1609(process_smb)
Transaction 9 of length 2670 (0 toread)
[2017/03/09 10:21:48.814904, 3] smbd/process.c:1414(switch_message)
switch message SMBsesssetupX (pid 20958) conn 0x0
[2017/03/09 10:21:48.814945, 3] smbd/sesssetup.c:1347(reply_sesssetup_and_X)
wct=12 flg2=0xc807
[2017/03/09 10:21:48.814973, 2] smbd/sesssetup.c:1293(setup_new_vc_session)
setup_new_vc_session: New VC == 0, if NT4.x compatible we would
close all old resources.
[2017/03/09 10:21:48.815008, 3]
smbd/sesssetup.c:1074(reply_sesssetup_and_X_spnego)
Doing spnego session setup
[2017/03/09 10:21:48.815040, 3]
smbd/sesssetup.c:1116(reply_sesssetup_and_X_spnego)
NativeOS=[] NativeLanMan=[] PrimaryDomain=[]
[2017/03/09 10:21:48.815093, 3] smbd/sesssetup.c:662(reply_spnego_negotiate)
reply_spnego_negotiate: Got secblob of size 2524
[2017/03/09 10:21:48.817915, 3]
libads/kerberos_verify.c:297(ads_keytab_verify_ticket)
libads/kerberos_verify.c:297: krb5_rd_req failed for all 40 matched
keytab principals
[2017/03/09 10:21:48.817969, 3] libads/kerberos_verify.c:638(ads_verify_ticket)
libads/kerberos_verify.c:638: krb5_rd_req with auth failed (Success)
[2017/03/09 10:21:48.818024, 1] smbd/sesssetup.c:344(reply_spnego_kerberos)
Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
sssd shows that adcli has been run:
(Wed Mar 8 16:18:26 2017) [sssd[be[AD]]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output
start---
* Found realm in keytab: EXAMPLE.COM
* Found computer name in keytab: SERVER
* Found service principal in keytab: host/SERVER
* Found service principal in keytab: host/server.example.com
* Found host qualified name in keytab: host/server.example.com
* Found service principal in keytab: RestrictedKrbHost/SERVER
* Found service principal in keytab: RestrictedKrbHost/server.example.com
* Using fully qualified name: server.example.com
* Using domain name: example.com
* Calculated computer account name from fqdn: SERVER
* Using domain realm: example.com
* Sending netlogon pings to domain controller: cldap://10.20.30.40
* Received NetLogon info from: dc1.example.com
* Wrote out krb5.conf snippet to
/tmp/adcli-krb5-m5MrZa/krb5.d/adcli-krb5-conf-FYuKkI
* Authenticated as default/reset computer account: SERVER
* Looked up short domain name: EXAMPLE
* Using fully qualified name: server.example.com
* Using domain name: example.com
* Using computer account name: SERVER
* Using domain realm: example.com
* Using fully qualified name: server.example.com
* Enrolling computer name: SERVER
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for SERVER$ at:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
* Retrieved kvno '32' for computer account in directory:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
* Password not too old, no change needed
* Modifying computer account: userAccountControl
! Couldn't set userAccountControl on computer account:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com: Insufficient
access
* Updated existing computer account:
CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
---adcli output end---
So, adcli updated the keytab, but Samba auth still stopped working?
It seems a bit worse than this though, as sssd itself is upset too:
Mar 9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect
Mar 9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect
I'm going to try to clear the SSSD databases to see if that helps.
John
6:15 a.m.
On 9 March 2017 at 12:06, John Beranek <john(a)redux.org.uk> wrote:
On 9 March 2017 at 10:29, John Beranek <john(a)redux.org.uk>
wrote:
> So, an update on this - I left the server for a day, and Samba has
> stopped authenticating. Samba log says:
>
[snip]
>
> So, adcli updated the keytab, but Samba auth still stopped working?
It seems a bit worse than this though, as sssd itself is upset too:
Mar 9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect
Mar 9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect
I'm going to try to clear the SSSD databases to see if that helps.
Cleared all SSSD databases, and re-ran "adcli join" and SSSD was happy again.
Disconnected the SMB share on my Windows workstation and
re-established (with a Username/Password prompt??) and SMB access is
working again: confusing.
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
2598
days inactive
2599
days old
sssd-users@lists.fedorahosted.org
13 comments
3 participants
participants (3)
-
John Beranek -
Mote, Todd -
Sumit Bose