Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-1615: Implementation of Centrify solution in environments where DMZ and internal domains exist.

Centrify DirectAudit ,   Centrify DirectControl ,   Centrify Identity Service, Mac Edition ,  

2 July,15 at 06:27 PM

Applies to: All versions of Centrify DirectControl.

Implementation of Centrify solution in environments where DMZ and internal domains exist.

If in an environment where there are AD domains in both DMZ, internal network with forest-forest 1-way trust through a firewall in place and all user auth comes from internal AD domain directly to the machines joined to DMZ domains then below are the minimum ports that needs to be opened.

Centrify Console:

If Centrify Admin console is running on a workstation in DMZ domain, Centrify console cannot browse users from remote forest because of the firewall between both DMZ, internal domains. Centrify admin console just like ADUC needs to talk to both GC and DC to get the account information from internal domains. Centrify admin console also need to have Kerberos authentication because it needs to connect as a user in the domain behind the firewall to get the account information.

Hence the following ports needs to be opened:

TCP 3268 – GC
TCP/UDP 88 – Kerberos Authentication

Centrify Agent:

TCP/UDP 88 - Kerberos Authentication

Currently DirectControl agent on Unix/Linux/MacOS only supports Kerberos authentication for user logons. For this to work in a multi-domain environment described above, the Unix workstation must ultimately talk directly to a KDC in the user's home domain. This direct conversation is carried out via Kerberos protocols over port 88. By default this conversation is performed using UDP. However in cases where a user belongs to lots of groups, the PAC information that comes back from the KDC in a successful authentication can exceed the size of a signal UDP packet. In this case the Kerberos libraries will set up a TCP connection to port 88 instead. This is why port 88 must be opened for both UDP and TCP.

TCP/UDP 464 - Kerberos Password Changes

If a user in a internal domain logs on to a Unix workstation in DMZ domain and his/her password has expired, DirectControl agent will orchestrate the immediate change of that user's password using the Kerberos kpasswd protocols. These protocols flow over port 464, and once again because of potentially large PAC payloads, may require TCP as well as UDP.

TCP/UDP 445 – Samba

If user group policies from user’s home domain needs to be applied, since Centrify Group Policy engine uses SMB transport to bring down the group policies, port 445 needs to be opened.


In a topology where there is a transitive trust relationship between the Unix workstation's home domain and the AD user logging, the Unix workstation must follow the transitive trust path, visiting each domain in between, picking up tickets for these intermediate domains as part of the authentication process. If the domain names are disjoint (i.e. there exists more than one root domain, as there would be in a cross-forest trust), the MIT Kerberos libraries as shipped cannot automatically figure out the path of trust. Centrify has enhanced the Kerberos libraries in order to do so, but these enhancements are not in the currently shipping product. In the mean time administrators can use the [capaths] directive in krb5.conf to manually configure the path of trust so that authentications can proceed. Details for the capaths directive can be found here:

References: How domains and forest trusts work over various protocols

Our console and agent running on workstations in DMZ should be able to talk with at least one DC in both root and child domains in the internal network because of the way Kerberos ticket referral implementation by Microsoft.

Centrify Corporation does not take any responsibility for the content or availability of this link and it was provided as a courtesy.  Customers should contact the vendor if there are any further questions

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

No related Articles