Jump to content

Cannot sync with active directory after domain controller change


puff
 Share

Recommended Posts

I'm using an ERA virtual appliance. Active Directory sync was successful when initially configuring ERA, and ERA is joined to the domain.

I recently upgraded domain controllers and changed domain controller names. Now when trying to sync from ERA I get "Improper format of Kerberos configuration file while initializing Kerberos 5 library":

error.png.9d65b0b6dfc10fb0a39199617fbaf379.png

I've rejoined the virtual appliance to the domain and verified that it's showing up in active directory

I updated the KDC from the Webadmin as such:

Capture1.JPG.9a7ae95d1f907a809cf6522193418777.JPG

I updated ERA sync settings as such:

Capture2.JPG.648ec930d8b9af608346bc5447265ab1.JPG

 

I've browsed through my /etc/krb5.conf file but without knowing much about it I'm not sure what it should look like. It looks like this:

[logging]

default = FILE:

kdc = FILE:

admin_server = FILE:

 

[libdefaults]

default_realm = MYDOMAIN.local

 

[realms]

MYDOMAIN.local = {

   default_domain =

   kdc = myserver.mydomain.local:

   admin_server = :

}

 

[domain_realm]

.mydomain.local = MYDOMAIN.local

 

Any help is appreciated.

Link to comment
Share on other sites

  • ESET Staff

I would try to set value of admin_server to be the same as KDC -> it is most probably value that is actually used by ERA.

In case it won't help, you could try to deploy new appliance (initially configured to use correct domain) just to get this configuration file.

 

Link to comment
Share on other sites

Tried adding the admin_server line. Also tried deleting the old domain controller out of /etc/hosts.

 

Wouldn't deploying a new one do the exact same thing as rejoining the domain? The ERA is successfully joined, and I can rejoin it with no problem and verify that it shows up in active directory. Maybe something is broken from the original configuration though. Might try a new one like you said just to see what that file says.

Link to comment
Share on other sites

Also, when I run through "Configure domain" from the server console, after the "Check Kerberos configuration in /etc/krb5.conf" I get:

Clearing Kerberos cache...

kdestroy: Improper format of Kerberos configuration file while initializing krb5

Link to comment
Share on other sites

Fixed by pulling the config from a test appliance as you suggested.  For anyone in the future who may run into this problem I edited the /etc/krb5.conf file as such:

[libdefaults]
	default_realm = MYDOMAIN.LOCAL
	ticket_lifetime = 24h
	forwardable = yes

[realms]
MYDOMAIN.LOCAL = {
	kdc = myserver.mydomain.local
}

[domain_realm]
	.mydomain.local = mydomain.local

Apparently you should NOT use the CentOS Webmin to edit kerberos settings as it adds a bunch of formatting that will break your active directory sync. Edit only from the terminal using vi or the "Configure domain" wizard in management mode.

 

Also, my default gateway was removed at some point. I ran a bunch of CentOS updates from the Webmin. Do you think that could have broken it?

 

Lastly my network interface is showing this

:Capture1.JPG.e8273fda825e5a7c629dba9e3ee5e5d9.JPG

and this:

Capture2.JPG.df3af14f73207da63bda8140701c029a.JPG

The network seems to be running normally though, but I do not have this error on the test appliance I configured. Could this be the result of anohter CentOS update? Does ESET recommend not updating CentOS as a best practice?

 

Thanks!

Edited by puff
Link to comment
Share on other sites

  • ESET Staff
On 20. 2. 2017 at 9:45 PM, puff said:

The network seems to be running normally though, but I do not have this error on the test appliance I configured. Could this be the result of anohter CentOS update? Does ESET recommend not updating CentOS as a best practice?

Thanks!

We do recommend to update (at least security-related packages) but backup (ideally snapshot) should be created prior to modification like this. We do not limit CentOS official updates and thus cannot guarantee that nothing goes wrong in the future.

Regarding this specific error: hard to say what caused that, it could be either DHCP client or also update could have overwritten configuration file -> interactive update should ask whether original (modified) or file from newly installed package should be used in case of conflict. You may also try to check modification date of relevant configuration file, which is I guess /etc/sysconfig/network-scripts/ifcfg-<interface name> and compare it with your activity on the system.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...