LDAP Upgrade Information

Replication Overview

On August 19th ITS will be upgrading its LDAP infrastructure to a fully load-balanced environment with automatic fail-over and disaster-recovery. We are inviting the technical community to test their connections to the new environment in advance.

Please note: The system will not be available for testing on or after Friday 8/16 as we prepare for the upgrade on Monday 8/19.

To test connections with your service accounts, please change your LDAP Server to testldap.ldap.uconn.edu.We support insecure 389, and STARTTLS on 389 and Secure 636.

During the testing phase you will be able to use:

  • testkadmin.uconn.edu: For your admin server
  • testkerberos.uconn.edu: for your KDC server

If you use Active Directory connected Kerberos, this page does not apply to you.

Sample /etc/krb5.conf file:

[logging]
	default = FILE:/var/log/krb5libs.log
	kdc = FILE:/var/log/krb5kdc.log
	admin_server = FILE:/var/log/kadmind.log

[libdefaults]
	dns_lookup_realm = false
	ticket_lifetime = 24h
	renew_lifetime = 7d
	forwardable = true
	rdns = false
	default_realm = UCONN.EDU
	default_ccache_name = KEYRING:persistent:%{uid}

[realms]
UCONN.EDU = {
	kdc = testkerberos.uconn.edu
	admin_server = testkadmin.uconn.edu
}

[domain_realm]
	.uconn.edu = UCONN.EDU
	uconn.edu = UCONN.EDU
During the testing phase you will be able to use:

  • testkadmin.uconn.edu: For your admin server
  • testkerberos.uconn.edu: for your KDC server

If you use Active Directory connected Kerberos, this page does not apply to you.

Sample /etc/krb5.conf file:

[logging]
	default = FILE:/var/log/krb5libs.log
	kdc = FILE:/var/log/krb5kdc.log
	admin_server = FILE:/var/log/kadmind.log

[libdefaults]
	dns_lookup_realm = false
	ticket_lifetime = 24h
	renew_lifetime = 7d
	forwardable = true
	rdns = false
	default_realm = UCONN.EDU

[realms]
UCONN.EDU = {
	kdc = testkerberos.uconn.edu
	admin_server = testkadmin.uconn.edu
}

[domain_realm]
	.uconn.edu = UCONN.EDU
	uconn.edu = UCONN.EDU
The Java virtual machine (JVM) caches DNS name lookups. When the JVM resolves a hostname to an IP address, it caches the IP address for a specified period of time, known as the time-to-live (TTL). In many cases, this is a one-time lookup.
This will be incompatible with the Global Server Load Balancing (GSLB) performed by the University’s Infoblox system. In the case of a disaster where the MSB and HBL Data-Centers are not available, Infoblox will change a number of DNS A records
to point to their Azure counterparts. If your JVM does not understand that this transition will take place, your application will cease to work.To modify the JVM’s TTL, set the networkaddress.cache.ttl property value. Use one of the following methods, depending on your needs:

  • globally, for all applications that use the JVM. Set networkaddress.cache.ttl in the $JAVA_HOME/jre/lib/security/java.security file:

    networkaddress.cache.ttl=60

  • for your application only, set networkaddress.cache.ttl in your application’s initialization code:

    java.security.Security.setProperty(“networkaddress.cache.ttl” , “60”);

Generalized Playbook for the morning of the 19th‘s maintenance window:

  • 5:00am: NetID site will be disabled for password changes. From this point no password changes till the migration has been completed will be honored until the migration is complete.
  • A current snapshot of the environment will be taken and copied to the new infrastructure.
  • Scheduled jobs will be delayed until migration is completed
  • Infrastructure will be populated with current data and the replication process to all cluster nodes will begin
  • 6:00am: DNS records will be cut-over to new infrastructure
  • ITS Managed Authentication services will be cut-over to new infrastructure
  • Nightly Sync from ID System will be triggered
  • Delayed scheduled jobs will be triggered
  • Done!

Any situation or issue that would push the project outside of the morning maintenance window will trigger a reschedule of the migration to a later date.