Bug 1399601

Hi,

this problem is blocking for me. Any chance to get an answer in next 3 days?

TIA,
Silvio

After installation, most of client operation is performed by SSSD therefore moving there to get the ports. But ultimately the bug should be moved either to LDI guide or Windows integration guide.

My tip, in addition to Kerberos ports, you will need also:
- 389 - LDAP
- 686 - LDAPS

With windows also probably:
- 3268 - Global Catalog - LDAP
- 3269 - Global Catalog - LDAPS
- 445 - maybe - SMB

For general usage:
- 123 - NTP
- 53 - DNS

For password authentication the clients must be either able to connect to the AD DC of the trusted domain or a KDC proxy configuration must be used (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_a_Kerberos_5_Server.html#KKDCP and https://www.freeipa.org/page/V4/KDC_Proxy). Please note that not only DCs of the parent domain od the user are connected but due to Kerberos ticket validation all domains in the trust path from the parent domain to the IPA domain are connected. This at least includes to the forest root.

For GSSAPI based the client does not need to connect to the AD DC. So I expect a different issue here. Are there any error messages displayed by putty? Does 'klist' called in the Windows client command or power shell list the host principal of the IPA client (host/fully.qualified.name) after trying to connect with putty and GSSAPI? Are there any sshd realated messages on the IPA client in /var/log/secure or the journal?

(In reply to Petr Vobornik from comment #3)

Hi,

THX for your answer but this looks a little bit like try and error. I use an Enterprise Linux with subscription, so I can expect that there is a documentation how an authentication and authorization of user from a trusted AD domain works, i.e. which services will be used (asked) by sssd on which server.

And to the details: normal or GC LDAP(S) maybe but why? If also SMB then we must also expect RPC and then the firewall rules will be more complicated (either DCE/MS RPC protocol inspection or a big ranger to all DCs).

DNS and NTP is configure to use the IdM server, so this is really not necessary.

I have many experiences with firewall configurations for Windows AD Clients in a DMZ like network because in my former company I was firewall admin. And there I had in this case simple temporary allowed any traffic to AD DCs with logging. So I would be able to found what is missing. But now the firewall will be administrated by a service provider, therefore “try and error” is to possible way. Otherwise from a DMZ to the company AD DCs should be opened not more as really necessary!

Br,
Silvio

(In reply to Sumit Bose from comment #4)

Hi,

I know the necessity that all DCs must be accessible. But THX for the hint. And we don't have really an forest but some User Principal Names are not <Login-Name>@<AD Domain>, this is why we must use the configuration for enterprise UPNs.

And to show it simple: I have setup 4 RH 7.2 servers which are part of one distributed Application. All are joined to the same IdM domain, 3 are in the LAN and one must be in the DMZ. Logon on the three LAN server as user from the trusted AD is possible (with password and also without using GSSAPI). From the same ssh client it is possible to logon to the 4th server as local and normal IdM user but not as user of the trusted AD. On this server an kinit using the same AD user works.

I.e. Kerberos is proper configured and can contact the AD DCs, but sssd needs additional services which are not described in any IdM/FreeIPA documentation.

I have checked the sssd logs, but there is no information. I have hoped that the info which ports are needed are known on your side and was only forgotten in the documentation. I have not the time to start debugging now. The server will nedded tomorrow and because Red Hat promotes especially the AD trust feature of IdM for companies I'm wonder that I'm the first user with this problem.

Br,
Silvio

(In reply to Silvio Wanka from comment #6)
> (In reply to Sumit Bose from comment #4)
> 
> Hi,
> 
> I know the necessity that all DCs must be accessible. But THX for the hint.
> And we don't have really an forest but some User Principal Names are not
> <Login-Name>@<AD Domain>, this is why we must use the configuration for
> enterprise UPNs.
> 
> And to show it simple: I have setup 4 RH 7.2 servers which are part of one
> distributed Application. All are joined to the same IdM domain, 3 are in the
> LAN and one must be in the DMZ. Logon on the three LAN server as user from
> the trusted AD is possible (with password and also without using GSSAPI).
> From the same ssh client it is possible to logon to the 4th server as local
> and normal IdM user but not as user of the trusted AD. On this server an
> kinit using the same AD user works.
> 
> I.e. Kerberos is proper configured and can contact the AD DCs, but sssd
> needs additional services which are not described in any IdM/FreeIPA
> documentation.

SSSD does more than a simple kinit on an IdM client, it tries to validate the ticket as well to prevent a specific kind of attacks as described in comment #4. I would expect that there are messages like ' TGT failed verification using key ...' in the krb5_child.log file if debug_level is set to 1 or higher on the host in the DMZ.

You can disable the validation by setting 'krb5_validate = false' in the [domain/...] section of sssd.conf on the host in the DMZ.

> 
> I have checked the sssd logs, but there is no information. I have hoped that
> the info which ports are needed are known on your side and was only
> forgotten in the documentation. I have not the time to start debugging now.
> The server will nedded tomorrow and because Red Hat promotes especially the
> AD trust feature of IdM for companies I'm wonder that I'm the first user
> with this problem.
> 
> Br,
> Silvio

Sumit, if I understand Silvio correctly, he would just like set of ports which should be opened for out-band communication on client so that it can communicate with IPA server and AD DC, right? 

It is not about changing config to enable e.g. just Kerberos to go through, right?

So was the list in comment 3, OK?

In comment 5 "THX for your answer but this looks a little bit like try and error." It is true that it is not documented. Thank you for the feedback. This bz will be serve as a basis for improving the doc.  To avoid "try and error" I'd recommend to open support case with Red Hat support. Bugzilla is more an engineering tool to discuss the technical aspects.

(In reply to Petr Vobornik from comment #8)

The question was: "which ports must be opened on an external firewall for outgoing traffic to the AD DC, so that trusted AD users can be logon". The ports which are needed to communicated to the IPA server are well documented (not for an external firewall, instead for the internal on the IPA server, but these are of course the same).

OK, if nobody from the engineering resp. development team can answer of my question then move this issue to a documentation issue and I must find another way. But to complete the documentation you must also find the answer ;-)

Thx & Br,
Silvio

Ah, sorry, my comment #4 is not explicit enough. The Kerberos port 88 must be open at least on TCP (but UDP would be good as well for e.g. for faster error reporting in some cases) for all IPA clients and servers to all AD DCs.

About documentation 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#trust-req-ports

list the ports that must be opened additionally for accessing AD resources but also mentions that LDAP, Kerberos and DNS must be opened and gives a link to 

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#tab.ipa-ports

But I agree that it would be easier and more obvious to add those ports to the table as well.


HTH

bye,
Sumit

(In reply to Sumit Bose from comment #10)

THX, but this not what I need to know because

1. The 1st link describes that must be opened on the IdM server and the AD domain controllers to create and use a two way trust.

2. The 2nd link describes that must be opened on a IdM server that a IdM client can use the IdM services. This is this what is currently opened on the external firewall for outgoing traffic to the IdM servers. The join (ipa-client-install) wouldn't have been successfully without this openings. And this it what I mean with “The ports which are needed to communicated to the IPA server are well documented” in comment #9,

Of course if we would open all this ports to the AD DCs it maybe work except sssd uses also RPC (TCP/135 + returned ports). But if we must open the same ports as for a Windows client in the DMZ then we can forget this. This is a security no-go. Kerberos is OK, LDAP already problematic but otherwise IdM is also accessible via LDAP. GC and SMB should not be accessible from DMZ. Maybe I must uninstall ipa-client and configure SSSD manually to use only LDAP with IdM servers.

Note: The default Red Hat firewall settings are to restrict incoming traffic but no outgoing traffic. That is the reason why the FreeIPA and also the RH IdM documentations only describes, what must be opened on the IPA/IdM server. For FreeIPA is this OK, but Red Hat is an Enterprise product and competes e.g. with VMware. VMware describes in detail which ports must be opened between which components also between clients and different vSphere parts. In Enterprise environments is this a “must have” because firewalls between server and client networks are there no curiosity.

THX,
Silvio

(In reply to Silvio Wanka from comment #11)
> (In reply to Sumit Bose from comment #10)
> 
> THX, but this not what I need to know because
> 
> 1. The 1st link describes that must be opened on the IdM server and the AD
> domain controllers to create and use a two way trust.
> 
> 2. The 2nd link describes that must be opened on a IdM server that a IdM
> client can use the IdM services. This is this what is currently opened on
> the external firewall for outgoing traffic to the IdM servers. The join
> (ipa-client-install) wouldn't have been successfully without this openings.
> And this it what I mean with “The ports which are needed to communicated to
> the IPA server are well documented” in comment #9,

ok, I guess a section should be added to the documentation explaining what options are available for clients in a DMZ or behind firewalls and what are minimal requirements to make it work.

> 
> Of course if we would open all this ports to the AD DCs it maybe work except
> sssd uses also RPC (TCP/135 + returned ports). But if we must open the same

SSSD does not use RPC or any other SMB/CIFS related ports on IPA clients. As said IPA client must be able to send and receive Kerberos packets from the AD DCs of the trusted forest on port 88 preferably via TCP and UDP. All other communication (LDAP, DNS) runs via the IPA server. 

> ports as for a Windows client in the DMZ then we can forget this. This is a
> security no-go. Kerberos is OK, LDAP already problematic but otherwise IdM
> is also accessible via LDAP. GC and SMB should not be accessible from DMZ.
> Maybe I must uninstall ipa-client and configure SSSD manually to use only
> LDAP with IdM servers.
> 
> Note: The default Red Hat firewall settings are to restrict incoming traffic
> but no outgoing traffic. That is the reason why the FreeIPA and also the RH
> IdM documentations only describes, what must be opened on the IPA/IdM
> server. For FreeIPA is this OK, but Red Hat is an Enterprise product and
> competes e.g. with VMware. VMware describes in detail which ports must be
> opened between which components also between clients and different vSphere
> parts. In Enterprise environments is this a “must have” because firewalls
> between server and client networks are there no curiosity.
> 
> THX,
> Silvio

Docu problem can't be Severity: high  ;-)

Reassigning to the docs component.

I made some initial changes to the ports requirements section. I've reached out to developers for review and clarification.

The updated Firewalls and Ports section now includes information about port requirements for clients. I also restructured the section to clarify all the port requirements.

I decided not to add the list of ports from the Linux Domain Identity guide to this guide as well. The above-mentioned restructuring helped clarify the port requirements even without duplicating the content in this way.

The update is now available on the Customer Portal.