Unable to authenticate with AD after IP change

0

1

I have a linux environment with a single AD server. It looks like the previous sys admin setup ldap with kerberos and sssd. Recently we went through an IP change, changing the IP on the AD and all the linux servers. Now I am unable to id or getent any AD users on my linux servers, which prevents my users from logging into the linux servers. I am getting the following error across my env "sssd_be: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)"

any help would be appreciated. fyi we are not using dns in this env, all the config files are the same minus where IP was mentioned but has been changed to reflect new IP

I have searched this forum for similar issues but looks like nothing will fix my problem.

running scientific Linux 6

smb.conf

[global]
  netbios name = 10xxxx
  server string = <hostname>
  workgroup = <DOMAIN>
  client signing = yes
  client use spnego = yes
  kerberos method = secrets and keytab
  realm = <DOMAIN>.COM
  security = ADS
  log file = /var/log/samba/log.%m
  max log size = 50
  idmap uid = 20000-29999
  idmap gid = 20000-29999
  idmap config <DOMAIN>:backend = ad
  idmap config <DOMAIN>default = yes
  idmap config <DOMAIN>:range = 10000000-29999999
  idmap config <DOMAIN>:schema_mode = rfc2307
  winbind nss info = rfc2307
  winbind enum users = no
  winbind enum groups = no
  winbind separator = +
  winbind use default domain = yes
  winbind nested groups = yes

/etc/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 = <DOMAIN>.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  renew_lifetime = 7d
  rdns = false
  forwardable = true
  default_tgs_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
  default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac

[realms]
  <DOMAIN>.COM = {
    kdc = 10.x.x.x
    admin_server = 10.x.x.x
  }

[domain_realm]
  .<domain>.com = <DOMAIN>.COM
  <domain>.com = <DOMAIN>.COM

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

jnixon55

Posted 2019-10-23T17:58:13.803

Reputation: 1

Does the AD server run Windows Server or Linux+Samba? – user1686 – 2019-10-23T19:30:15.360

It looks like ldap and samba. – jnixon55 – 2019-10-23T20:02:58.983

I can join the domain that works fine, I can query using ldapsearch. SSSD is not finding the users – jnixon55 – 2019-10-23T20:13:10.210

Answers

0

I can query using ldapsearch. SSSD is not finding the users

The difference is that you're authenticating using plain username/password, while SSSD is trying to use Kerberos with its "machine credentials" (which every AD member machine has).

Each server accepting Kerberos authentication (including AD's LDAP server) is identified by a "principal name" based on its domain name that the client uses (or IP address, although AD doesn't officially support that). For example, when connecting to dc1.example.com an LDAP client will try to get a Kerberos ticket for ldap/dc1.example.com@YOUR_REALM. (SSH would use host/… and SMB would use cifs/….)

If your environment doesn't use DNS (for no good reason), then the previous sysadmin must have added principal names for IP addresses directly to the AD DC, and you need to change them to match your new network.

Connect to the AD LDAP server using non-Kerberos authentication (it will probably require TLS/LDAPS), e.g. using Apache Directory Studio or some other LDAP client, then find the computer account belonging to the LDAP server itself. Edit its servicePrincipalName attribute (multi-value) to have the correct names. (If the server runs Samba, you can also use samba-tool spn add.)

(There shouldn't be any need to update the keytab as the Samba LDAP server is also the AD DC and will get keys directly from the AD database.)

user1686

Posted 2019-10-23T17:58:13.803

Reputation: 283 655