October 2017 - FreeIPA-users - Fedora mailing-lists

Re: several IPA CA certificate entries
by John Dennis 27 Oct '17

27 Oct '17

On 10/12/2017 05:06 PM, Bhavin Vaidya wrote: > Hello Jon, > > > thank you for your help. responded to main thread, and just sending you > the actual output for certutil. > > > [root@ds01 log]# certutil -d /etc/pki/nssdb -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ARTERIS.COM IPA CA CT,C,C > ARTERIS.COM IPA CA CT,C,C > ARTERIS.COM IPA CA CT,C,C > ARTERIS.COM IPA CA CT,C,C These nicknames do not look unique to me, I'm assuming you're still editing them for inclusion in this email. But irregardless here is where I'm going with this. Your goal is to identify the correct cert to use and which to discard. The only way you can do that is to examine each individual cert. To examine an individual cert you must have it's *unique* nickname to pass to "certutil -L -a -n xxx" where xxx is the unique nickname. Only you can identify the correct cert once you list them. At the absolute minimum they should each have a unique (issuer,serial_number) pair. The one you want to use will probably select based on the issuer and validity dates. > > ------------------------------------------------------------------------ > *From:* John Dennis <jdennis(a)redhat.com> > *Sent:* Thursday, October 12, 2017 6:10 AM > *To:* FreeIPA users list > *Cc:* Bhavin Vaidya; Rob Crittenden > *Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries > On 10/12/2017 03:29 AM, Rob Crittenden via FreeIPA-users wrote: >> Bhavin Vaidya via FreeIPA-users wrote: >>> Hello, >>> >>> >>> I'm having various problem on our FreeIPA setup, like can not establish >>> new replica server or add a client anymore. Initially we had certificate >>> issue, then we upgraded the Master FreeIPA server (CentOS 7.0.146) to >>> FreeIPA v4.4.0) few months back. >>> >>> >>> On master server it shows up 4 entries for IPA CA certificate. Is this >>> normal? >>> >>> >>> [root@ds01 ~]# certutil -d /etc/pki/nssdb -L >>> >>> Certificate Nickname Trust >>> Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> >>> EXAMPLE.COM IPA CA CT,C,C >>> EXAMPLE.COM IPA CA CT,C,C >>> EXAMPLE.COM IPA CA CT,C,C >>> EXAMPLE.COM IPA CA CT,C,C >> >> The question is: are these all different certificates (and why)? I >> assume someone ran ipa-cacert-manage renew a bunch of times. >> >> Multiple entries in itself shouldn't be a problem. >> >> I assume this is related to your client install issues. You may be able >> to get away with having just the latest CA cert stored in LDAP to avoid >> this. > > I saw this last night and my first thought was this shouldn't happen > because certutil enforces nickname uniqueness. > > We would like to verify what each cert is, specifically it's issuer and > serial number. But we can't ask certutil to show us the details of a > cert because you must pass the -n nickname flag to certutil so it can > find the cert to display. But since the nicknames are not unique you > can't do that. This is why certutil (and any low level NSS API that adds > a cert to the db) demands name uniqueness. > > Are the names listed with -L truly unique? It looks like you edited them. > > > -- > John -- John

6 14

yum update caused FreeIPA to temporarily return NXDOMAIN for valid records
by Nicholas Hinds 27 Oct '17

27 Oct '17

