Displaying 5 results from an estimated 5 matches for "set_server_common_status".
2018 Jul 20
2
SSSD on CentOS 7 failing to start when connecting to 4.8.3 AD via LDAP
...eply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished.
Target is not supported with this configuration.
(Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]]
[set_server_common_status] (0x0100): Marking server '192.168.192.50' as
'resolving name'
(Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]]
[set_server_common_status] (0x0100): Marking server '192.168.192.50' as
'name resolved'
(Thu Jul 19 23:40:44 2018) [sssd[be[AD.COMPANY.COM]]]
[sdap_ge...
2015 May 09
5
sssd on a DC
...nc] (0x0100): Principal name is: [DC1$@DOMAIN.TLD]
[...]
[sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
[child_sig_handler] (0x0100): child [8505] finished successfully.
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc2.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc2.domain.tld'
as 'working'
At first I thought it was something to do with the keytab file (which
is a bit of a black box to me and I don't quite understand); I even
extracted the keytab for DC1 and told sssd to use it directly, but I'm
confused...
2015 May 10
2
sssd on a DC
...;> [...]
>> [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
>> [child_sig_handler] (0x0100): child [8505] finished successfully.
>> [fo_set_port_status] (0x0100): Marking port 389 of server
>> 'dc2.domain.tld' as 'working'
>> [set_server_common_status] (0x0100): Marking server 'dc2.domain.tld'
>> as 'working'
>>
>> At first I thought it was something to do with the keytab file (which
>> is a bit of a black box to me and I don't quite understand); I even
>> extracted the keytab for DC1 and told ss...
2015 May 10
0
sssd on a DC
...to
DC1.my-pre-AD-dns-domain.tld, rather than DC1.domain.tld. This had
been working perfectly for everything else - but evidently kerberos is
a little pickier. I now have sssd working, I think:
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc1.domain.tld' as 'working'
[set_server_common_status] (0x0100): Marking server 'dc1.domain.tld'
as 'working'
I used the following commands to test the GSSAPI element (easier than
reloading sssd and wading through logs):
Failure scenario (wrong reverse DNS):
# kinit myusername
Password for myusername at DOMAIN.TLD:
# ldapsearch -LLL...
2015 May 09
0
sssd on a DC
...s: [DC1$@DOMAIN.TLD]
> [...]
> [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: DC1$
> [child_sig_handler] (0x0100): child [8505] finished successfully.
> [fo_set_port_status] (0x0100): Marking port 389 of server
> 'dc2.domain.tld' as 'working'
> [set_server_common_status] (0x0100): Marking server 'dc2.domain.tld'
> as 'working'
>
> At first I thought it was something to do with the keytab file (which
> is a bit of a black box to me and I don't quite understand); I even
> extracted the keytab for DC1 and told sssd to use it directl...