June 2018 - FreeIPA-users - Fedora mailing-lists

More on ldap_idmap_range
by Craig H Silva (Cenitex) 24 Jun '18

24 Jun '18

As it happens my paranoia seems to be on message. We have just deployed 4 new sles 12 systems, with the following config: id_provider = ad auth_provider = ad subdomains_provider = none access_provider = ad enumerate = false cache_credentials = true These systems were deployed without ldap_idmap_default_domain_sid or ldap_idmap_default_domain. And the range they have started using is different to the range that exists on other deployed systems. It appears that sssd has returned a different range from that which exists on our other systems. I would apreciate advice on how to configure a range that will be uniform from the start. Thanks for your help in advance. Craig Silva _________ Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM Cenitex | Level 15, 80 Collins Street, Melbourne 3000 ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/> This office is located on the land of the Traditional Owners of the Kulin Nation. [cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/> Accountability, Collaboration, Respect, Initiative and Courage ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.

1 0

ldap_idmap_default_domain_sid & ldap_idmap_range_size advice requested
by Craig H Silva (Cenitex) 24 Jun '18

24 Jun '18

As mentioned in a previous post, I work in an environment with a large AD tree with in excess of 30000 groups and multiple subdomains. We authenticate against the primary domain and are using ldap_id_mapping after having migrated from using posix attributes (the admin overhead was becoming prohibitive) Recently we were experimenting with using the ldap_idmap_default_domain_sid as a measure to ensure that the allocated uids and gids were protected against arbitrary change as new domains were encountered in the environment. We had not specified it previously and it did not have any deleterious effect until we attempted to purge a group that was affecting an update of the database (see previous message on Re: apparent error with ad_enum_cross_dom_members). sss_cache -E wouldn't purge this group so I deleted the databases and config in /var/lib/sss/db and restarted sssd with the effect that sssd started using a different range - not good. Unfortunately this only increased my paranoia. At this point I'm not sure as to how to proceed to ensure that the current range is maintained as inclusion of ldap_idmap_default_domain_sid will start the use of a new range. I also experimented with increasing the ldap_idmap_range_size from the default of 200000 to test whether the issue was due to encountering rids beyond the default range but this also triggered sssd to use a new range. Basically I'm getting into territory beyond the scope of my experience and seek advice on either biting the bullet and accepting a change in the range and specifying the default sid and dealing with the change on client systems, or getting advice on how to configure sssd to lock on the range its currently using without changing it. Relevant config in sssd.conf : id_provider = ad auth_provider = ad access_provider = ad subdomains_provider = none enumerate = true ignore_group_members = true cache_credentials = true ldap_id_mapping = true ldap_schema = ad # ldap_idmap_default_domain_sid = S-1-5-21-3009471437-2678356326-1117381816 ldap_idmap_default_domain = our domain.com # ldap_idmap_range_size = 500000 Thanks in advance Craig Silva _________ Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM Cenitex | Level 15, 80 Collins Street, Melbourne 3000 ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/> This office is located on the land of the Traditional Owners of the Kulin Nation. [cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/> Accountability, Collaboration, Respect, Initiative and Courage ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.

1 0

apparent error with ad_enum_cross_dom_members
by Craig H Silva (Cenitex) 24 Jun '18

24 Jun '18

Background - stupidly large AD domain with 30,000 plus groups. It is a forest with a number of legacy domains that are not relevant to our authentication on Linux but the AD admins don't want to allow us to mess with their schema so we still use group membership to manage sudo. We're also attempting to align with Windows through use of nested groups to fit in with enterprise preference for RBAC. It's complicated and there's no resourcing to put in place an IPA service which would help. Anyway these are the relevant config elements: id_provider = ad auth_provider = ad access_provider = ad subdomains_provider = none enumerate = true ignore_group_members = true cache_credentials = true ldap_id_mapping = true ldap_schema = ad ( I can provide full config if requested). We had gone to full enumeration and ignore_group_members to ensure that the groups that provide sudo access are available without ridiculous cpu utilisation and it was working but hit this apparent issue: [sssd[be[ourdomain.xxx.xxx]]] [ad_enum_cross_dom_members] (0x0080): Failed to add [CN=RG-Ourcompany-Ops-3rd Party-Data\#3-G,OU=CenITex,OU=Operations Roles,OU=Delegated Groups,OU= Infrastructure Security,DC=ourcompany,DC=xxx,DC=xxx,,DC=xx]: Input/output error Can raise a bug report if it's clear that this is the issue. Symptom is that group enumeration that was comprehensive, now seems to stop abruptly. Cheers Craig Silva _________ Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM Cenitex | Level 15, 80 Collins Street, Melbourne 3000 ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/> This office is located on the land of the Traditional Owners of the Kulin Nation. [cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/> Accountability, Collaboration, Respect, Initiative and Courage ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.

2 2

rotate host keytabs
by Natxo Asenjo 22 Jun '18

22 Jun '18

hi, does anybody rotate host keytabs? Is it worth it security-wise? Reading on how AD computer objects reset their password every 30 days ( https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-passwo…) got me thinking about the host keytabs ... Any ideas about this? -- Groeten, natxo

3 4

2FA integration: FreeIPA and Mac OS
by Oleksandr Yermolenko 22 Jun '18

22 Jun '18

Hi, Has someone managed to setup OTP 2FA between FreeIPA 4.5.X and Mac OS (High Sierra)? When authenticating with a non 2FA user, works fine. THE FIRST WAY: native heimdal client: aae$ kinit --version kinit (Heimdal 1.5.1apple1) Copyright 1995-2011 Kungliga Tekniska Högskolan Send bug-reports to heimdal-bugs(a)h5l.org aae$ aae$ kdestroy aae$ kinit --anonymous aae$ klist Credentials cache: KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7 Principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Issued Expires Principal Jun 20 12:41:07 2018 Jun 21 12:41:06 2018 krbtgt/IDM.CRP(a)IDM.CRP aae$ kinit --fast-armor-cache=KCM:74E6A71B-BCB9-43E1-8832-AFC7B17831E7 aae(a)IDM.CRP kinit: krb5_init_creds_set_fast_ccache: Matching credential (krbtgt/WELLKNOWN:ANONYMOUS@WELLKNOWN:ANONYMOUS) not found aae$ Found [1] that FAST is supported but is it enough for OTP I have no idea. Tried tcp protocol [2] without success. I can't find information how to activate anon FAST on Mac OS if this protocol is supported. What about OTP? I'm not sure that old heimdal kerberos client is compatible with pkinit/fast. I know so many questions to apple developers and support --------------------------------------------- THE SECOND WAY: client MIT version krb5-1.16.1 port install kerberos5 ... ---> Installing kerberos5 @1.16.1_0 ... slightly changed /etc/krb5.conf aae$ kdestroy kdestroy: No credentials cache found while destroying cache aae$ kinit -n aae$ klist -A Ticket cache: KCM:501 Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 06/20/2018 12:46:22 06/21/2018 12:46:22 krbtgt/IDM.CRP(a)IDM.CRP aae$ kinit -T KCM:501 aae(a)IDM.CRP Enter OTP Token Value: aae$ aae$ klist -A Ticket cache: KCM:501:2 Default principal: aae(a)IDM.CRP Valid starting Expires Service principal 06/20/2018 12:47:13 06/21/2018 12:46:59 krbtgt/IDM.CRP(a)IDM.CRP Ticket cache: KCM:501 Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 06/20/2018 12:46:22 06/21/2018 12:46:22 krbtgt/IDM.CRP(a)IDM.CRP aae$ much much better, but it's not enough because I can't use TGT. As you can see I tried to use KCM cache believing that I use native heimdal KCM server on my Mac, but without success: I do not see any valid tickets here /System/Library/CoreServices/<Ticket Viewer> and of course don't have kerberos related access to corporate resources. ---------------------------------------------- Any help is appreciated. Possible directions/ideas how to implement 2FA on Mac OS without hacks? I have successfully setup linux using pam-krb5 and anon_fast option. References: [1] https://www.redhat.com/archives/freeipa-users/2016-December/msg00214.html [2] https://www.redhat.com/archives/freeipa-users/2016-December/msg00219.html -- Oleksandr Yermolenko systems engineer

3 2

NFSv4 question
by Zane Zak 22 Jun '18

22 Jun '18

I know that this is not the ideal list for NFS questions, but I'm not sure of a better one. I'm exploring NFSv4 with kerberos security, all tied into FreeIPA. My question is whether or not the NFSv4 clients need nfs service principals. Obviously the NFSv4 server needs both, but the client side is where I'm confused. Some documentations say the client needs both a host and nfs service principal: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/ht… Other documentations say the client needs just a host principal: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… Any clarification would be appreciated. Thanks! ZZ

4 3

SSH public keys and cache invalidation
by Bart 22 Jun '18

22 Jun '18

Hi all, I have set up ipa server, established trust with an ad controller and enrolled a couple of clients to it. I have a problem understanding how to properly set up ssh pubkey authentication when it comes to caching. The issue is that when I upload the key to the server (via the web ui, for an AD user) and later delete this key (also via the web UI) I still can log in on a client machine for a couple of days using my private ssh key part. The command sss_ssh_authorizedkeys ad_user shows the correct key on both server and a client. Even after I delete manually cache files on the client, then sss_ssh_authorizedkeys displays the correct key. In a trial and error process of debugging it I added entry_cache_user_timeout = 60 to every section of sssd.conf on a client but it did not change much the situation described above. I assume that this is due to the caching settings on the server side (I guess user entries are still present in the sssd cache yet they are not visible in the web ui). Can someone please point me to the sssd cache settings that would cause ssh keys to stop from working within a reasonable time after they were deleted? Below I paste sanitized sssd config for the server: [domain/ipa.domain/ad.domain] debug_level = 10 # Enable short names without full domain use_fully_qualified_names = False ad_server = ad-1.ad.domain,ad-2.ad.domain #cache_first = True [domain/ipa.domain] ad_server = ad-1.ad.domain,ad-2.ad.domain debug_level = 10 id_provider = ipa ipa_server_mode = True ipa_server = ipa-server.ipa.domain ipa_domain = ipa.domain ipa_hostname = ipa-server.ipa.domain auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt krb5_store_password_if_offline = True enumerate = False subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout ignore_group_members = True ldap_purge_cache_timeout = 0 #cache_first = True [sssd] debug_level = 10 domain_resolution_order = ad.domain, ipa.domain services = nss, pam, ifp, ssh, sudo domains = ipa.domain [nss] debug_level = 10 filter_users = root,fedora homedir_substring = /home memcache_timeout = 600 entry_negative_timeout = 3600 override_shell = /bin/bash override_homedir = /home/%u homedir_substring = /home [pam] debug_level = 10 [sudo] debug_level = 10 [autofs] debug_level = 10 [ssh] debug_level = 10 [pac] debug_level = 10 [ifp] debug_level = 10 [secrets] debug_level = 10 [session_recording] debug_level = 10 and the client: [domain/ipa.domain/ad.domain] entry_cache_user_timeout = 60 debug_level = 10 # Enable short names without full domain use_fully_qualified_names = False subdomain_homedir = /home/%u selinux_provider = none ad_enable_gc = false ad_server = ad-1.ad.domain,ad-2.ad.domain [domain/ipa.domain] entry_cache_user_timeout = 60 debug_level = 9 ad_enable_gc = false subdomain_homedir = /home/%u # Optimization selinux_provider = none subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout ignore_group_members = True cache_first = True ldap_purge_cache_timeout = 0 ldap_sudo_smart_refresh_interval = 60 ldap_sudo_full_refresh_interval = 21600 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.domain id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = ipa-client.ipa.domain chpass_provider = ipa ipa_server = _srv_, ipa-server.ipa.domain dns_discovery_domain = ipa.domain [sssd] entry_cache_user_timeout = 60 domain_resolution_order = ad.domain,ipa.domain services = nss, sudo, pam, ssh domains = ipa.domain entry_cache_user_timeout = 60 [nss] entry_cache_user_timeout = 60 override_shell = /bin/bash override_homedir = /home/%u filter_users = root,fedora homedir_substring = /home [pam] entry_cache_user_timeout = 60 debug_level = 9 [sudo] entry_cache_user_timeout = 60 debug_level = 9 [autofs] [ssh] entry_cache_user_timeout = 60 debug_level = 9 [pac] debug_level = 9 [ifp] debug_level = 9

2 5

auth to pther providers still using freeipa
by Andrew Meyer 22 Jun '18

22 Jun '18

My company is wanting to use FreeIPA for everything. However we also utilize other external services that have their own auth system but can support oauth, or gsuite/facebook etc etc. Is this possible w/ FreeIPA? Also,Searching through google I found this - Ipsilon. Would you recommend I use that? | | | Ipsilon By Ipsilon Project Ipsilon identity provider project homepage | | | Thank you!

2 1

Can't uninstall client
by Bret Wortman 22 Jun '18

22 Jun '18

I'm trying to uninstall and reinstall the ipa client on a particular system. Here's what it looks like: # ipa-client-install --uninstall -U # ipa-client-install --enable-dns-updates --mkhomedir IPA client is already configured on this system. If you want to reinstall the IPA client, uninstall it first using 'ipa-client-install --uninstall'. The ipa-client-isntall command failed. See /var/log/ipaclient-install.log for more information # ipa-client-install --uninstall -U # Repeat at will. I've not encountered a client this "sticky" before. Any suggestions for busting it loose so I can get this system working again? It's currently enrolled with a set of IPA servers that have been decommissioned. I even tried powering one back on but that didn't help. -- photo *Bret Wortman* Founder, Damascus Products, LLC 855-644-2783 <tel:855-644-2783> | bret(a)wrapbuddies.co <mailto:bret@wrapbuddies.co> http://wrapbuddies.co/ 10332 Main St Suite 319 Fairfax, VA 22030 <http://facebook.com/wrapbuddiesco> <http://www.linkedin.com/in/bretwortman> <http://twitter.com/wrapbuddiesco> <http://instagram.com/wrapbuddies>

2 2

Tomcat/CA fails to start after upgrade
by Thomas Letherby 19 Jun '18

19 Jun '18

Hello all, I'm running FreeIPA on two CentOS 7 servers, one, the master is on a physical server, the other (a replica with CA, DNS etc) is running on an Ovirt cluster. I patched the boxes and upgraded IPA on the two servers a few days ago, and the master ran through the upgrade without any issue, however the replica fails when starting the CA, timing out after the 300 seconds. Increasing the timeout to 600 didn't help, and I rebuilt the replica from scratch which still gives the same error. If I try and restart the services after promoting it it tells me to run the upgrade, and if I do so I get the same error as the install: 2018-06-15T04:48:07Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 2018-06-15T04:48:07Z DEBUG Waiting for CA to start... 2018-06-15T04:48:08Z DEBUG request POST <replica>:8080 2018-06-15T04:48:08Z DEBUG request body '' 2018-06-15T04:48:08Z DEBUG response status 500 2018-06-15T04:48:08Z DEBUG response headers Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 2018-06-15T04:48:09Z DEBUG The ipa-server-upgrade command failed, exception: ScriptError: CA did not start in 300.0s 2018-06-15T04:48:09Z ERROR CA did not start in 300.0s Googling gets me similar problems people have had due to certificate expiry, but the dates look good as far as I can see and after a complete rebuild it should have issued new ones anyway I think. Digging through the logs I see variations on the below error, but I'm not sure why this would be the case: Could not connect to LDAP server host <Replica> port 636 Error netscape.ldap.LDAPException: Authentication failed (49) Browsing to http://<Replica>:8080/ca/admin/ca/getStatus Gets me this: *type* Exception report *message* *Subsystem unavailable* *description* *The server encountered an internal error that prevented it from fulfilling this request.* *exception* javax.ws.rs.ServiceUnavailableException: Subsystem unavailable com.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:500) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087) org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:748) *note* *The full stack trace of the root cause is available in the Apache Tomcat/7.0.76 logs.* I'm a bit stuck as to how to proceed fixing this, I'm not overly familiar with what logs do what with IPA, and I'm not seeing anything obviously wrong with the configuration. Has anyone seen this before, or can point me in the right direction to track this down? Thanks, Thomas

2 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2018