During an upgrade from 4.5.0-21.el7.centos.1.2 to 4.5.0-21.el7.centos.2.2 on a CentOS 7.4 machine, FreeIPA's DNS server briefly returned NXDOMAIN for records which existed in FreeIPA. These invalid responses were returned for a very short amount of time, but caused long-running issues with Java clients which tend to cache DNS responses. Upgraded packages included: 389-ds-base, 389-ds-base-libs, 389-ds-base-snmp, ipa-client, ipa-client-common, ipa-python-compat, ipa-server, ipa-server-common, ipa-server-dns, ipa-server-trust-ad, python2-ipa-server, and a dozen sss-related packages. I reproduced this in a FreeIPA test environment by running `while true; do dig some.dns.entry.managed.by.freeipa @ip.address.of.freeipa | tee -a a-log-file; done` from one server, and running `yum update` on the FreeIPA machine. The invalid NXDOMAIN responses were returned some time after the `yum update` logged 'Cleanup' for the RPMs, and seemed to be during the 'Verifying' phase. These NXDOMAIN responses claimed that an upstream nameserver ( a.root-servers.net) was the authority for my zone: a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> some.dns.entry.managed.by.freeipa @172.16.0.77 a-log-file-;; global options: +cmd a-log-file-;; Got answer: a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889 a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 a-log-file- a-log-file-;; QUESTION SECTION: a-log-file-;some.dns.entry.managed.by.freeipa. IN A a-log-file- a-log-file-;; AUTHORITY SECTION: a-log-file-. 60 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017102400 1800 900 604800 86400 a-log-file- a-log-file-;; Query time: 227 msec a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77) a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017 a-log-file-;; MSG SIZE rcvd: 130 Usually when querying an invalid DNS entry, the dig output still claims that my FreeIPA server is authoritative for the zone: $ dig doesntexist.zone.managed.by.freeipa @172.16.0.77 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> doesntexist.zone.managed.by.freeipa @172.16.0.77 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;doesntexist.zone.managed.by.freeipa. IN A ;; AUTHORITY SECTION: zone.managed.by.freeipa. 30 IN SOA idm01.freeipa. hostmaster.zone.managed.by.freeipa. 1508869828 30 900 1209600 30 ;; Query time: 0 msec ;; SERVER: 172.16.0.77#53(172.16.0.77) ;; WHEN: Tue Oct 24 19:27:12 2017 ;; MSG SIZE rcvd: 113 Is it possible that during a yum update, the FreeIPA DNS server temporarily forgets what zones it's authoritative for (or forgets all DNS records) and just delegates to the upstream DNS server for half a second or so? Or is something else going on here? I'm open to suggestions. Thanks, Nicholas.

2 6

Replica stopped working: pki-ca port failed?
by Lachlan Musicman 26 Oct '17

26 Oct '17

When I first installed our replica, it worked just fine - I could add a user and see it on the master server. And vice versa. I recently went back to take a look and make sure everything was working - and it's not. ipactl status shows everything is ok. Munge is up. I can ssh hostname between machines. When I look at the ID Views in the interface, I get an "IPA Error 903: InternalError". When I do an id <username> I get nosuch user. I did some googling. In /var log/dirsrv/domain/errors I found this: [26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ vmdr-linuxidm.unix.domain.com(a)UNIX.DOMAIN.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) I can get `kinit admin` working fine. But there's something wrong. I don't know where to look exactly. /var/log/httpd/error has this RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty Which is interesting. There's no file /usr/share/ipa/smb.conf.empty but there is a /usr/share/ipa/smb.conf.template? Ok, I think I've found the problem: ipa-replica-conncheck -c -m <master> Failed to connect to port 7389 tcp on 10.126.18.73 PKI-CA: Directory Service port (7389): FAILED ERROR: Port check failed! Inaccessible port(s): 7389 (TCP) On the master, pki-tomcatd is showing as OK, although nmap -sT -O localhost doesn't show 7389 open. Where can I look next? ipa -version VERSION: 4.5.0, API_VERSION: 2.228 cheers L. ------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. " *Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857

2 4

Re: Port 389
by Sean Hogan 26 Oct '17

26 Oct '17

Ok.. no worries. Thanks Simo From: Simo Sorce via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Sean Hogan <schogan(a)us.ibm.com>, Simo Sorce <simo(a)redhat.com> Date: 10/26/2017 02:17 PM Subject: [Freeipa-users] Re: Port 389 On Thu, 2017-10-26 at 14:11 -0700, Sean Hogan via FreeIPA-users wrote: > Hello IPA, > > Hopefully a quick question. > > RHEL 7.3 IPA 4.4 > > I have been digging around RHEL docs > https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_solu… for firewall ports and it > says > 389 is required for replication of IPA servers and clients to IPA > servers. > > FreeIPA docs say this: > SSL/startTLS When possible, configure your LDAP client to > communicate over > SSL/TLS. You can either use port 389 and enable startTLS in the > client or > configure to use the ldaps port, 636. The IPA CA certificate can be > found > in /etc/ipa/ca.crt on all enrolled hosts. > > > > > > Question is this... can IPA be configured without Port 389 at all > for clients to comm with IPA servers? Nope, sorry. Most clients use SASL/GSSAPI to secure the connection, and that is done over port 389. > > I realize the starttls using 389 encrypts the comms but for our > vlan firewall rules 389 is not something we really want to open. It > is easier to open IPA server IP to IPA server IP port 389 bi- > direction if needed for replication but for clients it would be the > whole subnet to IPA server 389. > I also noticed somewhere that direct 636 instead of 389 with starttls > for clients is deprecated but I think that was in Directory Server > docs. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org

1 0

Port 389
by Sean Hogan 26 Oct '17

26 Oct '17

Hello IPA, Hopefully a quick question. RHEL 7.3 IPA 4.4 I have been digging around RHEL docs https://access.redhat.com/solutions/357673 for firewall ports and it says 389 is required for replication of IPA servers and clients to IPA servers. FreeIPA docs say this: SSL/startTLS When possible, configure your LDAP client to communicate over SSL/TLS. You can either use port 389 and enable startTLS in the client or configure to use the ldaps port, 636. The IPA CA certificate can be found in /etc/ipa/ca.crt on all enrolled hosts. Question is this... can IPA be configured without Port 389 at all for clients to comm with IPA servers? I realize the starttls using 389 encrypts the comms but for our vlan firewall rules 389 is not something we really want to open. It is easier to open IPA server IP to IPA server IP port 389 bi-direction if needed for replication but for clients it would be the whole subnet to IPA server 389. I also noticed somewhere that direct 636 instead of 389 with starttls for clients is deprecated but I think that was in Directory Server docs. Sean Hogan

2 1

Re: Sync against AD group
by Rob Crittenden 26 Oct '17

26 Oct '17

