Hi Team,

I even tried using net ads join and it throws below error.

Failed to join domain: failed to lookup DC info for domain 'AD.ADMIN' over rpc: NT_STATUS_CONNECTION_RESET

Regards
Sachin Kumar

On Fri, May 19, 2023 at 1:54 PM Sac Isilia <udaypratap.singh65@gmail.com> wrote:
Hi Team,

I have started the troubleshooting with creating new RHEL 6 test machine to get a persistent sssd configuration that works . I am using official link to join manually (https://sssd.io/docs/ad/ad-provider-manual.html).

I set my krb5.conf as mentioned and then I ran kinit and it threw below error. Please help me resolve this issue.

kinit svc_admin@ad.usa
Password for svc_admin@ad.usa:
kinit: KDC reply did not match expectations while getting initial credentials

Regards
Sachin Kumar

On Wed, May 17, 2023 at 7:27 PM Sumit Bose <sbose@redhat.com> wrote:
Am Wed, May 17, 2023 at 05:03:58PM +0530 schrieb Sac Isilia:
> Hi Team,
>
> Sorry for the late reply. We are really confused about the behaviour of
> sssd. We have one machine whose net ads testjoin shows join failed but
> still I am able to authenticate via my AD ID. Can you help us why is it
> happening ? It present us to the confusion as what is really right
> configuration that will remain persistent and not break AD authentication
> even after server reboot. Below are the output of some important files but
> do let me know if you need some extra information.
>
> net ads test join output
>
> ```
> kerberos_kinit_password example1$@AD.ADMIN failed: Preauthentication failed
> kerberos_kinit_password example1$@AD.ADMIN failed: Preauthentication failed
> Join to domain is not valid: Logon failure
> ```

Hi,

the reason might be that the Kerberos keys related to the machine account
password in /etc/krb5.keytab are updated but not Samba's internal copy
of the machine account password.

You can check this by calling

    kinit -k 'example1$@AD.ADMIN'

if this works, it means the keytab is up-to-date and `net ads testjoin`
most probably failed because the internal copy in not update.

The reason is that by default SSSD only refreshes the keytab because
refreshing Samba's internal copy requires additional configuration which
might not be present in all environments. SSSD has to option
'ad_update_samba_machine_account_password' which can to set to 'true' to
tell SSSD to try to update Samba's internal copy as well.

Are you actively using Samba and/or winbind on this host or just have a
proper smb.conf so that tools like 'net' can work as expected?  In the
former case you might want to consider setting
`machine password timeout = 0` to disable machine account password
renewal on the Samba side because Samba currently only update it's
internal copy automatically and not the keytab.

HTH

bye,
Sumit

>
> smb.conf
> ```
> [global]
>         workgroup = ADADMIN
>         client signing = yes
>         client use spnego = yes
>         kerberos method = secrets and keytab
>         log file = /var/log/samba/%m.log
>         realm = AD.ADMIN
>         security = ads
>         netbios name = example1
>         disable netbios = yes
>         log file = /var/log/samba/log.%m
>          max log size = 50
>          load printers = yes
>          cups options = raw
>
> [homes]
>         comment = Home Directories
>         browseable = no
>         writable = yes
>
> [printers]
>         comment = All Printers
>         path = /var/spool/samba
>         browseable = no
>         guest ok = no
>         writable = no
>         printable = yes
> ```
>
> sssd.conf
>
> ```
> [sssd]
> services = nss, pam
> config_file_version = 2
> reconnection_retries = 3
> sbus_timeout = 30
> domains = ad.admin
>
> [nss]
> filter_groups = root
> filter_users = root
> reconnection_retries = 3[pam]reconnection_retries = 3
> [domain/ad.admin]
> id_provider = ad
> cache_credentials = True
> access_provider = simple
> ldap_id_mapping = True
> use_fully_qualified_names = False
> ad_domain = ad.admin
> enumerate = false
> ldap_deref_threshold = 0
> ldap_use_tokengroups = False
> debug_level = 3
> [autofs]
> ```
>
> krb5.conf
>
> ```
> logging]
>   default = FILE:/var/log/krb5libs.log
>   kdc = FILE:/var/log/krb5kdc.log
>   admin_server = FILE:/var/log/kadmind.log
>
> [libdefaults]
>   default_realm = AD.ADMIN
>   dns_lookup_realm = false
>   dns_lookup_kdc = true
>   ticket_lifetime = 24h
>   renew_lifetime = 7d
>   forwardable = true
> ```
>
> Regards
> Sachin Kumar
>
> On Wed, May 3, 2023 at 3:39 PM Sumit Bose <sbose@redhat.com> wrote:
>
> > Am Wed, May 03, 2023 at 12:17:31PM +0530 schrieb Sac Isilia:
> > > Hi Team,
> > >
> > > We are using sssd in our environment for authentication of AD users. But
> > it
> > > disconnect from domain for unknown reasons.
> > >
> > > Can someone help if there is some best practice or script that
> > > automatically rejoin the server to domain as soon as it disconnects? It
> > has
> > > become pain for us to do it manually.
> >
> > Hi,
> >
> > how often does this happen for a single host? If it is around every 30
> > days then most probably the automatic renewal of the machine account
> > password failed. If in your environment computers are not required to
> > renew their password every 30 days you can disable this feature by
> > setting
> >
> >     ad_maximum_machine_account_password_age = 0
> >
> > in the [domain/...] section of sssd.conf and restart SSSSD, see 'man
> > sssd-ad' for details.
> >
> > If you want to debug the issue I suggest to use a test host which is
> > currently working and set
> >
> >     ad_maximum_machine_account_password_age = 1
> >     debug_level = 9
> >
> > in the [domain/...] section of sssd.conf and restart SSSD. This will
> > tell SSSD to try to renew the machine account password if it is older
> > than one day and write a detailed debug log.
> >
> > Which version of SSSD are you using and on which platform?
> >
> > bye,
> > Sumit
> >
> > >
> > > Regards
> > > Sachin Kumar
> >
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> > > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> > _______________________________________________
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue