[Freeipa-users] sssd compatibility with older RHEL 6 minor releases.
Hello all. The environment i'm currently working to migrate under IPA identity management contains mostly RHEL 6.2 servers. I'm planing to use Active Directory Cross Forest Trust for Identities, IPA as sudo provider, and all the other goodies that IPA provides. If i want to enjoy all the new features (at least most of them), i know that clients have to be sssd version 1.9. And if i want IPA to be auto configured as sudo provider it has to be sssd 1.11. When reading the mailing list i noticed that sssd 1.11 is mentioned as feature of rhel 6.6. What i would like and understand is what could go wrong if i will install sssd 1.11 on rhel 6.2 servers.And what is is your general recommendations for older RHEL 6 (minor) releases? Thanks in advance, Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
Sorry for the late response. I can confirm that with 3.3.3-28.el7_0.3, i'm able to fetch the sub-domains and to log with its users. Thank you ! 2015-01-04 10:17 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: -- Hello all. I'm working on integrating AD trust feature in the forest of a large organization (Its network is not connected to the internet). First I tested the trust in clean environment (that i have deployed) to simulate production forest deployment , in the following configuration: The forest root domain : red.com Second Domain tree : blue.com IPA : linux.blue.com All the AD DCs are 2008 R2 server and 2008 R2 functional level. IPA server in installed on RHEL 7. ipa-server-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 With help of the mailing list, all works fine. Users from both red.com and blue.com are able to log into IPA domain. After the success, I proceeded to test the trust in organization's test environment. The installation of the trust itself has completed successfully. But although users from *red.com http://red.com* were able to log into IPA domain, users from *blue.com http://blue.com* couldn't. After checking the sssd logs it seemed as blue.com domain is unknown to IPA. Therefore I ran *ipa trustdomain-find red.com http://red.com *in both environments, to see if there are any differences. And indeed there were: While in the clean environment, the command returned both *red.com http://red.com* and *blue.com http://blue.com* domains, in organization's test environment it returned only *red.com http://red.com*. I tried to re fetch the domain with *ipa trust-fetch-domains red.com http://red.com *but it returned the message - No new trust domains were found. It made me think that maybe the AD is not returning all domains in the forest. I opened wireshark on both environments and ran *ipa trust-fetch-domains red.com http://red.com *to see what is been sent from AD to IPA. In both environments I seen the DsrEnumerateDomainTrusts request and response. Reading the content of response showed that in both environments, the response contained *red.com http://red.com* and *blue.com http://blue.com* domain. After inspecting the structures that contain domains information (DS_DOMAIN_TRUSTS) , I noticed that in both environments the *TrustAttribute *of red.com is set to 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 If this bit is set, then the trusted domain is within the same forest. Only evaluated on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. While I couldn't find specific information about 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 or a reason why the attributes would be different in the two deployments. I asked for advice from Microsoft IT guy in the organization. He said that difference in the *TrustAttribute *is caused by the fact, that the clean environment was created as Windows Server 2008, while the test (and production) forest was created as windows 2000 servers (about 12 years ago) and the forest was gradually upgraded to 2003 and 2008 along the years. Couldn't find more information on the attribute for windows server 2000/2003 but the theory sounds quite logical. I decided to check if *TrustAttribute *influences IPA's domain fetch. fetch_domains function in /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py contains the following lines of code: trust_attributes = dict( NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . result = [] for t in domains.array: *if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and* *(t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])):* res = dict() res['cn'] = unicode(t.dns_name) res['ipantflatname'] = unicode(t.netbios_name) res['ipanttrusteddomainsid'] = unicode(t.sid)
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
It will take some time to bring the new packages into organizations network. But as soon as it happens, ill inform you on the results. Thank you. 2015-01-04 10:17 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: -- Hello all. I'm working on integrating AD trust feature in the forest of a large organization (Its network is not connected to the internet). First I tested the trust in clean environment (that i have deployed) to simulate production forest deployment , in the following configuration: The forest root domain : red.com Second Domain tree : blue.com IPA : linux.blue.com All the AD DCs are 2008 R2 server and 2008 R2 functional level. IPA server in installed on RHEL 7. ipa-server-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 With help of the mailing list, all works fine. Users from both red.com and blue.com are able to log into IPA domain. After the success, I proceeded to test the trust in organization's test environment. The installation of the trust itself has completed successfully. But although users from *red.com http://red.com* were able to log into IPA domain, users from *blue.com http://blue.com* couldn't. After checking the sssd logs it seemed as blue.com domain is unknown to IPA. Therefore I ran *ipa trustdomain-find red.com http://red.com *in both environments, to see if there are any differences. And indeed there were: While in the clean environment, the command returned both *red.com http://red.com* and *blue.com http://blue.com* domains, in organization's test environment it returned only *red.com http://red.com*. I tried to re fetch the domain with *ipa trust-fetch-domains red.com http://red.com *but it returned the message - No new trust domains were found. It made me think that maybe the AD is not returning all domains in the forest. I opened wireshark on both environments and ran *ipa trust-fetch-domains red.com http://red.com *to see what is been sent from AD to IPA. In both environments I seen the DsrEnumerateDomainTrusts request and response. Reading the content of response showed that in both environments, the response contained *red.com http://red.com* and *blue.com http://blue.com* domain. After inspecting the structures that contain domains information (DS_DOMAIN_TRUSTS) , I noticed that in both environments the *TrustAttribute *of red.com is set to 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 If this bit is set, then the trusted domain is within the same forest. Only evaluated on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. While I couldn't find specific information about 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 or a reason why the attributes would be different in the two deployments. I asked for advice from Microsoft IT guy in the organization. He said that difference in the *TrustAttribute *is caused by the fact, that the clean environment was created as Windows Server 2008, while the test (and production) forest was created as windows 2000 servers (about 12 years ago) and the forest was gradually upgraded to 2003 and 2008 along the years. Couldn't find more information on the attribute for windows server 2000/2003 but the theory sounds quite logical. I decided to check if *TrustAttribute *influences IPA's domain fetch. fetch_domains function in /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py contains the following lines of code: trust_attributes = dict( NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . result = [] for t in domains.array: *if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and* *(t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])):* res = dict() res['cn'] = unicode(t.dns_name) res['ipantflatname'] = unicode(t.netbios_name) res['ipanttrusteddomainsid'] = unicode(t.sid)
Re: [Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
I would like to make a correction. The change i made is: if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST'] *or* (t.trust_attributes 0x0080)) and (t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): and not: if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST'] *||* (t.trust_attributes 0x0080)) and (t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level
Hello all. I'm working on integrating AD trust feature in the forest of a large organization (Its network is not connected to the internet). First I tested the trust in clean environment (that i have deployed) to simulate production forest deployment , in the following configuration: The forest root domain : red.com Second Domain tree : blue.com IPA : linux.blue.com All the AD DCs are 2008 R2 server and 2008 R2 functional level. IPA server in installed on RHEL 7. ipa-server-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 With help of the mailing list, all works fine. Users from both red.com and blue.com are able to log into IPA domain. After the success, I proceeded to test the trust in organization's test environment. The installation of the trust itself has completed successfully. But although users from *red.com http://red.com* were able to log into IPA domain, users from *blue.com http://blue.com* couldn't. After checking the sssd logs it seemed as blue.com domain is unknown to IPA. Therefore I ran *ipa trustdomain-find red.com http://red.com *in both environments, to see if there are any differences. And indeed there were: While in the clean environment, the command returned both *red.com http://red.com* and *blue.com http://blue.com* domains, in organization's test environment it returned only *red.com http://red.com*. I tried to re fetch the domain with *ipa trust-fetch-domains red.com http://red.com *but it returned the message - No new trust domains were found. It made me think that maybe the AD is not returning all domains in the forest. I opened wireshark on both environments and ran *ipa trust-fetch-domains red.com http://red.com *to see what is been sent from AD to IPA. In both environments I seen the DsrEnumerateDomainTrusts request and response. Reading the content of response showed that in both environments, the response contained *red.com http://red.com* and *blue.com http://blue.com* domain. After inspecting the structures that contain domains information (DS_DOMAIN_TRUSTS) , I noticed that in both environments the *TrustAttribute *of red.com is set to 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 If this bit is set, then the trusted domain is within the same forest. Only evaluated on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. While I couldn't find specific information about 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 or a reason why the attributes would be different in the two deployments. I asked for advice from Microsoft IT guy in the organization. He said that difference in the *TrustAttribute *is caused by the fact, that the clean environment was created as Windows Server 2008, while the test (and production) forest was created as windows 2000 servers (about 12 years ago) and the forest was gradually upgraded to 2003 and 2008 along the years. Couldn't find more information on the attribute for windows server 2000/2003 but the theory sounds quite logical. I decided to check if *TrustAttribute *influences IPA's domain fetch. fetch_domains function in /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py contains the following lines of code: trust_attributes = dict( NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . result = [] for t in domains.array: *if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and* *(t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])):* res = dict() res['cn'] = unicode(t.dns_name) res['ipantflatname'] = unicode(t.netbios_name) res['ipanttrusteddomainsid'] = unicode(t.sid) res['ipanttrustpartner'] = res['cn'] result.append(res) The bit-wise operation is preformed to check if the trust attribute is set to TRUST_ATTRIBUTE_WITHIN_FOREST (0x0020) and if so, the trust is added to result array. It seems the value of *TrustAttribute *set to 0x0080 is the reason the domain
Re: [Freeipa-users] Importing /etc/sudoers into IPA.
Thanks you for the response. The amount of rules is : 50+ Host_Alias 50+ User_Alias 10+ Runas_Alias 450+ Cmnd_Alias The user/groups -- command mapping itself is about 50 more rules. 2014-12-27 23:28 GMT+02:00 Rob Crittenden rcrit...@redhat.com: Genadi Postrilko wrote: I'm not sure i understand what you mean. IPA uses its own schema for sudo so the script will not work. I haven't looked at it so don't know what amount of effort would be needed to make it work. You can create the sudo commands and rules but in order to associate user and groups with the rules they will need to exist. How many rules are we talking about? rob 2014-12-22 22:50 GMT+02:00 Craig White cwh...@skytouchtechnology.com mailto:cwh...@skytouchtechnology.com: I would not recommend that path with FreeIPA. __ __ This is clearly the way to go with FreeIPA __ __ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html __ __ Craig White System Administrator O623-201-8179 M602-377-9752 __ __ cid:image001.png@01CF86FE.42D51630 __ __ SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 __ __ *From:*freeipa-users-boun...@redhat.com mailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Genadi Postrilko *Sent:* Monday, December 22, 2014 1:38 PM *To:* freeipa-users@redhat.com mailto:freeipa-users@redhat.com *Subject:* [Freeipa-users] Importing /etc/sudoers into IPA. __ __ Hello All. __ __ I'm planning to migrate the /etc/sudoers into the IPA. I have read that sudoers2ldif should be used to import /etc/sudoers into LDAP. http://www.sudo.ws/sudo/readme_ldap.html The script will work as is? or changes should be add? Should the users and group mentioned in sudoers be created beforehand? __ __ Thanks, Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Importing /etc/sudoers into IPA.
OK, I will try and brew something. Thank you for the response. 2014-12-23 23:28 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: Hi, -- Hello All. I'm planning to migrate the /etc/sudoers into the IPA. I have read that sudoers2ldif should be used to import /etc/sudoers into LDAP. http://www.sudo.ws/sudo/readme_ldap.html The script will work as is? or changes should be add? Should the users and group mentioned in sudoers be created beforehand? FreeIPA schema for sudo is different from what the script expects and produces so it will not be helpful. You can instead write own script that converts existing /etc/sudoers into a series of calls of IPA command line. I have no handy examples of how to do it. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Importing /etc/sudoers into IPA.
Hello All. I'm planning to migrate the /etc/sudoers into the IPA. I have read that sudoers2ldif should be used to import /etc/sudoers into LDAP. http://www.sudo.ws/sudo/readme_ldap.html The script will work as is? or changes should be add? Should the users and group mentioned in sudoers be created beforehand? Thanks, Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Importing /etc/sudoers into IPA.
I'm not sure i understand what you mean. 2014-12-22 22:50 GMT+02:00 Craig White cwh...@skytouchtechnology.com: I would not recommend that path with FreeIPA. This is clearly the way to go with FreeIPA https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html Craig White System Administrator O 623-201-8179 M 602-377-9752 [image: cid:image001.png@01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Genadi Postrilko *Sent:* Monday, December 22, 2014 1:38 PM *To:* freeipa-users@redhat.com *Subject:* [Freeipa-users] Importing /etc/sudoers into IPA. Hello All. I'm planning to migrate the /etc/sudoers into the IPA. I have read that sudoers2ldif should be used to import /etc/sudoers into LDAP. http://www.sudo.ws/sudo/readme_ldap.html The script will work as is? or changes should be add? Should the users and group mentioned in sudoers be created beforehand? Thanks, Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Certificate Authorities requirement for Cross realm trust?
In the Windows Integration guide the need for CA is mentioned. Both Active Directory and Identity Management must be configured with integrated certificate services. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-requirements I cannot install CA-less IPA if i want to create a Cross realm trust? If so, why? As far as i understand the Trust is Kerberos based. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa-server from copr repo
Ok :) Thank you for the response. 2014-11-21 10:39 GMT+02:00 Martin Kosek mko...@redhat.com: On 11/21/2014 09:30 AM, Genadi Postrilko wrote: Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) Martin Will it be included as a tech preview or fully supported? You mean if whole IPA will be Tech Preview or Fully Supported? The functionality that was present and supported in RHEL-7.0 of course cannot be suddenly put to Tech Preview. I cannot disclose at this moment which *new* features would be supported and which would be TP, wait and see - but I think this information will be publicly available even in RHEL-7.1 Beta :-) On 11/19/2014 10:24 PM, Tamas Papp wrote: On 11/19/2014 09:29 PM, Martin Kosek wrote: Ah, yes. This one is not a problem with the CentOS port, but rather existing problem in FreeIPA 4.1.1 which will be fixed in FreeIPA 4.1.2 on all platforms, including Fedora 21 and CentOS. See upstream ticket: https://fedorahosted.org/freeipa/ticket/4716 Until this is fixed, correct workaround is to chown this directory by named:named and chmod rights to 0770. I will with the team when 4.1.2 is about to be released, if it is not soon, I can just add the patch to the 4.1.1 in Copr repo. Thanks for all. Just a question. My understanding is that 4.x will not hit RH 7 ever. So for IPA 4.x we have to wait until RH8, am I correct? Thanks, tamas Actually no, FreeIPA 4.1 is planned to be included in RHEL-7.1 release - so you can look forward to that :-) Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Using Selective authentication on AD-IPA trust.
We need to get host/ipa.master and HTTP/ipa.master principals to get authenticated read only access to AD DC and LDAP servers. The problem with granting this access in 'Selective authentication' case will prevent the trust from working. Only the IPA servers are accessing AD DC? Or all the hosts (Clients) are also preforming query's on GC's LDAP, as you described in this older mail exchange : https://www.redhat.com/archives/freeipa-users/2014-January/msg00181.html *IPA needs to be able to look up users and groups in AD. To do so, it uses Kerberos authentication against AD's Global Catalog services with own credentials (per each IPA host). We are using cross-realm Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and vice versa, so IPA hosts can bind as their own identity (host/...) to AD.* If the first case is true, then read only permission can be granted to IPA server's *only *(?), . If the second is true, there is no escape but to convince (somehow) the AD IT guys. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Using Selective authentication on AD-IPA trust.
Hello all ! I am working on integrating IPA in a Microsoft dominated organization. After playing around with Cross forest trust and Directory server synchronization i came to the conclusion that Trust is the right way to go. Because it involves less configuration on AD side and its the direction the development community is focusing on. As i started discussing with AD administrators team, they expressed their concerns on the two-way trust needed. I have found the following thread in the freeipa archives: https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html where Simo Sorce explained why the two way trust is necessary. But then this thread appeared: https://www.redhat.com/archives/freeipa-users/2014-September/msg00276.html The discussion in the thread helped me *a lot* (especially the summary https://www.redhat.com/archives/freeipa-users/2014-September/msg00303.html) to explain the AD team why two-way trust is necessary and *not *a security risk. After convincing them that two-way trust in necessary, they still have put up a demand that the out-going AD-IPA trust authentication will be configured as *Selective **authentication.* Selective authentication is described as follows: *Windows will not automatically authenticate users form the specified forest for any resources in the local forest. After you close this dialog. grant individual access to each domain and server that you want to make available to users in the specified forest.* While the default is Forest- wide authentication: *Windows will automatically athenticate users from the specified forest for the recourses in the local forest.* Can this be done? Or it will break how IPA operates the trust? Thanks. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust
Both Domain functional level and Forest functional level are Windows Server 2008 R2. 2014-10-08 9:24 GMT+02:00 Sumit Bose sb...@redhat.com: On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain ( LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Error: invalid 'AD domain controller' when establishing trust
The ipa server is able to resolve blue.com. dig SRV _ldap._tcp.blue.com does return answer. 2014-10-08 14:11 GMT+02:00 Dmitri Pal d...@redhat.com: On 10/08/2014 07:29 AM, Genadi Postrilko wrote: Both Domain functional level and Forest functional level are Windows Server 2008 R2. Does blue.com actually resolves to the AD host? May be there is some DNS misconfiguration on the Linux system where you run the command from. 2014-10-08 9:24 GMT+02:00 Sumit Bose sb...@redhat.com: On Wed, Oct 08, 2014 at 02:42:47AM +0200, Genadi Postrilko wrote: Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain ( LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level can you check the domain and forest functional levels of your domains? You can find this information in the 'Active Directory Domains and Trusts' utility by right-clicking the domain name and selecting properties? iirc the minimal level we support in 2003R2. bye, Sumit Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Error: invalid 'AD domain controller' when establishing trust
Hello. I am attempting to create trust between AD and IPA. I have deployed AD environment as follows: I have created domain RED.COM Then i add new domain tree root - BLUE.COM. Now i would like to establish trust with IPA as a sub domain (LINUX.BLUE.COM) of BLUE.COM. I followed the guide and when reaching to trust agreement creation i stumbled into this error: ipa trust-add --type=ad blue.com --admin Administrator --password Active directory domain administrator's password: ipa: ERROR: invalid 'AD domain controller': unsupported functional level Both AD server are 2008 R2. IPA version is 3.3, installed on RHEL 7. Help will be appreciated. Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Firewall rules for AD TRUST
Hello all again. I am trying to make sense of the documentation on firewall rules for in IPA/AD Trust relationship. The official RHEL 7 Windows Integration Guide states in section - 5.2.6 Firewalls And Ports, that: *For a trust relationship, the Active Directory server and IdM server must have almost all of the required system ports open that are required for an IdM server installation, with the exception of the LDAP ports.* So the following ports should be open (on the side of the IPA) : 80, 443, 88, 464, 53 - TCP 88, 464, 53, 123 - UDP And also : *The IdM backend LDAP server must not be reachable by the Active Directory domain controller. The associated ports — 389 and 636 — on the IdM server host must be shut down for the Active Directory domain controller.* https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-requirements After searching the mail archives i found the next post: https://www.redhat.com/archives/freeipa-users/2014-August/msg00032.html *LDAP over UDP is required for trusts as connectionless LDAP (CLDAP) is part of discovery protocol that AD machines expect to work. Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not hurt.* But the HowTo documentation (on trust) in FreeIPA site states the following: *Previously we recommended that you should make sure that IPA LDAP server is not reachable by AD DC by closing down TCP ports 389 and 636 for AD DC. Our current tests lead to the assumption that this is not necessary anymore.* http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration Also after the ipa-adtrust-install script completes it outputs the following message: *Setup complete* *You must make sure these network ports are open: * *TCP Ports: * ** 138: netbios-dgm * ** 139: netbios-ssn * ** 445: microsoft-ds * *UDP Ports: * ** 138: netbios-dgm * ** 139: netbios-ssn * 389: (C)LDAP * 445: microsoft-ds * Those ports need to be opened between the AD and IPA server? Finally i would like to understand if all the ports that should to be opened on the side of the IPA server, also should be opened at the AD on the both directions (Incoming, outgoing)? I can see that the firewall configuration for AD not yet documented in the HowTo guide. Thanks, Genadi. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot [SOLVED]
The NetworkManager service was overriding the /etc/resolv.conf, so kinit couldn't resolve with the right DNS server. After stopping the NetworkManager and canceling its start up on boot, i can kinit with no problem. Didn't even had to change to forward-policy=only. Thank you for the help, and sorry i haven't noticed it sooner. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
2014-09-22 9:29 GMT+03:00 Petr Spacek pspa...@redhat.com: 'IPA forwarders' are exactly the same as normal 'BIND forward zone' so they involve normal DNS cache. Which type of forwarder do you have configured? Is your 'forwarding policy' set to 'first' (default) or 'only'? I have default forwarding policy: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 Forwarding policy 'first' (combined with cache) could be the cause of your problem. 'First' policy instructs BIND to contact the configured server and if it fails (because of timeout) BIND will re-try the same query using normal recursion. Depending on your network configuration, the normal DNS recursion can return different results than forwarding(^1). In this case BIND can cache e.g. NXDOMAIN answer from some other server and this answer will stay in cache for TTL value in the given answer. As a result, IPA could get cached NXDOMAIN instead of correct SRV records for AD until the TTL in cache expires. This is of course a wild guess. Detailed logs from named (log level 5 or higher+querylog) could tell us what exactly happened. This the named log after i increased the debug level to 5 and enabled querylog: https://gist.github.com/anonymous/89308cbca3b07252674c Have a nice day! (^1) I would argue that this points to a flaw in network configuration... The test involvement is just bunch of VMs in NAT configurations. Petr^2 Spacek Thank you for the help. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
I have recreated the problem. Rebooted the AD and now cannot kinit with AD users. [root@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit y...@blue.com [22865] 1411157693.26121: Resolving unique ccache of type KEYRING [22865] 1411157693.26167: Getting initial credentials for y...@blue.com [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial credentials The AD configured as forwarder: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 i can ping the AD machine. 2014-09-16 10:28 GMT+03:00 Sumit Bose sb...@redhat.com: On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit y...@blue.com HTH bye, Sumit I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
I have configured the DNS with the AD as a forwarder (ipa-server-install --forwarder), just as explaine in RHEL 7 Windows Integration guide - 5.3.1. Setting up Trust with IdM as a DNS Subdomain of Active Directory. To use KRB5_TRACE ill need to recreate the issue. 2014-09-16 10:28 GMT+03:00 Sumit Bose sb...@redhat.com: On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit y...@blue.com HTH bye, Sumit I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] freeIPA client sudo / sssd setup
Have you installed libsss_sudo? Try to follow the instruction here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html and http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf 2014-04-08 22:17 GMT+03:00 Mark Gardner malek...@gmail.com: I know I'm missing something simple. But I just can't get this ipa client to accept any sudo rules. -sh-4.1$ sudo -l [sudo] password for test...@domain.com: User test...@domain.com is not allowed to run sudo on cypress. -sh-4.1$ id uid=11659(test...@domain.com) gid=11659(test...@domain.com) groups=11659(testadm@domain. com),16047(ad_klasadm) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -sh-4.1$ kinit admin Password for ad...@hosted.domain.com: -sh-4.1$ ipa sudorule-show operations Rule name: operations Description: KLAS / System Admins Enabled: TRUE Command category: all Users: localadm User Groups: ad_operations, ad_operations_external, ad_klasadm, ad_klasadm_external /var/log/sssd/sssd_sudo.log (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [testadm] from [DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requestinginfo about [test...@domain.com] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [test...@domain.com] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [test...@domain.com] from [DOMAIN.COM] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser= test...@domain.com )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*))((dataExpireTimestamp=1396984126)))] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=test...@domain.com )(sudoUser=#11659)(sudoUser=%ad_klasadm)(sudoUser=+*)))] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [test...@domain.com] (Tue Apr 8 15:08:46 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! [root@cypress etc]# cat nsswitch.conf # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the db in front of files for entries you want to be # looked up first in the databases # # Example: #passwd:db files nisplus nis #shadow:db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss sudoers:files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc:nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc:files services: files sss netgroup: files sss publickey: nisplus automount: files aliases:files nisplus [root@cypress etc]# cd sssd [root@cypress sssd]# ls sssd.conf sssd.conf.deleted sssd.conf.sv [root@cypress sssd]# cat sssd.conf [domain/hosted.domain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hosted.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = cypress.hosted.domain.com chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa.hosted.domain.com ldap_tls_cacert = /etc/ipa/ca.crt debug_level=6 # # sudo integration #
Re: [Freeipa-users] Understanding role of the certificate in client - server communication.
Thank you for the answer. Is the communication between IPA Client and Server HTTPS based? not just SSL over TCP? So is Kerberos? Does it have to be over HTTP? or its purely over TCP/UDP? 2014-03-19 10:56 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: On Wed, 19 Mar 2014, Genadi Postrilko wrote: Thank you for the answer. Sory if i lack the knowledge, but why SSL is needed when using kerberos? Kerberos is based on 3th party that is trusted, why there is a need for public key encryption? Using Kerberos only, without asking for integrity and confidentiality services, without channel bindings to the outer encryption, is prone to MITM even with valid TLS channels. Use of certificates allows to perform mutual authentication at the SSL level and later perform channel bindings of the tunnelled Kerberos communication. Note that Kerberos over HTTP is weak without transport level security. HTTP authentication per se is independent of the transport. For more details you can look at Joe Orton's talk at ApacheCon'2008: http://www.apachecon.com/eu2008/program/materials/kerb-sso-http.pdf -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Understanding role of the certificate in client - server communication.
Thank you for the answer. Sory if i lack the knowledge, but why SSL is needed when using kerberos? Kerberos is based on 3th party that is trusted, why there is a need for public key encryption? On Mar 19, 2014 12:24 AM, Rob Crittenden rcrit...@redhat.com wrote: Genadi Postrilko wrote: Hello all. I'm trying to understand the use of the certificates in the communication between an IPA client and server. The documentation describes the retrieval of CA certificate while client setup: Retrieve the CA certificate for the IdM CA And retrieval of SSL server certificate: Enable certmonger, retrieve an SSL server certificate, and install the certificate in |/etc/pki/nssdb| https://access.redhat.com/site/documentation/en-US/Red_ Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ setting-up-clients.html#what-happens-clients From my understanding the authentication in IPA environment is kerberos based, therefore the client and server share a secret that allows the user to authenticate himself to the server and vice versa. Where comes the need for certificate? Some of the IPA server services are not kerberized? Kerberos over HTTP requires SSL which is why the CA is retrieved and installed. We don't currently use the machine certificate. This was for future-proofing. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Understanding role of the certificate in client - server communication.
Hello all. I'm trying to understand the use of the certificates in the communication between an IPA client and server. The documentation describes the retrieval of CA certificate while client setup: Retrieve the CA certificate for the IdM CA And retrieval of SSL server certificate: Enable certmonger, retrieve an SSL server certificate, and install the certificate in /etc/pki/nssdb https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/setting-up-clients.html#what-happens-clients From my understanding the authentication in IPA environment is kerberos based, therefore the client and server share a secret that allows the user to authenticate himself to the server and vice versa. Where comes the need for certificate? Some of the IPA server services are not kerberized? Thanks in advance. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Issues creating trust with AD.
I would like to clarify myself, i wasn't accurate when i compared it to : https://bugzilla.redhat.com/show_bug.cgi?id=878564. I have tried to reproduce the bug by restarting the AD. *I was able to preform winbindd commands:* [root@ipaserver1 ~]# wbinfo -u ADEXAMPLE\administrator ADEXAMPLE\guest ADEXAMPLE\genadi ADEXAMPLE\krbtgt ADEXAMPLE\linux$ ADEXAMPLE\daniel [root@ipaserver1 ~]# wbinfo -g admins editors default smb group ad_users ADEXAMPLE\domain computers ADEXAMPLE\domain controllers ADEXAMPLE\schema admins ADEXAMPLE\enterprise admins ADEXAMPLE\domain admins ADEXAMPLE\domain users ADEXAMPLE\domain guests ADEXAMPLE\group policy creator owners ADEXAMPLE\read-only domain controllers ADEXAMPLE\enterprise read-only domain controllers ADEXAMPLE\dnsupdateproxy [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\administrator S-1-5-21-2887728911-2909484380-3974070232-500 SID_USER (1) [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\guest S-1-5-21-2887728911-2909484380-3974070232-501 SID_USER (1) [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\genadi S-1-5-21-2887728911-2909484380-3974070232-1000 SID_USER (1) [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\krbtgt S-1-5-21-2887728911-2909484380-3974070232-502 SID_USER (1) [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\linux$ S-1-5-21-2887728911-2909484380-3974070232-1104 SID_USER (1) [root@ipaserver1 ~]# wbinfo -n ADEXAMPLE\daniel S-1-5-21-2887728911-2909484380-3974070232-1105 SID_USER (1) *But kinit with AD users failed:* [root@ipaserver1 ~]# kinit gen...@adexample.com kinit: Cannot resolve servers for KDC in realm ADEXAMPLE.COM while getting initial credentials *But after few minutes i was able to to kinit with AD users agian:* [root@ipaserver1 ~]# kinit gen...@adexample.com Password for gen...@adexample.com: I think i was too fast on making conclusions. Not sure if opening a bug is needed. 2014-02-21 17:38 GMT+02:00 Simo Sorce s...@redhat.com: On Fri, 2014-02-21 at 00:27 +0200, Genadi Postrilko wrote: Update: For some reason the AD server has rebooted himself. After the reboot i couldn't preform kinit with AD users. I found a bugzilla that describes the symptoms that i experienced : https://bugzilla.redhat.com/show_bug.cgi?id=878564 Not sure if it is the same bug - the bugzilla reports bug in samba4-4.0.0-48.el6.rc4.x86_64 while my version is samba4-4.0.0-58.el6.rc4.x86_64 (after downgrade). I have rebooted the IPA server to see if it changes anything. After the reboot i was able to kinit with AD users, but not only that - now i am able to login with AD users to client machines. Any idea on what just happened? Sounds like a bug in windbindd which we currently use to talk to the Windows DCs for this functionality. Apparently winbindd failed to detect the DC came back online. A restart of the ipa server caused winbindd to restart and retry to get online. Can you please open a bug to track this issue ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Issues creating trust with AD.
Update: For some reason the AD server has rebooted himself. After the reboot i couldn't preform kinit with AD users. I found a bugzilla that describes the symptoms that i experienced : https://bugzilla.redhat.com/show_bug.cgi?id=878564 Not sure if it is the same bug - the bugzilla reports bug in samba4-4.0.0-48.el6.rc4.x86_64 while my version is samba4-4.0.0-58.el6.rc4.x86_64 (after downgrade). I have rebooted the IPA server to see if it changes anything. After the reboot i was able to kinit with AD users, but not only that - now i am able to login with AD users to client machines. Any idea on what just happened? Thanks. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Issues creating trust with AD.
Thank you for the help!
I have preformed downgrade:
yum downgrade samba4*
[root@ipaserver1 ~]# rpm -qa | grep samb
samba4-python-4.0.0-58.el6.rc4.x86_64
samba4-winbind-4.0.0-58.el6.rc4.x86_64
samba4-common-4.0.0-58.el6.rc4.x86_64
samba4-winbind-clients-4.0.0-58.el6.rc4.x86_64
samba4-libs-4.0.0-58.el6.rc4.x86_64
samba4-client-4.0.0-58.el6.rc4.x86_64
samba4-4.0.0-58.el6.rc4.x86_64
And it worked !
*I am now able to perform login via ssh and su on to the ipaserver with
AD users:*
[root@ipaserver1 ~]# su gen...@adexample.com
sh-4.1$
*and wbinfo and getent return values:*
[root@ipaserver1 ~]# wbinfo -u
ADEXAMPLE\administrator
ADEXAMPLE\guest
ADEXAMPLE\genadi
ADEXAMPLE\krbtgt
ADEXAMPLE\linux$
ADEXAMPLE\daniel
[root@ipaserver1 ~]# wbinfo -g
admins
editors
default smb group
ad_users
ADEXAMPLE\domain computers
ADEXAMPLE\domain controllers
ADEXAMPLE\schema admins
ADEXAMPLE\enterprise admins
ADEXAMPLE\domain admins
ADEXAMPLE\domain users
ADEXAMPLE\domain guests
ADEXAMPLE\group policy creator owners
ADEXAMPLE\read-only domain controllers
ADEXAMPLE\enterprise read-only domain controllers
ADEXAMPLE\dnsupdateproxy
[root@ipaserver1 ~]# getent passwd gen...@adexample.com
gen...@adexample.com:*:699001000:699001000::/home/adexample.com/genadi:
*After this success, i have tried to execute a login on client machine
(using AD user), but it did not work:*
[root@ipaclient1 ~]# su gen...@adexample.com
su: user gen...@adexample.com does not exist
*Also wbinfo and getent do not return value:*
[root@ipaclient1 ~]# wbinfo -u
[root@ipaclient1 ~]# wbinfo -g
[root@ipaclient1 ~]# getent passwd gen...@adexample.com
*Therefore i have preformed downgrade:*
yum downgrade samba4*
[root@ipaclient1 ~]# rpm -qa | grep samb
samba-winbind-clients-3.6.9-167.el6_5.x86_64
samba-common-3.6.9-167.el6_5.x86_64
samba-winbind-3.6.9-167.el6_5.x86_64
samba4-libs-4.0.0-58.el6.rc4.x86_64
*After the downgrade the login attempt still failed:*
[root@ipaclient1 ~]# su gen...@adexample.com
su: user gen...@adexample.com does not exist
*I wonder if the fact that ipa-windbind-client is 3.6.9, is the cause.*
*Also here are the client configuration file:*
*sssd*
[root@ipaclient1 ~]# cat /etc/sssd/sssd.conf
[domain/linux.adexample.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linux.adexample.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipaclient1.linux.adexample.com
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = _srv_, ipaserver1.linux.adexample.com
ldap_tls_cacert = /etc/ipa/ca.crt
subdomains_provider = ipa
[sssd]
services = nss, pam, ssh, pac
config_file_version = 2
domains = linux.adexample.com
[nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
*krb5*
[root@ipaclient1 ~]# cat /etc/krb5.conf
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = LINUX.ADEXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
LINUX.ADEXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@
ADEXAMPLE.COM/@adexample.com/
auth_to_local = DEFAULT
}
[domain_realm]
.linux.adexample.com = LINUX.ADEXAMPLE.COM
linux.adexample.com = LINUX.ADEXAMPLE.COM
*And again - Thanks you. I was stuck on it for log time.*
2014-02-17 10:34 GMT+02:00 Sumit Bose sb...@redhat.com:
On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote:
I have seen threads where opened on trust issues:
AD - Freeipa trust confusion
Cross domain trust
Cannot loging via SSH with AD user TO IPA Domain - which I opened.
It looks like after creation of trust, TGT ticket can be issued from AD,
but su and ssh do not allow a log in with AD user.
I'm not sure if a conclusion has been reached on this subject.
I gave it a try again and attempted to create a trust with IPA as a DNS
subdomain of AD.
I followed :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html
AD domain: ADEXAMPLE.COM
IPA subdoamin: LINUX.ADEXAMPLE.COM
When i finished the necessary steps i attempted to retrieve a TGT from AD
(while logged in to IPA server):
[root@ipaserver1 sbin]# kinit administra...@adexample.com
Password for administra...@adexample.com:
[root@ipaserver1 sbin]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administra...@adexample.com
Valid starting ExpiresService principal
02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/adexample@adexample.com
renew until 02/15/14 07:50:21
But logging in by ssh and su ended in failure:
login as: administra...@adexample.com
administra...@addc.com@192.168.227.201's password:
Access denied
After reading
http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini
did the following
[Freeipa-users] Issues creating trust with AD.
I have seen threads where opened on trust issues: AD - Freeipa trust confusion Cross domain trust Cannot loging via SSH with AD user TO IPA Domain - which I opened. It looks like after creation of trust, TGT ticket can be issued from AD, but su and ssh do not allow a log in with AD user. I'm not sure if a conclusion has been reached on this subject. I gave it a try again and attempted to create a trust with IPA as a DNS subdomain of AD. I followed : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html AD domain: ADEXAMPLE.COM IPA subdoamin: LINUX.ADEXAMPLE.COM When i finished the necessary steps i attempted to retrieve a TGT from AD (while logged in to IPA server): [root@ipaserver1 sbin]# kinit administra...@adexample.com Password for administra...@adexample.com: [root@ipaserver1 sbin]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administra...@adexample.com Valid starting ExpiresService principal 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/adexample@adexample.com renew until 02/15/14 07:50:21 But logging in by ssh and su ended in failure: login as: administra...@adexample.com administra...@addc.com@192.168.227.201's password: Access denied After reading http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini did the following on the AD server: Administrative Tools - Active Directory Domains and Trust - adexample.com(right click) - Properties - Trust - Domain Trusted by this domain (outgoing trust) - Properties - General - Validate *After doing this i was able to login via ssh and su with Administrator **user :* login as: administra...@adexample.com administra...@adexample.com@192.168.227.201's password: Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 Could not chdir to home directory /home/adexample.com/administrator: No such file or directory /usr/bin/xauth: error in locking authority file /home/ adexample.com/administrator/.Xauthority -sh-4.1$ *But still not able to login with other AD accounts:* [root@ipaserver1 sbin]# su gen...@adexample.com su: user gen...@adexample.com does not exist After reading the other threads, ill try and provide as much information as i can: *wbinfo -u does not return values.* [root@ipaserver1 sbin]# wbinfo -u [root@ipaserver1 sbin]# *wbinfo -u output:* [root@ipaserver1 sbin]# wbinfo -g admins editors default smb group ad_users *wbinfo --online-status shows ADEXAMPLE is offline* [root@ipaserver1 ~]# wbinfo --online-status BUILTIN : online LINUX : online ADEXAMPLE : offline *getent for Administrator does return value.* [root@ipaserver1 sbin]# getent passwd administra...@adexample.com administra...@adexample.com:*:699000500:699000500::/home/ adexample.com/administrator: *getent for other AD users does not return value.* [root@ipaserver1 sbin]# getent passwd gen...@adexample.com [root@ipaserver1 sbin]# *System info/configurations:* [root@ipaserver1 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) [root@ipaserver1 sbin]# rpm -qa | grep ipa ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 libipa_hbac-python-1.9.2-129.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-trust-ad-3.0.0-37.el6.x86_64 libipa_hbac-1.9.2-129.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-37.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [root@ipaserver1 ~]# rpm -qa | grep sssd sssd-1.9.2-129.el6.x86_64 sssd-client-1.9.2-129.el6.x86_64 [root@ipaserver1 sbin]# rpm -qa | grep samb samba4-common-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 samba4-libs-4.0.0-60.el6_5.rc4.x86_64 samba4-python-4.0.0-60.el6_5.rc4.x86_64 samba4-4.0.0-60.el6_5.rc4.x86_64 samba4-client-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 *SSSD* [root@ipaserver1 ~]# cat /etc/sssd/sssd.conf [domain/linux.adexample.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.adexample.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaserver1.linux.adexample.com chpass_provider = ipa ipa_server = ipaserver1.linux.adexample.com ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa debug_level = 6 [sssd] services = nss, pam, ssh, pac config_file_version = 2 domains = linux.adexample.com debug_level = 6 [nss] debug_level = 6 [pam] debug_level = 6 [sudo] debug_level = 6 [autofs] debug_level = 6 [ssh] debug_level = 6 [pac] debug_level = 6 *KRB5* [root@ipaserver1 ~]# cat /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = LINUX.ADEXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h
Re: [Freeipa-users] Choosing the right way to create trust
What about adding alias DNS record of hostname.ipa.zone.corp to all linux machines, so they will keep the old FQDM. On Feb 12, 2014 10:49 AM, Martin Kosek mko...@redhat.com wrote: On 02/11/2014 07:29 PM, Genadi Postrilko wrote: I work in environment where the AD is the DC of the windows machines , while the linux machines (RHEL 5\6) are not centrally managed. I would like to create an IPA server to manage the linux machines while creating a trust with AD. The current situation is all windows and linux machines are under .zone.corp domain. From what ive read at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html , i can create trust when IPA is a subdomain of AD domain or when the domains are separate. I'm not sure what is the method i should approach. Can IPA be a dc inside the AD domain? Or should i create a subdomain for linux and then move all the linux machines to the new domain (I hope not). Any advice? The key here is that for IPA and AD to be able to work together in a trust, they need to be in separate domains with realm matching this domains. In your case, it seems to me that a following scenario would work the best: * AD with domain zone.corp and realm ZONE.CORP * IPA with domain ipa.zone.corp and realm IPA.ZONE.CORP Ideally, IPA should have DNS installed and have the ipa.zone.corp delegated from the AD DNS (or other DNS you use). More info here: http://www.freeipa.org/page/Trusts Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Choosing the right way to create trust
Client's local hostname must match the DNS A record? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Choosing the right way to create trust
I work in environment where the AD is the DC of the windows machines , while the linux machines (RHEL 5\6) are not centrally managed. I would like to create an IPA server to manage the linux machines while creating a trust with AD. The current situation is all windows and linux machines are under .zone.corp domain. From what ive read at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide.html, i can create trust when IPA is a subdomain of AD domain or when the domains are separate. I'm not sure what is the method i should approach. Can IPA be a dc inside the AD domain? Or should i create a subdomain for linux and then move all the linux machines to the new domain (I hope not). Any advice? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
sssd_example.com.log after changing the debug level: https://gist.github.com/anonymous/8290381#file-sssd_example-com-log [genadi@ipaserver root]$ wbinfo -u (no output) [genadi@ipaserver root]$ wbinfo -g admins editors default smb group ad_users ad_admins [genadi@ipaserver root]$ wbinfo --trusted-domains BUILTIN EXAMPLE ADDC [genadi@ipaserver root]$ wbinfo -i Administrator failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user Administrator [genadi@ipaserver root]$ wbinfo --domain-info ADDC.COM Name : ADDC Alt_Name : addc.com SID : S-1-5-21-33789592-1708006097-2663368750 Active Directory : No Native: No Primary : No 2014/1/6 Jakub Hrozek jhro...@redhat.com On Fri, Jan 03, 2014 at 07:29:54PM +0200, Genadi Postrilko wrote: Here are the other logs as well (ldap_child.log, sssd_pac.log, sssd_ssh.log). https://gist.github.com/anonymous/8242061 I attempted to log in (as administra...@addc.com) at 9:04. Thanks for the help. You need the *domain* log. According to the logs, your domain is called example.com, do you need to put debug_level=6 (or higher, but 6 should be enough) to the section called [domain/example.com] in sssd.conf, restart sssd, attempt the login and then attach /var/log/sssd/sssd_example.com.log Given that SSSD is complaining about not being able to find the user, I suspect a similar problem as in the other thread, that is, Winbind on the server not being able to talk to the AD. Does wbinfo -u $user work on the server? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
What is content of the log when SSSD is doing auth? When i log in with IPA domain client, the output of the log is (anything non standard?): Jan 5 12:08:37 ipaserver sshd[24434]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 user= r...@example.com Jan 5 12:08:37 ipaserver sshd[24434]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 user= r...@example.com Jan 5 12:08:37 ipaserver sshd[24434]: Accepted password for ron@EXAMPLE.COMfrom 192.168.227.1 port 57144 ssh2 Jan 5 12:08:37 ipaserver sshd[24434]: pam_unix(sshd:session): session opened for user r...@example.com by (uid=0) Here is the /etc/pam.d/system-auth file : https://gist.github.com/anonymous/8273507 it does contains pam_sss.so module. When i created the the environment, first i installed the IPA server, then joined the IPA clients and finally created the trust. 2014/1/5 Dmitri Pal d...@redhat.com On 01/04/2014 06:13 PM, Genadi Postrilko wrote: Output from /var/log/secure: Jan 4 15:03:02 ipaserver sshd[5958]: Invalid user Administrator@ADDC.COMfrom 192.168.227.1 Jan 4 15:03:02 ipaserver sshd[5959]: input_userauth_request: invalid user administra...@addc.com Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): check pass; user unknown Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 Jan 4 15:03:06 ipaserver sshd[5958]: pam_succeed_if(sshd:auth): error retrieving information about user administra...@addc.com Jan 4 15:03:08 ipaserver sshd[5958]: Failed password for invalid user administra...@addc.com from 192.168.227.1 port 53125 ssh2 I do not see SSSD doing auth. Is pam_sss configured for PAM for SSH? See more details here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#installing-host-keys http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf I do not see simple HowTo to configure SSH to use SSSD for cases when ipa-client-install is not used. May be we should provide one. The expectation is: You install IPA, create trust, join client to IPA using ipa-client-install and it configures everything you need. The order of last two steps can be reversed but the result should be the same. 2014/1/3 Genadi Postrilko genadip...@gmail.com Here are the other logs as well (ldap_child.log, sssd_pac.log, sssd_ssh.log). https://gist.github.com/anonymous/8242061 I attempted to log in (as administra...@addc.com) at 9:04. Thanks for the help. ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
Output from /var/log/secure: Jan 4 15:03:02 ipaserver sshd[5958]: Invalid user Administrator@ADDC.COMfrom 192.168.227.1 Jan 4 15:03:02 ipaserver sshd[5959]: input_userauth_request: invalid user administra...@addc.com Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): check pass; user unknown Jan 4 15:03:06 ipaserver sshd[5958]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.1 Jan 4 15:03:06 ipaserver sshd[5958]: pam_succeed_if(sshd:auth): error retrieving information about user administra...@addc.com Jan 4 15:03:08 ipaserver sshd[5958]: Failed password for invalid user administra...@addc.com from 192.168.227.1 port 53125 ssh2 2014/1/3 Genadi Postrilko genadip...@gmail.com Here are the other logs as well (ldap_child.log, sssd_pac.log, sssd_ssh.log). https://gist.github.com/anonymous/8242061 I attempted to log in (as administra...@addc.com) at 9:04. Thanks for the help. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
Here are the other logs as well (ldap_child.log, sssd_pac.log, sssd_ssh.log). https://gist.github.com/anonymous/8242061 I attempted to log in (as administra...@addc.com) at 9:04. Thanks for the help. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
Hi all. I have a running IPA Server (3.0.0-37) on RHEL 6.2. I'm trying to create Trust between IPA server and AD (In different DNS domains). I followed the red hat guide https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf . When i completed the needed step to create the trust and retrieved a krb ticket from the AD server: [root@ipaserver ~]# kinit administra...@addc.com Password for administra...@addc.com: [root@ipaserver ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administra...@addc.com Valid starting ExpiresService principal 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/addc@addc.com renew until 01/03/14 12:20:30 But when i try to connect to the IPA server via SHH (Putty) i get Access denied message: login as: administra...@addc.com administra...@addc.com@192.168.227.128's password: Access denied Any ideas on what i could have done wrong in the process of creating the trust? Thank you in advance. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
Its a newly installed IPA Server, haven't added any Rules. The relevant output from /var/log/secure : Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user Administrator@ADDC.COMfrom 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid user administra...@addc.com Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; user unknown Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.100 Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error retrieving information about user administra...@addc.com Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user administra...@addc.com from 192.168.227.100 port 62484 ssh2 2014/1/2 Rob Crittenden rcrit...@redhat.com Genadi Postrilko wrote: Hi all. I have a running IPA Server (3.0.0-37) on RHEL 6.2. I'm trying to create Trust between IPA server and AD (In different DNS domains). I followed the red hat guide https://access.redhat.com/site/documentation/en-US/Red_ Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_ Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf. When i completed the needed step to create the trust and retrieved a krb ticket from the AD server: [root@ipaserver ~]# kinit administra...@addc.com mailto:administra...@addc.com Password for administra...@addc.com mailto:administra...@addc.com: [root@ipaserver ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administra...@addc.com mailto:administra...@addc.com Valid starting ExpiresService principal 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/addc@addc.com mailto:addc@addc.com renew until 01/03/14 12:20:30 But when i try to connect to the IPA server via SHH (Putty) i get Access denied message: login as: administra...@addc.com mailto:administra...@addc.com administra...@addc.com@192.168.227.128 http://192.168.227.128's password: Access denied Any ideas on what i could have done wrong in the process of creating the trust? I'd check the sssd logs and /var/log/secure. Do you have any HBAC rules? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cannot loging via SSH with AD user TO IPA Domain.
Here are the *sssd.log, **sssd_nss.log. *Other logs where empty of did not contain the output for the relevant log in. https://gist.github.com/anonymous/8228284 2014/1/2 Dmitri Pal d...@redhat.com On 01/02/2014 04:45 PM, Genadi Postrilko wrote: Its a newly installed IPA Server, haven't added any Rules. The relevant output from /var/log/secure : Jan 2 13:36:24 ipaserver sshd[4864]: Invalid user from 192.168.227.100 Jan 2 13:36:24 ipaserver sshd[4865]: input_userauth_request: invalid user Jan 2 13:36:26 ipaserver sshd[4865]: Connection closed by 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4868]: Invalid user Administrator@ADDC.COMfrom 192.168.227.100 Jan 2 13:36:35 ipaserver sshd[4869]: input_userauth_request: invalid user administra...@addc.com Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): check pass; user unknown Jan 2 13:36:44 ipaserver sshd[4868]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.227.100 Jan 2 13:36:44 ipaserver sshd[4868]: pam_succeed_if(sshd:auth): error retrieving information about user administra...@addc.com Jan 2 13:36:46 ipaserver sshd[4868]: Failed password for invalid user administra...@addc.com from 192.168.227.100 port 62484 ssh2 2014/1/2 Rob Crittenden rcrit...@redhat.com Genadi Postrilko wrote: Hi all. I have a running IPA Server (3.0.0-37) on RHEL 6.2. I'm trying to create Trust between IPA server and AD (In different DNS domains). I followed the red hat guide https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/pdf/Identity_Management_Guide/Red_Hat_Enterprise_Linux-6-Identity_Management_Guide-en-US.pdf . When i completed the needed step to create the trust and retrieved a krb ticket from the AD server: [root@ipaserver ~]# kinit administra...@addc.com mailto:administra...@addc.com Password for administra...@addc.com mailto:administra...@addc.com: [root@ipaserver ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administra...@addc.com mailto: administra...@addc.com Valid starting ExpiresService principal 01/02/14 12:20:30 01/02/14 22:20:34 krbtgt/addc@addc.com mailto:addc@addc.com renew until 01/03/14 12:20:30 But when i try to connect to the IPA server via SHH (Putty) i get Access denied message: login as: administra...@addc.com mailto:administra...@addc.com administra...@addc.com@192.168.227.128 http://192.168.227.128's password: Access denied Any ideas on what i could have done wrong in the process of creating the trust? I'd check the sssd logs and /var/log/secure. Do you have any HBAC rules? rob ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Looks an error similar to what I see in the other thread. Unfortunately be might need to wait till Monday for Alexander, Sumit and Jakub to come back and provide help. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
