Update: Still getting error when trying to join the realm. Not getting much support from the Active directory folks either, suspected maybe timing mismatch, so asked for time and got response that it was correct.... I don't want to give up here but not sure what else to do ... linux books ordered.
############################## With no computer account object in active directory get this error (user is not a domain admin): KDC policy rejects request [root@PHXRASPCI01 bin]# realm join -v [email protected] abc.com * Resolving: _ldap._tcp.abc.com * Performing LDAP DSE lookup on: x.x.166.251 * Performing LDAP DSE lookup on: x.x.166.252 * Successfully discovered: abc.com Password for [email protected]: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.I7G6UY -U [email protected] ads join abc.com Enter [email protected]'s password:kerberos_kinit_password [email protected] failed: KDC policy rejects request Failed to join domain: failed to connect to AD: KDC policy rejects request ! Joining the domain abc.com failed realm: Couldn't join realm: Joining the domain abc.com failed ###################################################### Asked a domain admin to create a computer account in AD and now get insufficient privileges......yay right??? No :( [root@PHXRASPCI01 bin]# realm join -v [email protected] abc.com * Resolving: _ldap._tcp. abc.com * Performing LDAP DSE lookup on: x.x.161.252 * Performing LDAP DSE lookup on: x.x.161.251 * Successfully discovered: abc.com Password for username@ abc.com: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.Y8U2UY -U [email protected] ads join abc.com Enter [email protected]'s password: Failed to join domain: Failed to set account flags for machine account (NT_STATUS_ACCESS_DENIED) ! Insufficient permissions to join the domain abc.com realm: Couldn't join realm: Insufficient permissions to join the domain abc.com ########################################################################### Had domain admin use his credentials and get constraint violation error. [root@PHXRASPCI01 log]# realm join -v [email protected] abc.com * Resolving: _ldap._tcp. abc.com * Performing LDAP DSE lookup on: x.x.161.251 * Performing LDAP DSE lookup on: x.x.161.252 * Successfully discovered: abc.com Password for domainadmin@ abc.com: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.R8T4UY -U domainadmin@ abc.com ads join abc.com Enter [email protected]'s password: Failed to join domain: Failed to set machine spn: Constraint violation Do you have sufficient permissions to create machine accounts? ! Joining the domain abc.com failed realm: Couldn't join realm: Joining the domain abc.com failed ##################################################### Sonia Gilbert, -Engineer II, Information Protection & Compliance Team 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 [email protected] -----Original Message----- From: Jakub Hrozek [mailto:[email protected]] Sent: Thursday, February 02, 2017 10:36 PM To: [email protected] Subject: [SSSD-users] Re: account not authenticating in child domain On Thu, Feb 02, 2017 at 09:11:39PM +0000, Gilbert, Sonia wrote: > Thanks for helping out Lukas. > > Kinit resolves to dc02 then fails pre-authentication because it was not the > master KDC, after providing password, then resolves to dc01 and then gets the > policy rejects again. Tried a few times and it seems that it does not matter > which server it resolves, get the same messages about not being master and > policy reject. I also tried to set the " dns_lookup_kdc = false" but just > caused it not find a server. Klist, only see the server object in the > a.abc.com domain. > > Below are the results of KRB5_TRACE=/dev/stderr kinit [email protected]: > > [root@server01 etc]# KRB5_TRACE=/dev/stderr kinit [email protected] In general, I think you should either use -E/-C or use upper-case realm. > [17578] 1486068170.688787: Getting initial credentials for > [email protected] [17578] 1486068170.689166: Sending request (193 bytes) > to abc.com [17578] 1486068170.818519: Resolving hostname infdcpci02.abc.com. > [17578] 1486068170.883645: Sending initial UDP request to dgram > x.x.161.252:88 (dc02) [17578] 1486068170.946802: Received answer (195 > bytes) from dgram x.x.161.252:88 [17578] 1486068171.9293: Response was > not from master KDC [17578] 1486068171.9356: Received error from KDC: > -1765328359/Additional pre-authentication required [17578] > 1486068171.9425: Processing preauth types: 16, 15, 19, 2 [17578] > 1486068171.9456: Selected etype info: etype aes256-cts, salt "abc.com018443", > params "" > > [17578] 1486068435.915755: AS key obtained for encrypted timestamp: > aes256-cts/B3B5 [17578] 1486068435.915855: Encrypted timestamp (for > 1486068405.778558): plain > 301AA011180F32303137303230323230343634355AA10502030BE13E, encrypted > B9066FF3F56DC8C931B4AA95937AE59185BCE87FDC1D2BF482A575B8166CEDA85E95D7 > EF5F36253F77D6674F208413BF079CEB6B45CBB101 > [17578] 1486068435.915914: Preauth module encrypted_timestamp (2) > (real) returned: 0/Success [17578] 1486068435.915931: Produced preauth > for next request: 2 [17578] 1486068435.915978: Sending request (273 > bytes) to abc.com [17578] 1486068436.45327: Resolving hostname > infdcpci01.abc.com. > [17578] 1486068436.110256: Sending initial UDP request to dgram > x.x.161.251:88 (different server dc01) [17578] 1486068436.191100: > Received answer (102 bytes) from dgram x.x.161.251:88 Is this a DC from the same realm? > [17578] 1486068436.256271: Response was not from master KDC [17578] > 1486068436.256323: Received error from KDC: -1765328372/KDC policy > rejects request [17578] 1486068436.256366: Retrying AS request with > master KDC [17578] 1486068436.256381: Getting initial credentials for > [email protected] [17578] 1486068436.256480: Sending request (193 bytes) > to abc.com (master) > kinit: KDC policy rejects request while getting initial credentials > > > With krb5.conf: > dns_lookup_kdc = false > > [root@server01 etc]# KRB5_TRACE=/dev/stderr kinit [email protected] > [17798] 1486068606.982122: Getting initial credentials for > [email protected] [17798] 1486068606.982485: Sending request (193 bytes) > to abc.com [17798] 1486068606.982757: Retrying AS request with master > KDC [17798] 1486068606.982798: Getting initial credentials for > [email protected] [17798] 1486068606.982864: Sending request (193 bytes) > to abc.com (master) > kinit: Cannot find KDC for realm "abc.com" while getting initial > credentials Does it work if you define a 'known good' DC in krb5.conf ? > > > [root@server01 etc]# klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 host/[email protected] > 2 [email protected] > 2 [email protected] > 2 [email protected] > 2 [email protected] > 2 [email protected] > > Sonia Gilbert, -Engineer II, Information Protection & Compliance Team > 3375 Koapaka Street, 3rd Floor, Honolulu, HI 96819 | P: 808.564.7503 > [email protected] > > > > > -----Original Message----- > From: Lukas Slebodnik [mailto:[email protected]] > Sent: Thursday, February 02, 2017 10:41 AM > To: End-user discussions about the System Security Services Daemon > <[email protected]> > Subject: [SSSD-users] Re: account not authenticating in child domain > > On (02/02/17 19:55), Gilbert, Sonia wrote: > >No. Also they said that they opened up the firewall for all the ports. > > > >[root@server01 /]# kinit [email protected] Password for [email protected]: > >kinit: KDC policy rejects request while getting initial credentials > > > >Could it be trying to use krb5.keytab? Is it unique to each instance. > >Since it was removed from the realm, will it need to have a new keytab > >generated. Is that a local verification or do we also have to do something > >on the AD server? > > > Use KRB5_TRACE for extra tracing information. > e.g. > KRB5_TRACE=/dev/stderr kinit [email protected] > > LS > _______________________________________________ > sssd-users mailing list -- [email protected] To > unsubscribe send an email to [email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] To > unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