Miguel Angel Coa M. wrote: > Rob, > My idea about A/D group is centralize the users for the winsync because > some are in one OU and others in others (but i see this isn't possible) > > eg. > > Example2.com <-- Domain root > Builtin <-- Default > ..... > ..... > Users <-- Default users -> base search (CN=users,DC=example2, DC=com) > ..... > Area01 <-- Custom OU and i've some user for sync --> base search > (OU=area01,DC=example2, DC=com) > Area02 <-- Custom OU and i've others user for sync --> base search > (OU=area02,DC=example2, DC=com) > Area03 <-- Custom OU and i've others user for sync --> base > search (OU=area03,DC=example2, DC=com) > ...... > AreaXX <-- Custom OU and i've others user for sync --> base > search (OU=areaXX,DC=example2, DC=com) > > > ¿In my case what could I do? Right, moving all the users to a custom OU or otherwise separate subtree would be the only way to do it AFAIK. rob > > > Thanks. > > > Saludos. > --- > Miguel Coa M. > > 2017-10-25 18:42 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>>: > > Miguel Angel Coa M. wrote: > > Hi Rob, > > CN=LAB is a group entry and inside i've a few members > > > > [.................] > > # LAB, Users, example2.com <http://example2.com> <http://example2.com> > > dn: CN=LAB,CN=Users,DC=example2,DC=com > > objectClass: top > > objectClass: group > > cn: LAB > > description: Usuario de grupo LAB > > member: CN=winuser64,CN=Users,DC=example2,DC=com > > member: CN=winuserlab2 userlab2,OU=Test,DC=example2,DC=com > > member: CN=winuser40 winuser40,OU=Test,DC=example2,DC=com > > member: CN=winuserlab1 userlab1,OU=Test,DC=example2,DC=com > > distinguishedName: CN=LAB,CN=Users,DC=example2,DC=com > > instanceType: 4 > > whenCreated: 20171023203927.0Z > > whenChanged: 20171024203108.0Z > > uSNCreated: 49193 > > uSNChanged: 61493 > > name: LAB > > objectGUID:: gQBcEwVqHU+L3DmmZPVFFw== > > objectSid:: AQUAAAAAAAUVAAAAguTkYzspTdFQ0vfEWwQAAA== > > sAMAccountName: LAB > > sAMAccountType: 268435456 > > groupType: -2147483640 > > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example2,DC=com > > dSCorePropagationData: 16010101000000.0Z > > That's why. winsync syncs against a subtree, not members of a group. > > rob > > > [.................] > > > > > > Regards. > > > > > > > > > > Saludos. > > --- > > Miguel Coa M. > > > > 2017-10-25 17:28 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com <mailto:rcritten@redhat.com> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>: > > > > Miguel Angel Coa M. via FreeIPA-users wrote: > > > Hello Everyone, > > > I've setting IPA server connect with AD (Windows Server > 2012R2) and work > > > fine, but i need change the sub-tree for user sync and this > step fail > > > (not sync anything) . > > > For example, when i sync against the default base is ok > > > > > > [.................] > > > CN=Users,DC=example2,dc=com > > > [.................] > > > > > > [.................] > > > nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com > > > [.................] > > > > > > > > > But i try change the base and does not sync anything > > > > > > [.................] > > > CN=LAB,CN=Users,DC=example2,dc=com > > > [.................] > > > > > > When the LAB is AD group. ¿is possible sync against AD group? > > > > IIRC winsync looks for entries that match objectclass=ntuser. > I CN=LAB > > literally a group entry or a subtree? > > > > rob > > > > > >

1 0

Re: Sync against AD group
by Rob Crittenden 25 Oct '17

25 Oct '17

Miguel Angel Coa M. wrote: > Hi Rob, > CN=LAB is a group entry and inside i've a few members > > [.................] > # LAB, Users, example2.com <http://example2.com> > dn: CN=LAB,CN=Users,DC=example2,DC=com > objectClass: top > objectClass: group > cn: LAB > description: Usuario de grupo LAB > member: CN=winuser64,CN=Users,DC=example2,DC=com > member: CN=winuserlab2 userlab2,OU=Test,DC=example2,DC=com > member: CN=winuser40 winuser40,OU=Test,DC=example2,DC=com > member: CN=winuserlab1 userlab1,OU=Test,DC=example2,DC=com > distinguishedName: CN=LAB,CN=Users,DC=example2,DC=com > instanceType: 4 > whenCreated: 20171023203927.0Z > whenChanged: 20171024203108.0Z > uSNCreated: 49193 > uSNChanged: 61493 > name: LAB > objectGUID:: gQBcEwVqHU+L3DmmZPVFFw== > objectSid:: AQUAAAAAAAUVAAAAguTkYzspTdFQ0vfEWwQAAA== > sAMAccountName: LAB > sAMAccountType: 268435456 > groupType: -2147483640 > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example2,DC=com > dSCorePropagationData: 16010101000000.0Z That's why. winsync syncs against a subtree, not members of a group. rob > [.................] > > > Regards. > > > > > Saludos. > --- > Miguel Coa M. > > 2017-10-25 17:28 GMT-03:00 Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>>: > > Miguel Angel Coa M. via FreeIPA-users wrote: > > Hello Everyone, > > I've setting IPA server connect with AD (Windows Server 2012R2) and work > > fine, but i need change the sub-tree for user sync and this step fail > > (not sync anything) . > > For example, when i sync against the default base is ok > > > > [.................] > > CN=Users,DC=example2,dc=com > > [.................] > > > > [.................] > > nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com > > [.................] > > > > > > But i try change the base and does not sync anything > > > > [.................] > > CN=LAB,CN=Users,DC=example2,dc=com > > [.................] > > > > When the LAB is AD group. ¿is possible sync against AD group? > > IIRC winsync looks for entries that match objectclass=ntuser. I CN=LAB > literally a group entry or a subtree? > > rob > >

1 0

Sync against AD group
by Miguel Angel Coa M. 25 Oct '17

25 Oct '17

Hello Everyone, I've setting IPA server connect with AD (Windows Server 2012R2) and work fine, but i need change the sub-tree for user sync and this step fail (not sync anything) . For example, when i sync against the default base is ok [.................] CN=Users,DC=example2,dc=com [.................] [.................] nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com [.................] But i try change the base and does not sync anything [.................] CN=LAB,CN=Users,DC=example2,dc=com [.................] When the LAB is AD group. ¿is possible sync against AD group? Saludos. --- Miguel Coa M.

2 1

FreeIPA+Ubuntu-16.04+Samba, is there a solution
by Kees Bakker 25 Oct '17

25 Oct '17

Hey, As described by Alexander in [1], Samba on Ubuntu 16.04 is built against Heimdal, and that conflicts with FreeIPA (which requires MIT Kerberos). We have a network with Ubuntu 16.04 servers, and Ubuntu 16.04 workstations, and some Windows PCs. So far I was unable to configure the samba server to use the IPA server for authentication (again, see [1]). So, what are my options Ubuntu 16.04 / Samba / FreeIPA / Windows PCs? I was thinking to setup a Fedora or Centos server (with samba), but I have no clue if that path will lead to a working solution. Another alternative, maybe, is to use LDAP, but I'm afraid to screw my nicely working IPA server. There is this guide [2], but I've already done ipa-adtrust-install and I think there is now already some LDAP scheme added for samba. (Not sure though) Any thoughts? [1] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1552249 [2] https://help.ubuntu.com/lts/serverguide/samba-ldap.html -- Kees Bakker

1 0

IPA cross-forest trust, retrieve additional ldap attributes for users
by Steve Dainard 24 Oct '17

24 Oct '17

Hello, I'm running a cross-forest trust with RHEL 7 IPA (60 day trial), when I do an ldapsearch on the AD user against the IPA server I get very few attributes. It seems like the sssd option 'ldap_user_extras_attrs' should fetch additional attributes but I can't seem to get any results. I'm also confused which section this option should be added to on IPA server sssd.conf. I've tried: [domain/ipadomain] ldap_user_extras_attrs = givenname, sn, displayname [domain/addomain] ldap_user_extras_attrs = givenname, sn, displayname [domain/ipadomain/addomain] ldap_user_extras_attrs = givenname, sn, displayname Of note, I didn't include the 'mail' attribute as a value above as I read a post that said IPA should pull this attribute automatically but I'm not seeing it either when doing an ldapsearch. Maybe this points to a bigger problem.. Here are the value's I'm receiving: # steve.dainard(a)addomain.com, users, compat, ipadomain.com dn: uid=steve.dainard(a)addomain.com,cn=users,cn=compat,dc=ipadomain,dc=com objectClass: posixAccount objectClass: top gecos: Steve Dainard cn: Steve Dainard uidNumber: 1587 gidNumber: 1028 loginShell: /bin/sh homeDirectory: /home/addomain.com/steve.dainard uid: steve.dainard(a)addomain.com The uidNumber/gidNumber are coming from AD, but the loginShell in AD is set to /bin/bash. I've also seen mention of using the [ifp] section to populate attributes for applications such as manageiq http://manageiq.org/docs/reference/euwe/auth/ipa_ad_trust but if I add that option my client hosts can't id users. I'm not entirely sure if the [ifp] entry should be server side, client side, or both. Thanks, Steve

2 3

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users October 2017