From tk at mdevsys.com Thu Oct 1 01:22:25 2015 From: tk at mdevsys.com (TomK) Date: Wed, 30 Sep 2015 21:22:25 -0400 Subject: [Freeipa-users] HBAC In-Reply-To: <560BD190.7050401@redhat.com> References: <560B3A68.7020401@mdevsys.com> <560B3D73.9050704@mdevsys.com> <20150930055047.GG4539@redhat.com> <560BD190.7050401@redhat.com> Message-ID: <560C8AD1.5080105@mdevsys.com> On 9/30/2015 8:12 AM, Martin Kosek wrote: > On 09/30/2015 07:50 AM, Alexander Bokovoy wrote: >> On Tue, 29 Sep 2015, TomK wrote: >>> Hey Guy's, >>> >>> (Sending this again as I didn't have this email included in the freeipa-users >>> mailing list so not sure if the other message will get posted.) >>> >>> Before I post a ticket to RH Support for an RFE, I'll post the request here >>> to get some feedback on options and what ideas folks have. I've a situation >>> as follows. I have the following setup in WS 2012 AD DC: >>> >>> TomK (user) >>> TomK Groups: >>> unixg >>> windowsg >>> >>> unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04' >>> windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09' >>> >>> TomK(user) also has the 'host' attribute defined as per the proper RFC for >>> LDAP. With SSSD rules I can define the rules to read the user 'host' >>> attribute but not the group 'host' attribute: >>> >>> >>> |access_provider = ldap ldap_access_order = host ldap_user_authorized_host = >>> host| >>> >>> >>> Essentially TomK to be given access to hosts listed in the 'host' attribute >>> but denied entry into lab05 for example (not listed in any group 'host' >>> attribute above) to the server. If I have a new user that has joined that >>> particular team at our organization, I can simply add her/him to the above >>> groups and this user would get access only to the listed servers in 'host' >>> attribute by default. I don't need to specify new groups in customized >>> sssd.conf or ldap.conf files or in sshd config files. Hence less to update >>> with Salt or any other CM suite. I've managed to setup SUDO rules and with >>> the openssh-ldap.diff schema SSH public keys could be stored in AD as well >>> and be read by OpenSSH. So aside from the HBAC capability on groups, >>> virtually all our needs are handled by the WS2012 AD DC as it has to follow >>> the OpenLDAP standard anyway. Now to get this we considered and are still >>> considering FreeIPA. However this idea poses a set of challenges: >>> >>> 1) In large organizations where the AD support department are only trained in >>> Windows AD setup and configuration (Only windows guy's) this would require a >>> minimal of 3 bodies to support that know LDAP/Linux. This is a large cost. >>> >>> 2) The additional server requires the same hardening as the Windows AD DC >>> servers meaning a new procedure has to be carved out for the 2+ FreeIPA >>> servers to be supported, hardened and maintained (upgraded). >>> >>> Now I probably sound somewhat anti-FreeIPA, however the challenges of >>> implementing it in large organizations surface after some deliberation, so >>> probably better to list then as it may help direct development of the product >>> to contend with the challenges (Like having a document fully dedicated to >>> hardening a FreeIPA server with selinux and other technologies in easy to >>> maintain configuration). I could be mistaken but some folks mention that >>> it's 'better' to implement this sort of HBAC through other means (?? iptables >>> ??) but never tried the alternatives yet. >>> >>> So, cutting to the end, would it be possible to add an attribute like: >>> >>> |ldap_user_authorized_host| >>> >>> but perhaps called 'ldap_group_authorized_host' to the SSSD code to enable >>> reading the 'host' attribute on AD/LDAP defined groups? >> In FreeIPA we support HBAC rules for AD users and groups. What exactly >> is wrong with that? >> >> See 'ipa help trust' for details how to map AD groups to IPA groups and >> then 'ipa help hbacrule' for how to limit access of those groups to >> specific hosts and services on them. >> >> This is all covered well in the guide: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html > More reading on External groups used for AD access control: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups > > I would also suggest a video with HBAC and Trust in action: > > https://www.youtube.com/watch?v=sQnNFJOzwa8 > > HTH, > Martin We already defined HBAC rules in the manner that all the links you pointed out indicate as an early implementation. As a product, there is no issue in IDM from that perspective. This is all great and the product is fine from that perspective. It would be good to have a dual option of either allowing SSSD or IDM / FreeIPA have full HBAC capability not just FreeIPA / IDM as in our organization that would be a huge cost savings vs implementing IDM as a separate Linux DC to be managed by a separate team. So for those customers that wish to go directly to AD or have already invested in AD can choose SSSD only (If MS bundles AD with certain purchases, for example, that is an actual cost savings for a company). Other customers who wish to keep the two separate so they do not flood AD DC's with non Windows AD settings can integrate IDM. There will be cases where there could be a potential to save on costs vs AD so the Linux IDM could be chosen as an Enterprise DC to which Windows server authenticate as well as Linux ones or vice versa, whereas those organizations already implementing Windows AD can have the option to have Linux servers connecting to the AD DC via SSSD. Since SSSD and IDM are so closely coupled, for someone who requires HBAC, the choice is either take both SSSD and IDM or neither. So other solutions are being explored instead. Do these reasons make sense as to why I posted the original ask? Thanks, TomK From pspacek at redhat.com Thu Oct 1 07:15:08 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 1 Oct 2015 09:15:08 +0200 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: References: Message-ID: <560CDD7C.8090804@redhat.com> On 30.9.2015 20:36, Matt Wells wrote: > Hi all, I hoped I may glean some brilliance from the group. > I have a Freeipa Server sitting atop a Fedora 21 server. The initial plan > was to replicate users+passwords with Windows 2012R2 server but following > some of the information in the other posts and docs we've moved to a > trust. The trust has been setup using the documentation and in short it's > worked without issue. I'm able to get principles from the Windows realm ( > marvel.comics.com). So what I'm attempting and failing to do is > authenticating my IPA users to the Windows 8 desktops. Ideally I don't > want any users in AD, it's simply there to deliver a GPO and in the next > year it will be phased out and we'll be replacing Windows 8 with linux > desktops. > > So > marvel.comics.com = windows > dc.comics.com = freeipa > > # rpm -qi freeipa-server > Name : freeipa-server > Version : 4.1.4 > Release : 1.fc21 > Architecture: x86_64 > Install Date: Tue 25 Aug 2015 08:17:56 PM UTC > Group : System Environment/Base > Size : 4521059 > License : GPLv3+ > Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID > 89ad4e8795a43f54 > Source RPM : freeipa-4.1.4-1.fc21.src.rpm > Build Date : Thu 26 Mar 2015 03:16:19 PM UTC > Build Host : buildhw-07.phx2.fedoraproject.org > [root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a > Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17 > 22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > [root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release > Fedora release 21 (Twenty One) > > To cut to the chase here's me logging into a Windows 8 desktop system. I > try to login 3 different ways; this system is a member of the marvel > domain. Time is extremely close, close enough that I feel really good > about ruling it out. Any light you all could shed on this would be > outstanding. Thank you all for your time on this, I really appreciate all > the time and effort this team puts into reading these posts. > > Username: dc/greenlantern > Password: ************ > > [root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i > greenlantern > [30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH > base="dc=dc,dc=comics,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc > )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences > krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock > passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink > objectClass" > > Username: greenlanter at dc > Password: ************ > > > [30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH > base="dc=dc,dc=comics,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc > )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName > krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey > krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration > krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange > krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth > krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences > krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock > passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink > objectClass" > > > Username: greenlanter at dc.comics.com > Password: ************ > > [30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH > base="dc=dc,dc=comics,dc=com" scope=2 > filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com > @DC.COMICS.COM > )(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM > )))" attrs="krbPrincipalName krbCanonicalName > ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference > krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference > krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases > krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData > krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife > krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData > ipaUserAuthType ipatokenRadiusConfigLink objectClass" > > >>From what I can tell, everything looks good to wbinfo; we see the domain > and he see's us. In the AD trust I can go under the trust and validate the > trust with no issues. > [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status > BUILTIN : online > DC : online > MARVEL : online > [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info > marvel.comics.com > Name : MARVEL > Alt_Name : marvel.comics.com > SID : S-1-5-21-3495301974-2766379234-3984916731 > Active Directory : Yes > Native : Yes > Primary : No > [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n > 'MARVEL.COMICS.COM\Domain > Admins' > S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) > [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info > marvel.comics.com > Name : MARVEL > Alt_Name : marvel.comics.com > SID : S-1-5-21-3495301974-2766379234-3984916731 > Active Directory : Yes > Native : Yes > Primary : No Unfortunately you will not be able to log into Windows workstations using IPA users because FreeIPA is (at the moment) missing Global Catalog component which prevents Windows from working with IPA users. It should work the other way around, but there is nothing you can do at the moment to make it working with IPA users in Windows. Global Catalog is several months away in the best case. Sorry. -- Petr^2 Spacek From paul.c.arnold4.ctr at mail.mil Thu Oct 1 10:05:45 2015 From: paul.c.arnold4.ctr at mail.mil (Arnold, Paul C CTR USARMY PEO STRI (US)) Date: Thu, 1 Oct 2015 10:05:45 +0000 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <560CDD7C.8090804@redhat.com> References: , <560CDD7C.8090804@redhat.com> Message-ID: <7322D64AC622D441BC921DE15D30CD215496AA0D@ugunhpsp.easf.csd.disa.mil> In a similar vein, is anyone aware of a (safe) automated work-around that can periodically map users into localized Windows accounts? I am conceptualizing some sort of powershell script involving a query to 389DS, but automating any form of account management that way sounds moderately terrifying, and may be out of the scope of this mailing list. Regards, -- Paul C. Arnold IT Systems Engineer Cole Engineering Services, Inc. ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Petr Spacek [pspacek at redhat.com] Sent: Thursday, October 01, 2015 03:15 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops This email was sent from a non-Department of Defense email account, and contained active links. All links are disabled, and require you to copy and paste the address to a Web browser. Please verify the identity of the sender, and confirm authenticity of all links contained within the message. Unfortunately you will not be able to log into Windows workstations using IPA users because FreeIPA is (at the moment) missing Global Catalog component which prevents Windows from working with IPA users. It should work the other way around, but there is nothing you can do at the moment to make it working with IPA users in Windows. Global Catalog is several months away in the best case. Sorry. -- Petr^2 Spacek From pbrezina at redhat.com Thu Oct 1 11:59:37 2015 From: pbrezina at redhat.com (=?ISO-8859-2?Q?Pavel_B=F8ezina?=) Date: Thu, 01 Oct 2015 13:59:37 +0200 Subject: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo In-Reply-To: References: <20150915123638.GN2884@hendrix> <9685d8df363c41bea5501ec5c0094c0e@TCCCORPEXCH02.TCC.local> <20150918084152.GF3162@hendrix.redhat.com> <66af2f79790146edbee4f9f34061f8f9@TCCCORPEXCH02.TCC.local> <20150921192924.GQ13819@hendrix.redhat.com> <594cb56fe2d54826b2d82711089d6652@TCCCORPEXCH02.TCC.local> <20150921200943.GY13819@hendrix.redhat.com> <4f5f2129a13f4d7e9aadfc35872ba5c3@TCCCORPEXCH02.TCC.local> <560A7BA1.7080706@redhat.com> <3ab447cc1e9549869d9cb58176bce9cf@TCCCORPEXCH02.TCC.local> <20150930124219.GT15644@hendrix.arn.redhat.com> Message-ID: <560D2029.7000407@redhat.com> On 09/30/2015 09:04 PM, Andy Thompson wrote: >> On Wed, Sep 30, 2015 at 12:17:22PM +0000, Andy Thompson wrote: >>>> On 09/21/2015 10:42 PM, Andy Thompson wrote: >>>>>> On Mon, Sep 21, 2015 at 07:39:01PM +0000, Andy Thompson wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Jakub Hrozek [mailto:jhrozek at redhat.com] >>>>>>>> Sent: Monday, September 21, 2015 3:29 PM >>>>>>>> To: Andy Thompson >>>>>>>> Cc: freeipa-users at redhat.com; pbrezina at redhat.com >>>>>>>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo >>>>>>>> >>>>>>>> On Mon, Sep 21, 2015 at 02:22:54PM +0000, Andy Thompson wrote: >>>>>>>>>> >>>>>>>>>> On Thu, Sep 17, 2015 at 11:42:54AM +0000, Andy Thompson >> wrote: >>>>>>>>>>> I've narrowed it down a bit doing some testing. The sudo >>>>>>>>>>> rules work when >>>>>>>>>> I remove the user group restriction from them. My sudo rules >>>>>>>>>> all have my ad groups in the rule >>>>>>>>>>> >>>>>>>>>>> Rule name: ad_linux_admins >>>>>>>>>>> Enabled: TRUE >>>>>>>>>>> Host category: all >>>>>>>>>>> Command category: all >>>>>>>>>>> RunAs User category: all >>>>>>>>>>> RunAs Group category: all >>>>>>>>>>> User Groups: ad_linux_admins <- if I remove this then >>>>>>>>>>> the rule gets >>>>>>>>>> applied >>>>>>>>>> >>>>>>>>>> Nice catch. Is the group visible after you login and run id? >>>>>>>>>> >>>>>>>>>> What is the exact IPA server version? >>>>>>>>> >>>>>>>>> Ok I also figured out if I rename my AD groups to match my IPA >>>>>>>>> groups then >>>>>>>> the sudo rules are applied. >>>>>>>>> >>>>>>>>> I tested a couple things though, if I put a rule in the local >>>>>>>>> sudoers file on a server running sssd 1.11 >>>>>>>>> >>>>>>>>> %@ "sudo commands" >>>>>>>>> >>>>>>>>> That rule was not applied. If I remove the then >>>>>>>>> the rule got >>>>>>>> applied. >>>>>>>>> >>>>>>>>> On a server running sssd 1.12 that rule works, but does not >>>>>>>>> work if I >>>>>>>> remove the . And none of the IPA sudo rules work. >>>>>>>> So something changed with the domain suffix between versions it >>>>>>>> would appear. >>>>>>>>> >>>>>>>>> They key to making the IPA sudo rules work in 1.12 is to >>>>>>>>> remove the >>>>>>>> default_domain_suffix setting in the sssd.conf, but that's not >>>>>>>> an option in my environment. >>>>>>>>> >>>>>>>>> So all the moving parts together, it appears that having AD >>>>>>>>> groups with a different name than the IPA groups in >>>>>>>>> conjunction with the default_domain_suffix setting breaks things >> right now in 1.12. >>>>>>>>> Appears since I renamed the ad group to match then the rule >>>>>>>>> without a domain suffix will get matched now >>>>>>>> >>>>>>>> Hello Andy, >>>>>>>> >>>>>>>> I'm sorry for the constant delays, but I was busy with some >>>>>>>> trust-related fixes lately. >>>>>>>> >>>>>>>> Did you have a chance to confirm that just swapping sssd /on >>>>>>>> the client/ while keeping the same version on the server fixes >>>>>>>> the issue for >>>>>> you? >>>>>>>> >>>>>>>> Pavel (CC), can you help me out here, please? I have the setup >>>>>>>> ready on my machine, so tomorrow we can take a look and >>>>>>>> experiment (I can give you access to my environment via tmate >>>>>>>> maybe..), but I wasn't able to reproduce the issue locally yet. >>>>>>> >>>>>>> It's fine I understand the backlog. >>>>>>> >>>>>>> I was not able to backrev the sssd due to dependency issues. I >>>>>>> tried >>>>>> downgrading all the dependencies and got in a loop and stopped >>>>>> trying. Are there any tricks you can think of to downgrade the >>>>>> sssd >>>> cleanly? >>>>>>> >>>>>>> -andy >>>>>>> >>>>>> >>>>>> What failures are you getting? I normally just download all >>>>>> \*sss\* packages and then downgrade with rpm -U --oldpackage. >>>>> >>>>> >>>>> I'm just trying to use yum. If I yum downgrade sssd I get a ton >>>>> of deps. If include all the deps it lists >>>>> >>>>> yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 >>>>> sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python >>>>> python-sssdconfig >>>>> >>>>> I get multilib errors with libsss_idmap. >>>>> >>>>> Looks like my local repo doesn't have libsss_idmap 1.11 available. >>>>> Let me >>>> look into that and see what repo it sits in and see if I can figure >>>> out why it's not pulling in. >>>>> >>>>> -andy >>>>> >>>> >>>> Hi, since none of us is able to reproduce this in house, can you >>>> give us more precise steps how to reproduce and more information? >>>> What I have in mind at this moment is: >>>> >>>> 1) How is membership defined? I suspect it goes as AD-USER -> >>>> AD-GROUP >>>> -> IPA->GROUP, right? What types of groups are used? >>>> >>> >>> I have AD user->AD group->external IPA group->IPA group >>> >>>> 2) sssd.conf might also turn out to be useful >>>> >>>> 3) Remove SSSD and sudo logs, reproduce and send us all the logs >>>> please with the commands to reproduce. Not just snippets. >>>> >>> >>> I can gather this up and get it over to you. >>> >>> Actually I just realized I have two other environments and this is working >> without issue in those environments. I haven't done a full sudo rollout in >> those environments yet so I didn't think to check those, but the admins rule >> is working correctly and I haven't renamed any ad groups to match my IPA >> groups. >>> >>> Could it be something in a sudo rule or something in AD that's interfering >> with this working correctly? >> >> I would first try to find the difference in the environment. Are sssd versions >> the same on the clients and servers? Are sudo versions the same? >> >> ...etc. >> >> Pavel has a sudo troubleshooting guide in the works, maybe it would help.. > > All updates are controlled from the same repo so versions are all the same between the environments, that's why I'm wondering if something in AD could cause this. Can't imagine what it would be though. Groups are all mapped in the same way. >Sudo is setup the same and works fine it was just the AD group name being different that is throwing it fits in this one environment. Once I renamed the AD groups to match it all started pulling in without any issue. I think I don't really understand this paragraph. Can you be more descriptive and specific here, please? Please, give us specific examples of the groups, names, rules, etc. > > I will add the finer grained rules in the other environments when I start rolling it out there one at a time and see if I can tie it to any of those. > > -andy > From Markus.Moj at mc.ingenico.com Thu Oct 1 12:14:34 2015 From: Markus.Moj at mc.ingenico.com (Markus.Moj at mc.ingenico.com) Date: Thu, 1 Oct 2015 12:14:34 +0000 Subject: [Freeipa-users] [FreeIPA] SUDO fails with system error Message-ID: Dear @all, I?ve an issue with two, Oracle Linux based, clients and my freeipa server. I can authenticate on any on the enrolled machines but the two oracle server aren?t able to access sudo and I don?t know why. Here are a few thing I?ve already figured out. Both machines are enrolled from scratch and I see following entries in ldap_child.log (Thu Oct 1 12:51:52 2015) [[sssd[ldap_child[3933]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/@' not found in Kerberos database (Thu Oct 1 12:51:52 2015) [[sssd[ldap_child[3934]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/@' not found in Kerberos database Furthermore I get following entries in secure log pam_unix(sudo:auth): authentication failure; logname= uid=957400001 euid=0 tty=/dev/pts/1 ruser= rhost= user= pam_sss(sudo:auth): authentication failure; logname= uid=957400001 euid=0 tty=/dev/pts/1 ruser= rhost= user= pam_sss(sudo:auth): received for user : 4 (System error) Also I get following entries in sssd_pam.log (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [@] (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [] added to PAM initgroup cache (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): user: (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sudo (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6457 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: (Thu Oct 1 14:06:14 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f0d05f51ab0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f0d04221ed0:3:@] (Thu Oct 1 14:06:14 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f0d05f51ab0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f0d05f479e0 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [4][] (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]. (Thu Oct 1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 26 (Thu Oct 1 14:06:14 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f0d05f51110][20] (Thu Oct 1 14:06:17 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f0d05f51110][20] (Thu Oct 1 14:06:17 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate In krb5_child.log I get following entries (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [main] (0x0400): krb5_child started. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [unpack_buffer] (0x1000): total buffer size: [129] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [unpack_buffer] (0x0100): cmd [241] uid [957400001] gid [957400001] validate [true] enterprise principal [false] offline [false] UPN [@] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [unpack_buffer] (0x2000): No old ccache (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:957400001] old_ccname: [not set] keytab: [/etc/krb5.keytab] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/@] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/@ in keytab. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [match_principal] (0x1000): Principal matched to the sample (host/@). (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [become_user] (0x0200): Trying to become user [957400001][957400001]. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [main] (0x2000): Running as [957400001][957400001]. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [k5c_setup] (0x2000): Running as [957400001][957400001]. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [main] (0x0400): Will perform online auth (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [] (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.736207: Getting initial credentials for @ (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.736379: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_ (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.736466: Retrieving host/@ -> krb5_ccache_conf_data/fast_avail/krbtgt\/\@@X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_ with result: -1765328243/Matching credential not found (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.736618: Sending request (167 bytes) to (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.736984: Initiating TCP connection to stream 10.46.155.120:88 (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.737944: Sending TCP request to stream 10.46.155.120:88 (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.740873: Received answer (356 bytes) from stream 10.46.155.120:88 (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.740920: Terminating TCP connection to stream 10.46.155.120:88 (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.741032: Response was from master KDC (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.741096: Received error from KDC: -1765328359/Additional pre-authentication required (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.741133: Upgrading to FAST due to presence of PA_FX_FAST in reply (Thu Oct 1 14:06:14 2015) [[sssd[krb5_child[6458]]]] [sss_child_krb5_trace_cb] (0x4000): [6458] 1443701174.741151: Restarting to upgrade to FAST Maybe someone is able and is willing to help. Thanks in advance Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 476 bytes Desc: not available URL: From Andy.Thompson at e-tcc.com Thu Oct 1 12:53:14 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Thu, 1 Oct 2015 12:53:14 +0000 Subject: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo In-Reply-To: <560D2029.7000407@redhat.com> References: <20150915123638.GN2884@hendrix> <9685d8df363c41bea5501ec5c0094c0e@TCCCORPEXCH02.TCC.local> <20150918084152.GF3162@hendrix.redhat.com> <66af2f79790146edbee4f9f34061f8f9@TCCCORPEXCH02.TCC.local> <20150921192924.GQ13819@hendrix.redhat.com> <594cb56fe2d54826b2d82711089d6652@TCCCORPEXCH02.TCC.local> <20150921200943.GY13819@hendrix.redhat.com> <4f5f2129a13f4d7e9aadfc35872ba5c3@TCCCORPEXCH02.TCC.local> <560A7BA1.7080706@redhat.com> <3ab447cc1e9549869d9cb58176bce9cf@TCCCORPEXCH02.TCC.local> <20150930124219.GT15644@hendrix.arn.redhat.com> <560D2029.7000407@redhat.com> Message-ID: <39daeab99a154236a32a0695090124a1@TCCCORPEXCH02.TCC.local> > On 09/30/2015 09:04 PM, Andy Thompson wrote: > >> On Wed, Sep 30, 2015 at 12:17:22PM +0000, Andy Thompson wrote: > >>>> On 09/21/2015 10:42 PM, Andy Thompson wrote: > >>>>>> On Mon, Sep 21, 2015 at 07:39:01PM +0000, Andy Thompson wrote: > >>>>>>>> -----Original Message----- > >>>>>>>> From: Jakub Hrozek [mailto:jhrozek at redhat.com] > >>>>>>>> Sent: Monday, September 21, 2015 3:29 PM > >>>>>>>> To: Andy Thompson > >>>>>>>> Cc: freeipa-users at redhat.com; pbrezina at redhat.com > >>>>>>>> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo > >>>>>>>> > >>>>>>>> On Mon, Sep 21, 2015 at 02:22:54PM +0000, Andy Thompson > wrote: > >>>>>>>>>> > >>>>>>>>>> On Thu, Sep 17, 2015 at 11:42:54AM +0000, Andy Thompson > >> wrote: > >>>>>>>>>>> I've narrowed it down a bit doing some testing. The sudo > >>>>>>>>>>> rules work when > >>>>>>>>>> I remove the user group restriction from them. My sudo rules > >>>>>>>>>> all have my ad groups in the rule > >>>>>>>>>>> > >>>>>>>>>>> Rule name: ad_linux_admins > >>>>>>>>>>> Enabled: TRUE > >>>>>>>>>>> Host category: all > >>>>>>>>>>> Command category: all > >>>>>>>>>>> RunAs User category: all > >>>>>>>>>>> RunAs Group category: all > >>>>>>>>>>> User Groups: ad_linux_admins <- if I remove this then > >>>>>>>>>>> the rule gets > >>>>>>>>>> applied > >>>>>>>>>> > >>>>>>>>>> Nice catch. Is the group visible after you login and run id? > >>>>>>>>>> > >>>>>>>>>> What is the exact IPA server version? > >>>>>>>>> > >>>>>>>>> Ok I also figured out if I rename my AD groups to match my IPA > >>>>>>>>> groups then > >>>>>>>> the sudo rules are applied. > >>>>>>>>> > >>>>>>>>> I tested a couple things though, if I put a rule in the local > >>>>>>>>> sudoers file on a server running sssd 1.11 > >>>>>>>>> > >>>>>>>>> %@ "sudo commands" > >>>>>>>>> > >>>>>>>>> That rule was not applied. If I remove the then > >>>>>>>>> the rule got > >>>>>>>> applied. > >>>>>>>>> > >>>>>>>>> On a server running sssd 1.12 that rule works, but does not > >>>>>>>>> work if I > >>>>>>>> remove the . And none of the IPA sudo rules work. > >>>>>>>> So something changed with the domain suffix between versions it > >>>>>>>> would appear. > >>>>>>>>> > >>>>>>>>> They key to making the IPA sudo rules work in 1.12 is to > >>>>>>>>> remove the > >>>>>>>> default_domain_suffix setting in the sssd.conf, but that's not > >>>>>>>> an option in my environment. > >>>>>>>>> > >>>>>>>>> So all the moving parts together, it appears that having AD > >>>>>>>>> groups with a different name than the IPA groups in > >>>>>>>>> conjunction with the default_domain_suffix setting breaks > >>>>>>>>> things > >> right now in 1.12. > >>>>>>>>> Appears since I renamed the ad group to match then the rule > >>>>>>>>> without a domain suffix will get matched now > >>>>>>>> > >>>>>>>> Hello Andy, > >>>>>>>> > >>>>>>>> I'm sorry for the constant delays, but I was busy with some > >>>>>>>> trust-related fixes lately. > >>>>>>>> > >>>>>>>> Did you have a chance to confirm that just swapping sssd /on > >>>>>>>> the client/ while keeping the same version on the server fixes > >>>>>>>> the issue for > >>>>>> you? > >>>>>>>> > >>>>>>>> Pavel (CC), can you help me out here, please? I have the setup > >>>>>>>> ready on my machine, so tomorrow we can take a look and > >>>>>>>> experiment (I can give you access to my environment via tmate > >>>>>>>> maybe..), but I wasn't able to reproduce the issue locally yet. > >>>>>>> > >>>>>>> It's fine I understand the backlog. > >>>>>>> > >>>>>>> I was not able to backrev the sssd due to dependency issues. I > >>>>>>> tried > >>>>>> downgrading all the dependencies and got in a loop and stopped > >>>>>> trying. Are there any tricks you can think of to downgrade the > >>>>>> sssd > >>>> cleanly? > >>>>>>> > >>>>>>> -andy > >>>>>>> > >>>>>> > >>>>>> What failures are you getting? I normally just download all > >>>>>> \*sss\* packages and then downgrade with rpm -U --oldpackage. > >>>>> > >>>>> > >>>>> I'm just trying to use yum. If I yum downgrade sssd I get a ton > >>>>> of deps. If include all the deps it lists > >>>>> > >>>>> yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5 > >>>>> sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python > >>>>> python-sssdconfig > >>>>> > >>>>> I get multilib errors with libsss_idmap. > >>>>> > >>>>> Looks like my local repo doesn't have libsss_idmap 1.11 available. > >>>>> Let me > >>>> look into that and see what repo it sits in and see if I can figure > >>>> out why it's not pulling in. > >>>>> > >>>>> -andy > >>>>> > >>>> > >>>> Hi, since none of us is able to reproduce this in house, can you > >>>> give us more precise steps how to reproduce and more information? > >>>> What I have in mind at this moment is: > >>>> > >>>> 1) How is membership defined? I suspect it goes as AD-USER -> > >>>> AD-GROUP > >>>> -> IPA->GROUP, right? What types of groups are used? > >>>> > >>> > >>> I have AD user->AD group->external IPA group->IPA group > >>> > >>>> 2) sssd.conf might also turn out to be useful > >>>> > >>>> 3) Remove SSSD and sudo logs, reproduce and send us all the logs > >>>> please with the commands to reproduce. Not just snippets. > >>>> > >>> > >>> I can gather this up and get it over to you. > >>> > >>> Actually I just realized I have two other environments and this is > >>> working > >> without issue in those environments. I haven't done a full sudo > >> rollout in those environments yet so I didn't think to check those, > >> but the admins rule is working correctly and I haven't renamed any ad > >> groups to match my IPA groups. > >>> > >>> Could it be something in a sudo rule or something in AD that's > >>> interfering > >> with this working correctly? > >> > >> I would first try to find the difference in the environment. Are sssd > >> versions the same on the clients and servers? Are sudo versions the > same? > >> > >> ...etc. > >> > >> Pavel has a sudo troubleshooting guide in the works, maybe it would > help.. > > > > All updates are controlled from the same repo so versions are all the same > between the environments, that's why I'm wondering if something in AD > could cause this. Can't imagine what it would be though. Groups are all > mapped in the same way. > >Sudo is setup the same and works fine it was just the AD group name being > different that is throwing it fits in this one environment. Once I renamed the > AD groups to match it all started pulling in without any issue. > > I think I don't really understand this paragraph. Can you be more descriptive > and specific here, please? Please, give us specific examples of the groups, > names, rules, etc. > For example, in my environments I have a group in AD called "Linux Admins". I've got that mapped into IPA as below Linux Admins-> ad_linux_admins_external -> ad_linux_admins (posix) In the environment displaying this behavior I had to rename the AD group to "ad_linux_admins" to match the posix group name in IPA in order for sudo rules to work in conjunction with the default_domain_suffix configured in sssd. -andy From kretebe at freemail.hu Thu Oct 1 09:20:20 2015 From: kretebe at freemail.hu (=?UTF-8?Q?Moln=C3=A1r_Domokos?=) Date: Thu, 1 Oct 2015 11:20:20 +0200 (CEST) Subject: [Freeipa-users] Sudo entry not found by sssd in the cache db In-Reply-To: <560A7AC5.20607@redhat.com> Message-ID: "Pavel B?ezina" ?rta: >On 09/15/2015 09:10 AM, Moln?r Domokos wrote: >> >> "Moln?r Domokos" ?rta: >> >> On 09/14/2015 03:08 PM, Pavel B?ezina wrote: >>> On 09/11/2015 02:40 PM, Moln?r Domokos wrote: >>>> Full log attached. >>>> "Moln?r Domokos" ?rta: >>>> >>>> >>>> "Pavel B?ezina" ?rta: >>>> >>>> On 09/09/2015 09:31 PM, Moln?r Domokos wrote: >>>> > I have a working IPA server and a working client >>>> config on an OpenSuse >>>> > 13.2 with the following versions: >>>> > nappali:~ # rpm -qa |grep sssd >>>> > sssd-tools-1.12.2-3.4.1.i586 >>>> > sssd-krb5-1.12.2-3.4.1.i586 >>>> > python-sssd-config-1.12.2-3.4.1.i586 >>>> > sssd-ipa-1.12.2-3.4.1.i586 >>>> > sssd-1.12.2-3.4.1.i586 >>>> > sssd-dbus-1.12.2-3.4.1.i586 >>>> > sssd-krb5-common-1.12.2-3.4.1.i586 >>>> > sssd-ldap-1.12.2-3.4.1.i586 >>>> > sssd is confihured for nss, pam, sudo >>>> > There is a test sudo rule defined in the ipa server, >>>> which applies to >>>> > user "doma". However when the user tries to use sudo >>>> the rule does not >>>> > work. >>>> > doma at nappali:/home/doma> sudo ls >>>> > doma's password: >>>> > doma is not allowed to run sudo on nappali. This >>>> incident will be reported. >>>> > The corresponding log in the sssd_sudo.log is this: >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_cmd_get_version] (0x0200): >>>> > Received client version [1]. >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_cmd_get_version] (0x0200): >>>> > Offered version [1]. >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_parse_name_for_domains] >>>> > (0x0200): name 'doma' matched without domain, user is doma >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_parse_name_for_domains] >>>> > (0x0200): name 'doma' matched without domain, user is doma >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sudosrv_cmd_parse_query_done] >>>> > (0x0200): Requesting default options for [doma] from >>>> [] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sudosrv_get_user] (0x0200): >>>> > Requesting info about [doma at szilva] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> > [sudosrv_get_sudorules_query_cache] (0x0200): >>>> Searching sysdb with >>>> > >>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> > [sudosrv_get_sudorules_query_cache] (0x0200): >>>> Searching sysdb with >>>> > [(&(objectClass=sudoRule)(|(name=defaults)))] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_parse_name_for_domains] >>>> > (0x0200): name 'doma' matched without domain, user is doma >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sss_parse_name_for_domains] >>>> > (0x0200): name 'doma' matched without domain, user is doma >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sudosrv_cmd_parse_query_done] >>>> > (0x0200): Requesting rules for [doma] from [] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> [sudosrv_get_user] (0x0200): >>>> > Requesting info about [doma at szilva] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> > [sudosrv_get_sudorules_query_cache] (0x0200): >>>> Searching sysdb with >>>> > >>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))] >>>> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >>>> > [sudosrv_get_sudorules_query_cache] (0x0200): >>>> Searching sysdb with >>>> > >>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))] >>>> > (Wed Sep 9 21:25:30 2015) [sssd[sudo]] [client_recv] >>>> (0x0200): Client >>>> > disconnected! >>>> > This seems perfectly OK with one exception. The query >>>> against the sysdb >>>> > does not find the entry. This is strange because the >>>> entry is there. >>>> > Log in sssd.log: >>>> > (Wed Sep 2 08:52:13 2015) [sssd] >>>> [sysdb_domain_init_internal] (0x0200): >>>> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb >>>> > So we know that the sysdb is >>>> /var/lib/sss/db/cache_szilva.ldb >>>> > Running the exact same query seen above in the >>>> sssd_sudo.log against the >>>> > db returns: >>>> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb >>>> > >>>> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))" >>>> > asq: Unable to register control with rootdse! >>>> > # record 1 >>>> > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb >>>> > cn: Doma_ls >>>> > dataExpireTimestamp: 1441830262 >>>> > entryUSN: 20521 >>>> > name: Doma_ls >>>> > objectClass: sudoRule >>>> > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva >>>> > sudoCommand: ls >>>> > sudoHost: nappali.szilva >>>> > sudoRunAsGroup: ALL >>>> > sudoRunAsUser: ALL >>>> > sudoUser: doma >>>> > distinguishedName: >>>> name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb >>>> > # returned 1 records >>>> > # 1 entries >>>> > # 0 referrals >>>> > This confirms that the entry is indeed there in the >>>> db. Why is it found >>>> > with ldbsearch and why does sssd_sudo not find it? >>>> > I am pretty much stuck with this one. Anyone has an idea? >>>> > >>>> > >>>> Hi, >>>> this is strange. Can you provide the logs with debug >>>> level set to 0x3ff0 >>>> >>>> please? Can you also send it as an attachment? Thanks! >>>> >>>> Sure. Here it is. Now I can see that the rule is returned. The >>>> question is why the rule does not match. Anyway much better :) >>> >>> Hi, thanks for the logs. Since the rule is returned, we will get >>> more information from sudo logs. Can you please enable sudo >>> logging by putting the following line into /etc/sudo.conf? >>> >>> Debug sudo /var/log/sudo_debug all at trace >>> >>> Run sudo and send us /var/log/sudo_debug? Thanks >> >> Thanks for the tip with the proper debug syntax - I was unable to >> get a single log item out of sudo before. >> >> I think I have found something. This is the relevant part of the >> output of all at debug (you need this not trace I think): >> >> Sep 14 22:13:39 sudo[2314] username=doma >> Sep 14 22:13:39 sudo[2314] domainname=NULL >> Sep 14 22:13:39 sudo[2314] state |= USERMATCH >> Sep 14 22:13:39 sudo[2314] Received 1 rule(s) >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175 >> Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE >> Sep 14 22:13:39 sudo[2314] emalloc: cnt=1 >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648 >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556 >> Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva >> Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206 >> Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61 >> Sep 14 22:13:39 sudo[2314] <- addr_matches_if @ ./match_addr.c:71 := >> false >> Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local >> host: false @ addr_matches() ./match_addr.c:217 >> Sep 14 22:13:39 sudo[2314] <- addr_matches @ ./match_addr.c:218 := false >> Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941 >> Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+' >> Sep 14 22:13:39 sudo[2314] <- netgr_matches @ ./match.c:953 := false >> Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776 >> Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern >> nappali.szilva: false @ hostname_matches() ./match.c:788 >> Sep 14 22:13:39 sudo[2314] <- hostname_matches @ ./match.c:789 := false >> Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not >> Sep 14 22:13:39 sudo[2314] <- sudo_sss_check_host @ ./sssd.c:591 := >> false >> Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_filterp @ ./sssd.c:654 >> := 0 >> Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 >> -> 0) >> Sep 14 22:13:39 sudo[2314] <- sudo_sss_filter_result @ ./sssd.c:221 >> := 0xb7c9e410 >> Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => >> f_sss_result=(0xb7c9e410, 0) >> Sep 14 22:13:39 sudo[2314] <- sudo_sss_result_get @ ./sssd.c:728 := >> 0xb7c9e410 >> Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries >> Sep 14 22:13:39 sudo[2314] Done with LDAP searches >> >> >> And here is the code from match.c. >> >> bool >> hostname_matches(const char *shost, const char *lhost, const char >> *pattern) >> { >> debug_decl(hostname_matches, SUDO_DEBUG_MATCH) >> const char *host; >> bool rc; >> >> host = strchr(pattern, '.') != NULL ? lhost : shost; >> if (has_meta(pattern)) { >> rc = !fnmatch(pattern, host, FNM_CASEFOLD); >> } else { >> rc = !strcasecmp(host, pattern); >> } >> sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO, >> "host %s matches sudoers pattern %s: %s", >> host, pattern, rc ? "true" : "false"); >> debug_return_bool(rc); >> } >> >> By the look of it it should match. I tried to find out how shost and >> lhost get their values - these are macros to a member of the >> sudo_user struct but that part is not debugged. Only thing I can >> confirm is that I do not get the >> >> log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host); >> >> from line 816 of sudoers.c. >> >> I also checked the hosts file and there I do have the >> >> 192.168.110.3 nappali nappali.szilva >> >> entry. >> >> Still stuck whit this. >> On 09/14/2015 03:08 PM, Pavel B?ezina wrote: >> On 09/11/2015 02:40 PM, Moln?r Domokos wrote: >> Full log attached. >> "Moln?r Domokos" ?rta: >> >> >> "Pavel B?ezina" ?rta: >> >> On 09/09/2015 09:31 PM, Moln?r Domokos wrote: >> >> > I have a working IPA server and a working client config on an OpenSuse >> > 13.2 with the following versions: >> > nappali:~ # rpm -qa |grep sssd >> > sssd-tools-1.12.2-3.4.1.i586 >> > sssd-krb5-1.12.2-3.4.1.i586 >> > python-sssd-config-1.12.2-3.4.1.i586 >> > sssd-ipa-1.12.2-3.4.1.i586 >> > sssd-1.12.2-3.4.1.i586 >> > sssd-dbus-1.12.2-3.4.1.i586 >> > sssd-krb5-common-1.12.2-3.4.1.i586 >> > sssd-ldap-1.12.2-3.4.1.i586 >> > sssd is confihured for nss, pam, sudo >> >> > There is a test sudo rule defined in the ipa server, which applies to >> > user "doma". >> However when the user tries to use sudo the rule does not >> > work. >> > doma at nappali:/home/doma> sudo ls >> > doma's password: >> > doma is not allowed to run sudo on nappali. >> This incident will be reported. >> > The corresponding log in the sssd_sudo.log is this: >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200): >> > Received client version [1]. >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200): >> > Offered version [1]. >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains] >> >> > (0x0200): name 'doma' matched without domain, user is doma >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains] >> >> > (0x0200): name 'doma' matched without domain, user is doma >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done] >> > (0x0200): Requesting default options for [doma] from [] >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200): >> > Requesting info about [doma at szilva] >> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> >> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp >> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> > [(&(objectClass=sudoRule)(|(name=defaults)))] >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains] >> >> > (0x0200): name 'doma' matched without domain, user is doma >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sss_parse_name_for_domains] >> >> > (0x0200): name 'doma' matched without domain, user is doma >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done] >> > (0x0200): Requesting rules for [doma] from [] >> > (Wed Sep >> 9 21:25:25 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200): >> > Requesting info about [doma at szilva] >> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> >> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp >> > (Wed Sep 9 21:25:25 2015) [sssd[sudo]] >> >> > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> >> > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))] >> > (Wed Sep >> 9 21:25:30 2015) [sssd[sudo]] [client_recv] (0x0200): Client >> > disconnected! >> >> > This seems perfectly OK with one exception. The query against the sysdb >> >> > does not find the entry. This is strange because the entry is there. >> > Log in sssd.log: >> > (Wed Sep >> 2 08:52:13 2015) [sssd] [sysdb_domain_init_internal] (0x0200): >> > DB File for szilva: /var/lib/sss/db/cache_szilva.ldb >> >> > So we know that the sysdb is /var/lib/sss/db/cache_szilva.ldb >> >> > Running the exact same query seen above in the sssd_sudo.log against the >> > db returns: >> > ldbsearch -H /var/lib/sss/db/cache_szilva.ldb >> > >> "(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#1816400003)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))" >> > asq: Unable to register control with rootdse! >> > # record 1 >> > dn: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb >> > cn: Doma_ls >> > dataExpireTimestamp: 1441830262 >> > entryUSN: 20521 >> > name: Doma_ls >> > objectClass: sudoRule >> > originalDN: cn=Doma_ls,ou=sudoers,dc=szilva >> > sudoCommand: ls >> > sudoHost: nappali.szilva >> > sudoRunAsGroup: ALL >> > sudoRunAsUser: ALL >> > sudoUser: doma >> >> > distinguishedName: name=Doma_ls,cn=sudorules,cn=custom,cn=szilva,cn=sysdb >> > # returned 1 records >> > # 1 entries >> > # 0 referrals >> >> > This confirms that the entry is indeed there in the db. Why is it found >> > with ldbsearch and why does sssd_sudo not find it? >> > I am pretty much stuck with this one. Anyone has an idea? >> > >> > >> Hi, >> >> this is strange. Can you provide the logs with debug level set to 0x3ff0 >> >> please? Can you also send it as an attachment? Thanks! >> >> Sure. Here it is. Now I can see that the rule is returned. The >> question is why the rule does not match. Anyway much better :) >> >> Hi, thanks for the logs. Since the rule is returned, we will get more information from sudo logs. Can you please enable sudo logging by putting the following line into /etc/sudo.conf? >> >> Debug sudo /var/log/sudo_debug all at trace >> >> Run sudo and send us /var/log/sudo_debug? Thanks >> >> Thanks for the tip with the proper debug syntax - I was unable to get a single log item out of sudo before. >> >> I think I have found something. This is the relevant part of the output of all at debug (you need this not trace I think): >> >> Sep 14 22:13:39 sudo[2314] username=doma >> Sep 14 22:13:39 sudo[2314] domainname=NULL >> Sep 14 22:13:39 sudo[2314] state |= USERMATCH >> Sep 14 22:13:39 sudo[2314] Received 1 rule(s) >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_filter_result @ ./sssd.c:175 >> Sep 14 22:13:39 sudo[2314] in_res=0xb7c9c1b8, count=1, act=INCLUDE >> Sep 14 22:13:39 sudo[2314] emalloc: cnt=1 >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_result_filterp @ ./sssd.c:648 >> Sep 14 22:13:39 sudo[2314] -> sudo_sss_check_host @ ./sssd.c:556 >> Sep 14 22:13:39 sudo[2314] val[0]=nappali.szilva >> Sep 14 22:13:39 sudo[2314] -> addr_matches @ ./match_addr.c:206 >> Sep 14 22:13:39 sudo[2314] -> addr_matches_if @ ./match_addr.c:61 >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] IP address nappali.szilva matches local host: false @ addr_matches() ./match_addr.c:217 >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] -> netgr_matches @ ./match.c:941 >> Sep 14 22:13:39 sudo[2314] netgroup appali.szilva has no leading '+' >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] -> hostname_matches @ ./match.c:776 >> Sep 14 22:13:39 sudo[2314] host nappali matches sudoers pattern nappali.szilva: false @ hostname_matches() ./match.c:788 >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] sssd/ldap sudoHost 'nappali.szilva' ... not >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] reallocating result: 0xb7cb1900 (count: 1 -> 0) >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] u_sss_result=(0xb7c9c1b8, 1) => f_sss_result=(0xb7c9e410, 0) >> Sep 14 22:13:39 sudo[2314] >> Sep 14 22:13:39 sudo[2314] searching SSSD/LDAP for sudoers entries >> Sep 14 22:13:39 sudo[2314] Done with LDAP searches >> >> >> And here is the code from match.c. >> >> bool >> hostname_matches(const char *shost, const char *lhost, const char *pattern) >> { >> debug_decl(hostname_matches, SUDO_DEBUG_MATCH) >> const char *host; >> bool rc; >> >> host = strchr(pattern,'.') != NULL ? lhost : shost; >> if (has_meta(pattern)) { >> rc = !fnmatch(pattern, host, FNM_CASEFOLD); >> } else { >> rc = !strcasecmp(host, pattern); >> } >> sudo_debug_printf(SUDO_DEBUG_DEBUG|SUDO_DEBUG_LINENO, >> "host %s matches sudoers pattern %s: %s", >> host, pattern, rc ? "true" : "false"); >> debug_return_bool(rc); >> } >> >> By the look of it it should match. I tried to find out how shost and lhost get their values - these are macros to a member of the sudo_user struct but that part is not debugged. Only thing I can confirm is that I do not get the >> >> log_warning(MSG_ONLY, N_("unable to resolve host %s"), user_host); >> >> from line 816 of sudoers.c. >> >> I also checked the hosts file and there I do have the >> >> 192.168.110.3 nappali nappali.szilva >> >> entry. >> >> Still stuck whit this. >> >> -- >> 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 >> >> Additional info. In match.c >> >> 780 host = strchr(pattern, '.') != NULL ? lhost : shost; >> >> if the pattern contains a '.' then lhost is used, which is then >> >> 784 rc = !strcasecmp(host, pattern); >> >> compared with the pattern. In our case - from the debug log - host is >> "nappali" while the pattern is "nappali.szilva". >> >> Clearly from some reason lhost does not contain the fqdn as it should. I >> also tested the set_fqdn at line 806 in sudoers.c with this code: >> >> void >> main(void) >> { >> struct addrinfo *res0, hint; >> char *p; >> char *user_host, *user_shost; >> >> user_host=malloc(500); >> user_shost=malloc(500); >> >> memset(&hint, 0, sizeof(hint)); >> hint.ai_family = PF_UNSPEC; >> hint.ai_flags = AI_FQDN; >> if (getaddrinfo("nappali", NULL, &hint, &res0) != 0) { >> printf("unable to resolve host %s", user_host); >> } else { >> user_host = strdup(res0->ai_canonname); >> printf ("Canonname, user_host: %s, >> %s\n",res0->ai_canonname,user_host); >> if ((p = strchr(user_host, '.')) != NULL) >> user_shost = strndup(user_host, (size_t)(p - user_host)); >> else >> user_shost = user_host; >> } >> printf("Shost: %s\n",user_shost); >> } >> >> This outputs on the host in question: >> >> doma at nappali:/home/doma> cc test.c >> doma at nappali:/home/doma> ./a.out >> Canonname, user_host: nappali.szilva, nappali.szilva >> Shost: nappali >> >> Seems OK. >> >> Any idea? > >Hi, I'm sorry for a late delay. Did you manage to create any progress on >this? > Hi, yes. Actually a workaround had been identified. One needs to set hostname to the fqdn and then it works. On Tue, Sep 15, 2015 at 01:58:07PM +0300, Alexander Bokovoy wrote: >> sudo doesn't do normalization and IPA's way of exposing host names is by using by default fqdn. So sudo compares local hostname with fqdn-based one, guess which way it will succeed? You theoretically could have every hostname in IPA registered non-fqdn but what you cannot have is a mix between fqdn- and non-fqdn names. And I replied: You may well be right but I still think this is a bug in sudo/sssd plugin. As sudo does indeed try to nomalize, but it fails. Here's why I think so: @line 582 in sssd.c: when calling hostname_matches it is a clear intention of the code that the hostname matching is done both against the fqdn and the naked hostname. @lines 773-790 in match.c: the implementation of hostname_matches(..) is done correctly. It guesses intelligently and chooses to match either against the fqdn or the naked hostname based on the format of the hostname provided by IPA. If there is a '.' in the IPA provided hostname name then the hostname compared to the fqdn otherwise it is compared to the bare hostname. @line 805 in sudoers.c in set_fqdn the fqdn is correctly retrieved for the host during initialization - so sudo is indeed aware of both host name versions. I tested this part it it works OK. The bug - I think - is that the information correctly retrieved during init through set_fqdn in sudoers.c somehow does not make its way to line 582 in sssd.c. There both user_shost and user_host seem to contain the naked hostname unless the bare hostaname contains the fqdn itself. I do not have enough time to find out why this happens but the above evidence suggests that there is a bug somewhere in the process. From abokovoy at redhat.com Thu Oct 1 14:03:24 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Oct 2015 17:03:24 +0300 Subject: [Freeipa-users] NFS Automount Domain Homedirs In-Reply-To: References: <20150929154754.GE4539@redhat.com> <20150930140846.GN4539@redhat.com> <20150930144619.GP4539@redhat.com> Message-ID: <20151001140324.GD4971@redhat.com> On Wed, 30 Sep 2015, Sadettin Albasan wrote: >Here is a list of installed sssd packages: > >sssd-client-1.12.4-47.el6.x86_64 >sssd-common-1.12.4-47.el6.x86_64 >sssd-ad-1.12.4-47.el6.x86_64 >sssd-1.12.4-47.el6.x86_64 >python-sssdconfig-1.12.4-47.el6.noarch >sssd-krb5-common-1.12.4-47.el6.x86_64 >sssd-ipa-1.12.4-47.el6.x86_64 >sssd-ldap-1.12.4-47.el6.x86_64 >sssd-proxy-1.12.4-47.el6.x86_64 >sssd-tools-1.12.4-47.el6.x86_64 >sssd-common-pac-1.12.4-47.el6.x86_64 >sssd-krb5-1.12.4-47.el6.x86_64 Thanks. My apologies, we checked with Sumit and apparently, SSSD in RHEL 6.7 was built without support for NFS idmap module. Can you check if using CentOS 7 client and server for NFS would work? -- / Alexander Bokovoy From fujisan43 at gmail.com Thu Oct 1 14:23:01 2015 From: fujisan43 at gmail.com (Fujisan) Date: Thu, 1 Oct 2015 16:23:01 +0200 Subject: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI Message-ID: Hello, I want to add user 'user1' with the freeipa web UI. It is not present in the list of users in the web UI but when I click "add", it says 'user with name "user1" already exists'. ldapsearch shows 'user1' is there: --------------------------------------------------------------- $ ldapsearch -x -h ipasrv uid=user1 # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=user1 # requesting: ALL # # user1, users, compat, mydomain dn: uid=user1,cn=users,cn=compat,dc=mydomain objectClass: posixAccount objectClass: top cn: user one gidNumber: 1029 gecos: user one uidNumber: 1029 loginShell: /bin/bash homeDirectory: /home/user1 uid: user1 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------------------------------------------------------- and ldapdelete doesn't work: --------------------------------------------------------------- $ ldapdelete -x -h ipasrv 'uid=user1,cn=users,cn=compat,dc=mydomain' ldap_delete: No such object (32) matched DN: dc=mydomain --------------------------------------------------------------- How can I remove 'user1' completely? Regards, Fuji -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Oct 1 14:33:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Oct 2015 17:33:11 +0300 Subject: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI In-Reply-To: References: Message-ID: <20151001143311.GE4971@redhat.com> On Thu, 01 Oct 2015, Fujisan wrote: >Hello, > >I want to add user 'user1' with the freeipa web UI. It is not present in >the list of users in the web UI but when I click "add", it says 'user with >name "user1" already exists'. > >ldapsearch shows 'user1' is there: >--------------------------------------------------------------- >$ ldapsearch -x -h ipasrv uid=user1 ># extended LDIF ># ># LDAPv3 ># base (default) with scope subtree ># filter: uid=user1 ># requesting: ALL ># > ># user1, users, compat, mydomain >dn: uid=user1,cn=users,cn=compat,dc=mydomain >objectClass: posixAccount >objectClass: top >cn: user one >gidNumber: 1029 >gecos: user one >uidNumber: 1029 >loginShell: /bin/bash >homeDirectory: /home/user1 >uid: user1 > ># search result >search: 2 >result: 0 Success > ># numResponses: 2 ># numEntries: 1 >--------------------------------------------------------------- > >and ldapdelete doesn't work: >--------------------------------------------------------------- >$ ldapdelete -x -h ipasrv 'uid=user1,cn=users,cn=compat,dc=mydomain' >ldap_delete: No such object (32) > matched DN: dc=mydomain >--------------------------------------------------------------- > >How can I remove 'user1' completely? Compat tree (cn=compat,dc=mydomain) is a read-only tree which is generated based on the primary tree (in cn=accounts,dc=mydomain). If there is no entry in the primary tree, there wouldn't be any entry in compat tree because it only adds (or removes) entries based on their existence in the primary tree. What I see looks like a replication conflict that might have left an entry named uid=user1+nsuniqueid=,cn=users,cn=accounts,dc=mydomain and which caused creation of this compat tree entry. Can you show output of ldapsearch -D cn=directory\ manager -W -b cn=accounts,dc=mydomain '(uid=user1*)' ? -- / Alexander Bokovoy From aebruno2 at buffalo.edu Thu Oct 1 15:03:09 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Thu, 1 Oct 2015 11:03:09 -0400 Subject: [Freeipa-users] ipa upgrade failed Message-ID: <20151001150309.GA10653@dead.ccr.buffalo.edu> Running CentOS 7.1.1503. Upgrading via yum update from: ipa-server.x86_64 0:4.1.0-18.el7.centos.3 --to-- ipa-server.x86_64 0:4.1.0-18.el7.centos.4 We have 3 replicates. Upgrading the first replicate (first-master) went fine. Upgrading the second replicate failed. Got the following error during the update on the second replicate: Pre schema upgrade failed with [Errno 111] Connection refused IPA upgrade failed. Where should I look for more info? Looked in the usual places and didn't see anything out of the ordinary. How can I fix/verify the upgrade? Thanks! --Andrew From d.korittki at mittwald.de Thu Oct 1 15:06:34 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Thu, 1 Oct 2015 17:06:34 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts Message-ID: <560D4BFA.2040303@mittwald.de> Hello folks, I am running two FreeIPA Servers with around 100 users and around 15.000 hosts, which are used by users to login via ssh. The FreeIPA servers (which are Centos 7.0) ran good for a while, but as more and more hosts got migrated to serve as FreeIPA hosts, it started to get slow and unstable. For example, its hard to maintain hostgroups, which have more than 1.000 hosts. The ipa host-* commands are getting slower as the hostgroup grows. Is this normal? We also experience random dirsrv segfaults. Here's a dmesg line from the latest: [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the problem. I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that solve my problems? FreeIPA server version is 3.3.3-28.el7.centos 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 Kind regards, Dominik Korittki From mbasti at redhat.com Thu Oct 1 15:09:23 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 17:09:23 +0200 Subject: [Freeipa-users] ipa upgrade failed In-Reply-To: <20151001150309.GA10653@dead.ccr.buffalo.edu> References: <20151001150309.GA10653@dead.ccr.buffalo.edu> Message-ID: <560D4CA3.8080609@redhat.com> On 10/01/2015 05:03 PM, Andrew E. Bruno wrote: > Running CentOS 7.1.1503. > > Upgrading via yum update from: > > ipa-server.x86_64 0:4.1.0-18.el7.centos.3 > > --to-- > > ipa-server.x86_64 0:4.1.0-18.el7.centos.4 > > > We have 3 replicates. Upgrading the first replicate (first-master) went > fine. Upgrading the second replicate failed. > > Got the following error during the update on the second replicate: > > Pre schema upgrade failed with [Errno 111] Connection refused > IPA upgrade failed. > > Where should I look for more info? Looked in the usual places and didn't > see anything out of the ordinary. How can I fix/verify the upgrade? > > Thanks! > > --Andrew > Hello, can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for more specific errors? Martin From jhrozek at redhat.com Thu Oct 1 15:19:17 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 1 Oct 2015 17:19:17 +0200 Subject: [Freeipa-users] [FreeIPA] SUDO fails with system error In-Reply-To: References: Message-ID: <20151001151917.GD17053@hendrix.redhat.com> On Thu, Oct 01, 2015 at 12:14:34PM +0000, Markus.Moj at mc.ingenico.com wrote: > Dear @all, > > > > I?ve an issue with two, Oracle Linux based, clients and my freeipa server. I can authenticate on any on the enrolled machines but the two oracle server aren?t able to access sudo and I don?t know why. ~~~~~~~~~~~ What version of OEL and sssd? > > Here are a few thing I?ve already figured out. > > > > Both machines are enrolled from scratch and I see following entries in ldap_child.log > > (Thu Oct 1 12:51:52 2015) [[sssd[ldap_child[3933]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/@' not found in Kerberos database > > (Thu Oct 1 12:51:52 2015) [[sssd[ldap_child[3934]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/@' not found in Kerberos database This looks like the enrollment is not correct, are you able to kinit -k ? > > > > Furthermore I get following entries in secure log > > pam_unix(sudo:auth): authentication failure; logname= uid=957400001 euid=0 tty=/dev/pts/1 ruser= rhost= user= > > pam_sss(sudo:auth): authentication failure; logname= uid=957400001 euid=0 tty=/dev/pts/1 ruser= rhost= user= > > pam_sss(sudo:auth): received for user : 4 (System error) You said you were able to authenticate, but here the authentication is throwing system error. How did you authenticate, was it maye with ssh keys? Is that all you have in krb5_child.log? I don't see the child exiting in the logs.. From aebruno2 at buffalo.edu Thu Oct 1 15:28:35 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Thu, 1 Oct 2015 11:28:35 -0400 Subject: [Freeipa-users] ipa upgrade failed In-Reply-To: <560D4CA3.8080609@redhat.com> References: <20151001150309.GA10653@dead.ccr.buffalo.edu> <560D4CA3.8080609@redhat.com> Message-ID: <20151001152835.GB10653@dead.ccr.buffalo.edu> On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote: > > > On 10/01/2015 05:03 PM, Andrew E. Bruno wrote: > >Running CentOS 7.1.1503. > > > >Upgrading via yum update from: > > > > ipa-server.x86_64 0:4.1.0-18.el7.centos.3 > > > > --to-- > > > > ipa-server.x86_64 0:4.1.0-18.el7.centos.4 > > > >We have 3 replicates. Upgrading the first replicate (first-master) went > >fine. Upgrading the second replicate failed. > > > >Got the following error during the update on the second replicate: > > > >Pre schema upgrade failed with [Errno 111] Connection refused > >IPA upgrade failed. > > > >Where should I look for more info? Looked in the usual places and didn't > >see anything out of the ordinary. How can I fix/verify the upgrade? > > > >Thanks! > > > >--Andrew > > > Hello, > > can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for > more specific errors? Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time of the upgrade: [01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation threads - op stack size 84 max work q size 59 max work q stack size 59 [01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled [01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting up [01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B is less than db size 28639232B; We recommend to increase the entry cache size nsslapd-cachememsize. [01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. ... tion. [01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/srv-d13-39-02.int.ccr.buffalo.edu at INT.CCR.BUFFALO.EDU] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" (srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to go into backoff mode. Will retry later. [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated [01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) ... [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22231 (rc: 32) [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22232 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22233 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22234 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22235 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22236 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22237 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22238 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22239 (rc: 32) [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22240 (rc: 32) .. These delete_changerecord are repeated all the way to 321722. Here's the errors from /var/log/ipaupgrade.log 2015-10-01T14:44:49Z DEBUG [4/10]: starting directory server 2015-10-01T14:44:49Z DEBUG Starting external process 2015-10-01T14:44:49Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' 2015-10-01T14:44:50Z DEBUG Process finished, return code=0 2015-10-01T14:44:50Z DEBUG stdout= 2015-10-01T14:44:50Z DEBUG stderr= 2015-10-01T14:44:50Z DEBUG duration: 0 seconds 2015-10-01T14:44:50Z DEBUG [5/10]: preparing server upgrade 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused 2015-10-01T14:45:00Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-10-01T14:45:00Z DEBUG duration: 10 seconds 2015-10-01T14:45:00Z DEBUG [6/10]: updating schema ... 2015-10-01T14:45:43Z DEBUG duration: 2 seconds 2015-10-01T14:45:43Z DEBUG [9/10]: restoring configuration 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-10-01T14:45:43Z DEBUG duration: 0 seconds 2015-10-01T14:45:43Z DEBUG [10/10]: starting directory server 2015-10-01T14:45:43Z DEBUG Starting external process 2015-10-01T14:45:43Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 2015-10-01T14:45:44Z DEBUG stdout= 2015-10-01T14:45:44Z DEBUG stderr= 2015-10-01T14:45:44Z DEBUG Starting external process 2015-10-01T14:45:44Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at INT-CCR-BUFFALO-EDU.service' 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 2015-10-01T14:45:44Z DEBUG stdout=active 2015-10-01T14:45:44Z DEBUG stderr= 2015-10-01T14:45:44Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2015-10-01T14:45:51Z DEBUG duration: 7 seconds 2015-10-01T14:45:51Z DEBUG Done. 2015-10-01T14:45:51Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 151, in run raise admintool.ScriptError('IPA upgrade failed.', 1) 2015-10-01T14:45:51Z DEBUG The ipa-ldap-updater command failed, exception: ScriptError: IPA upgrade failed. 2015-10-01T14:45:51Z ERROR IPA upgrade failed. 2015-10-01T14:45:51Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} 2015-10-01T14:45:51Z DEBUG IPA version 4.1.0-18.el7.centos.4 2015-10-01T14:45:51Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' ... 2015-10-01T14:48:37Z DEBUG The CA status is: running 2015-10-01T14:48:37Z INFO The ipa-upgradeconfig command was successful But from looking through the ipaupgrade.log it seems like the schema changes were in fact applied? From fujisan43 at gmail.com Thu Oct 1 15:34:26 2015 From: fujisan43 at gmail.com (Fujisan) Date: Thu, 1 Oct 2015 17:34:26 +0200 Subject: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI In-Reply-To: <20151001143311.GE4971@redhat.com> References: <20151001143311.GE4971@redhat.com> Message-ID: I get this: ----------------------------- $ ldapsearch -D cn=directory\ manager -W -b cn=accounts,dc=mydomain '(uid=user1*)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=user1*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ----------------------------- On Thu, Oct 1, 2015 at 4:33 PM, Alexander Bokovoy wrote: > On Thu, 01 Oct 2015, Fujisan wrote: > >> Hello, >> >> I want to add user 'user1' with the freeipa web UI. It is not present in >> the list of users in the web UI but when I click "add", it says 'user with >> name "user1" already exists'. >> >> ldapsearch shows 'user1' is there: >> --------------------------------------------------------------- >> $ ldapsearch -x -h ipasrv uid=user1 >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: uid=user1 >> # requesting: ALL >> # >> >> # user1, users, compat, mydomain >> dn: uid=user1,cn=users,cn=compat,dc=mydomain >> objectClass: posixAccount >> objectClass: top >> cn: user one >> gidNumber: 1029 >> gecos: user one >> uidNumber: 1029 >> loginShell: /bin/bash >> homeDirectory: /home/user1 >> uid: user1 >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> --------------------------------------------------------------- >> >> and ldapdelete doesn't work: >> --------------------------------------------------------------- >> $ ldapdelete -x -h ipasrv 'uid=user1,cn=users,cn=compat,dc=mydomain' >> ldap_delete: No such object (32) >> matched DN: dc=mydomain >> --------------------------------------------------------------- >> >> How can I remove 'user1' completely? >> > Compat tree (cn=compat,dc=mydomain) is a read-only tree which is > generated based on the primary tree (in cn=accounts,dc=mydomain). > > If there is no entry in the primary tree, there wouldn't be any entry in > compat tree because it only adds (or removes) entries based on their > existence in the primary tree. > > What I see looks like a replication conflict that might have left an > entry named > uid=user1+nsuniqueid=,cn=users,cn=accounts,dc=mydomain and > which caused creation of this compat tree entry. > > Can you show output of ldapsearch -D cn=directory\ manager -W -b > cn=accounts,dc=mydomain '(uid=user1*)' > ? > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Oct 1 15:40:34 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 1 Oct 2015 17:40:34 +0200 Subject: [Freeipa-users] ipa upgrade failed In-Reply-To: <20151001152835.GB10653@dead.ccr.buffalo.edu> References: <20151001150309.GA10653@dead.ccr.buffalo.edu> <560D4CA3.8080609@redhat.com> <20151001152835.GB10653@dead.ccr.buffalo.edu> Message-ID: <560D53F2.5@redhat.com> On 10/01/2015 05:28 PM, Andrew E. Bruno wrote: > On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote: >> >> On 10/01/2015 05:03 PM, Andrew E. Bruno wrote: >>> Running CentOS 7.1.1503. >>> >>> Upgrading via yum update from: >>> >>> ipa-server.x86_64 0:4.1.0-18.el7.centos.3 >>> >>> --to-- >>> >>> ipa-server.x86_64 0:4.1.0-18.el7.centos.4 >>> >>> We have 3 replicates. Upgrading the first replicate (first-master) went >>> fine. Upgrading the second replicate failed. >>> >>> Got the following error during the update on the second replicate: >>> >>> Pre schema upgrade failed with [Errno 111] Connection refused >>> IPA upgrade failed. >>> >>> Where should I look for more info? Looked in the usual places and didn't >>> see anything out of the ordinary. How can I fix/verify the upgrade? >>> >>> Thanks! >>> >>> --Andrew >>> >> Hello, >> >> can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for >> more specific errors? > Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time of the upgrade: > > [01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation threads - op stack size 84 max work q size 59 max work q stack size 59 > [01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled > [01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting up > [01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B is less than db size 28639232B; We recommend to increase the entry cache size nsslapd-cachememsize. > [01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. > ... > tion. > [01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 > [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 > [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated > [01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/srv-d13-39-02.int.ccr.buffalo.edu at INT.CCR.BUFFALO.EDU] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) > [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" (srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to go into backoff mode. Will retry later. > [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated > [01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > ... > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22231 (rc: 32) > [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22232 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22233 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22234 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22235 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22236 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22237 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22238 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22239 (rc: 32) > [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22240 (rc: 32) > .. > > > These delete_changerecord are repeated all the way to 321722. > > > Here's the errors from /var/log/ipaupgrade.log > > > 2015-10-01T14:44:49Z DEBUG [4/10]: starting directory server > 2015-10-01T14:44:49Z DEBUG Starting external process > 2015-10-01T14:44:49Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > 2015-10-01T14:44:50Z DEBUG Process finished, return code=0 > 2015-10-01T14:44:50Z DEBUG stdout= > 2015-10-01T14:44:50Z DEBUG stderr= > 2015-10-01T14:44:50Z DEBUG duration: 0 seconds > 2015-10-01T14:44:50Z DEBUG [5/10]: preparing server upgrade > 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused > 2015-10-01T14:45:00Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade > ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ > self.create_connection() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection > dm_password=self.dm_password, pw_name=self.pw_name) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect > conn.do_external_bind(pw_name) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > > 2015-10-01T14:45:00Z DEBUG duration: 10 seconds > 2015-10-01T14:45:00Z DEBUG [6/10]: updating schema > > ... > > 2015-10-01T14:45:43Z DEBUG duration: 2 seconds > 2015-10-01T14:45:43Z DEBUG [9/10]: restoring configuration > 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-10-01T14:45:43Z DEBUG duration: 0 seconds > 2015-10-01T14:45:43Z DEBUG [10/10]: starting directory server > 2015-10-01T14:45:43Z DEBUG Starting external process > 2015-10-01T14:45:43Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 > 2015-10-01T14:45:44Z DEBUG stdout= > 2015-10-01T14:45:44Z DEBUG stderr= > 2015-10-01T14:45:44Z DEBUG Starting external process > 2015-10-01T14:45:44Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 > 2015-10-01T14:45:44Z DEBUG stdout=active > > 2015-10-01T14:45:44Z DEBUG stderr= > 2015-10-01T14:45:44Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > 2015-10-01T14:45:51Z DEBUG duration: 7 seconds > 2015-10-01T14:45:51Z DEBUG Done. > 2015-10-01T14:45:51Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute > return_value = self.run() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 151, in run > raise admintool.ScriptError('IPA upgrade failed.', 1) > > 2015-10-01T14:45:51Z DEBUG The ipa-ldap-updater command failed, exception: ScriptError: IPA upgrade failed. > 2015-10-01T14:45:51Z ERROR IPA upgrade failed. > 2015-10-01T14:45:51Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} > 2015-10-01T14:45:51Z DEBUG IPA version 4.1.0-18.el7.centos.4 > 2015-10-01T14:45:51Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > > ... > > 2015-10-01T14:48:37Z DEBUG The CA status is: running > 2015-10-01T14:48:37Z INFO The ipa-upgradeconfig command was successful > > > But from looking through the ipaupgrade.log it seems like the schema changes were in fact applied? > It looks like the DS has not been ready yet It started at: [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests But upgrade failed before: 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused If there are no other errors listed, so other part of upgrade are successful. Pre-schema upgrade is done for DNS forward zones, but in case that this was successfully done on master, dns forwardzones should be already updated. This code is also removed in versions of IPA, so it should not cause issues in future. Martin From simo at redhat.com Thu Oct 1 16:04:14 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 1 Oct 2015 12:04:14 -0400 Subject: [Freeipa-users] HBAC In-Reply-To: <560C8AD1.5080105@mdevsys.com> References: <560B3A68.7020401@mdevsys.com> <560B3D73.9050704@mdevsys.com> <20150930055047.GG4539@redhat.com> <560BD190.7050401@redhat.com> <560C8AD1.5080105@mdevsys.com> Message-ID: <560D597E.7030205@redhat.com> On 30/09/15 21:22, TomK wrote: > > > On 9/30/2015 8:12 AM, Martin Kosek wrote: >> On 09/30/2015 07:50 AM, Alexander Bokovoy wrote: >>> On Tue, 29 Sep 2015, TomK wrote: >>>> Hey Guy's, >>>> >>>> (Sending this again as I didn't have this email included in the >>>> freeipa-users >>>> mailing list so not sure if the other message will get posted.) >>>> >>>> Before I post a ticket to RH Support for an RFE, I'll post the >>>> request here >>>> to get some feedback on options and what ideas folks have. I've a >>>> situation >>>> as follows. I have the following setup in WS 2012 AD DC: >>>> >>>> TomK (user) >>>> TomK Groups: >>>> unixg >>>> windowsg >>>> >>>> unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04' >>>> windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09' >>>> >>>> TomK(user) also has the 'host' attribute defined as per the proper >>>> RFC for >>>> LDAP. With SSSD rules I can define the rules to read the user 'host' >>>> attribute but not the group 'host' attribute: >>>> >>>> >>>> |access_provider = ldap ldap_access_order = host >>>> ldap_user_authorized_host = >>>> host| >>>> >>>> >>>> Essentially TomK to be given access to hosts listed in the 'host' >>>> attribute >>>> but denied entry into lab05 for example (not listed in any group 'host' >>>> attribute above) to the server. If I have a new user that has >>>> joined that >>>> particular team at our organization, I can simply add her/him to the >>>> above >>>> groups and this user would get access only to the listed servers in >>>> 'host' >>>> attribute by default. I don't need to specify new groups in customized >>>> sssd.conf or ldap.conf files or in sshd config files. Hence less to >>>> update >>>> with Salt or any other CM suite. I've managed to setup SUDO rules >>>> and with >>>> the openssh-ldap.diff schema SSH public keys could be stored in AD >>>> as well >>>> and be read by OpenSSH. So aside from the HBAC capability on groups, >>>> virtually all our needs are handled by the WS2012 AD DC as it has to >>>> follow >>>> the OpenLDAP standard anyway. Now to get this we considered and are >>>> still >>>> considering FreeIPA. However this idea poses a set of challenges: >>>> >>>> 1) In large organizations where the AD support department are only >>>> trained in >>>> Windows AD setup and configuration (Only windows guy's) this would >>>> require a >>>> minimal of 3 bodies to support that know LDAP/Linux. This is a >>>> large cost. >>>> >>>> 2) The additional server requires the same hardening as the Windows >>>> AD DC >>>> servers meaning a new procedure has to be carved out for the 2+ FreeIPA >>>> servers to be supported, hardened and maintained (upgraded). >>>> >>>> Now I probably sound somewhat anti-FreeIPA, however the challenges of >>>> implementing it in large organizations surface after some >>>> deliberation, so >>>> probably better to list then as it may help direct development of >>>> the product >>>> to contend with the challenges (Like having a document fully >>>> dedicated to >>>> hardening a FreeIPA server with selinux and other technologies in >>>> easy to >>>> maintain configuration). I could be mistaken but some folks >>>> mention that >>>> it's 'better' to implement this sort of HBAC through other means (?? >>>> iptables >>>> ??) but never tried the alternatives yet. >>>> >>>> So, cutting to the end, would it be possible to add an attribute like: >>>> >>>> |ldap_user_authorized_host| >>>> >>>> but perhaps called 'ldap_group_authorized_host' to the SSSD code to >>>> enable >>>> reading the 'host' attribute on AD/LDAP defined groups? >>> In FreeIPA we support HBAC rules for AD users and groups. What exactly >>> is wrong with that? >>> >>> See 'ipa help trust' for details how to map AD groups to IPA groups and >>> then 'ipa help hbacrule' for how to limit access of those groups to >>> specific hosts and services on them. >>> >>> This is all covered well in the guide: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html >>> >> More reading on External groups used for AD access control: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups >> >> >> I would also suggest a video with HBAC and Trust in action: >> >> https://www.youtube.com/watch?v=sQnNFJOzwa8 >> >> HTH, >> Martin > > We already defined HBAC rules in the manner that all the links you > pointed out indicate as an early implementation. As a product, there is > no issue in IDM from that perspective. This is all great and the > product is fine from that perspective. > > It would be good to have a dual option of either allowing SSSD or IDM / > FreeIPA have full HBAC capability not just FreeIPA / IDM as in our > organization that would be a huge cost savings vs implementing IDM as a > separate Linux DC to be managed by a separate team. So for those > customers that wish to go directly to AD or have already invested in AD > can choose SSSD only (If MS bundles AD with certain purchases, for > example, that is an actual cost savings for a company). Other customers > who wish to keep the two separate so they do not flood AD DC's with non > Windows AD settings can integrate IDM. > > There will be cases where there could be a potential to save on costs vs > AD so the Linux IDM could be chosen as an Enterprise DC to which Windows > server authenticate as well as Linux ones or vice versa, whereas those > organizations already implementing Windows AD can have the option to > have Linux servers connecting to the AD DC via SSSD. > > Since SSSD and IDM are so closely coupled, for someone who requires > HBAC, the choice is either take both SSSD and IDM or neither. So other > solutions are being explored instead. > > Do these reasons make sense as to why I posted the original ask? When SSSD is integrated directly in AD you can use Group Policies to define access controls. See ad_gpo_access_control in sssd-ad(5) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Oct 1 16:08:08 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 1 Oct 2015 12:08:08 -0400 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <560CDD7C.8090804@redhat.com> References: <560CDD7C.8090804@redhat.com> Message-ID: <560D5A68.7070608@redhat.com> On 01/10/15 03:15, Petr Spacek wrote: > On 30.9.2015 20:36, Matt Wells wrote: >> Hi all, I hoped I may glean some brilliance from the group. >> I have a Freeipa Server sitting atop a Fedora 21 server. The initial plan >> was to replicate users+passwords with Windows 2012R2 server but following >> some of the information in the other posts and docs we've moved to a >> trust. The trust has been setup using the documentation and in short it's >> worked without issue. I'm able to get principles from the Windows realm ( >> marvel.comics.com). So what I'm attempting and failing to do is >> authenticating my IPA users to the Windows 8 desktops. Ideally I don't >> want any users in AD, it's simply there to deliver a GPO and in the next >> year it will be phased out and we'll be replacing Windows 8 with linux >> desktops. >> >> So >> marvel.comics.com = windows >> dc.comics.com = freeipa >> >> # rpm -qi freeipa-server >> Name : freeipa-server >> Version : 4.1.4 >> Release : 1.fc21 >> Architecture: x86_64 >> Install Date: Tue 25 Aug 2015 08:17:56 PM UTC >> Group : System Environment/Base >> Size : 4521059 >> License : GPLv3+ >> Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID >> 89ad4e8795a43f54 >> Source RPM : freeipa-4.1.4-1.fc21.src.rpm >> Build Date : Thu 26 Mar 2015 03:16:19 PM UTC >> Build Host : buildhw-07.phx2.fedoraproject.org >> [root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a >> Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17 >> 22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> [root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release >> Fedora release 21 (Twenty One) >> >> To cut to the chase here's me logging into a Windows 8 desktop system. I >> try to login 3 different ways; this system is a member of the marvel >> domain. Time is extremely close, close enough that I feel really good >> about ruling it out. Any light you all could shed on this would be >> outstanding. Thank you all for your time on this, I really appreciate all >> the time and effort this team puts into reading these posts. >> >> Username: dc/greenlantern >> Password: ************ >> >> [root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i >> greenlantern >> [30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH >> base="dc=dc,dc=comics,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >> )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink >> objectClass" >> >> Username: greenlanter at dc >> Password: ************ >> >> >> [30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH >> base="dc=dc,dc=comics,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >> )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >> passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink >> objectClass" >> >> >> Username: greenlanter at dc.comics.com >> Password: ************ >> >> [30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH >> base="dc=dc,dc=comics,dc=com" scope=2 >> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com >> @DC.COMICS.COM >> )(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM >> )))" attrs="krbPrincipalName krbCanonicalName >> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference >> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData >> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >> ipaUserAuthType ipatokenRadiusConfigLink objectClass" >> >> >> >From what I can tell, everything looks good to wbinfo; we see the domain >> and he see's us. In the AD trust I can go under the trust and validate the >> trust with no issues. >> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status >> BUILTIN : online >> DC : online >> MARVEL : online >> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >> marvel.comics.com >> Name : MARVEL >> Alt_Name : marvel.comics.com >> SID : S-1-5-21-3495301974-2766379234-3984916731 >> Active Directory : Yes >> Native : Yes >> Primary : No >> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n >> 'MARVEL.COMICS.COM\Domain >> Admins' >> S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) >> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >> marvel.comics.com >> Name : MARVEL >> Alt_Name : marvel.comics.com >> SID : S-1-5-21-3495301974-2766379234-3984916731 >> Active Directory : Yes >> Native : Yes >> Primary : No > > Unfortunately you will not be able to log into Windows workstations using IPA > users because FreeIPA is (at the moment) missing Global Catalog component > which prevents Windows from working with IPA users. > > It should work the other way around, but there is nothing you can do at the > moment to make it working with IPA users in Windows. Global Catalog is several > months away in the best case. This is not entirely true. There is no way to add IPA SIDs to the relevant authorization groups using the GUI tools in AD, but technically you can do that using command line tools and pasting in SIDs directly. Authentication would be possible then, however Windows clients will never be able to resolve SID to Names, so looking at file permissions you will not be able to see user names, but only SIDs for IPA users. Some tools that may depend on SID->Name translation may also fail in unexpected ways. This is why we do not recommend to try this, but it is technically possible if you know very well how to handle everything through Windows CLIs (I don't so don't ask :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From aebruno2 at buffalo.edu Thu Oct 1 17:50:11 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Thu, 1 Oct 2015 13:50:11 -0400 Subject: [Freeipa-users] ipa upgrade failed In-Reply-To: <560D53F2.5@redhat.com> References: <20151001150309.GA10653@dead.ccr.buffalo.edu> <560D4CA3.8080609@redhat.com> <20151001152835.GB10653@dead.ccr.buffalo.edu> <560D53F2.5@redhat.com> Message-ID: <20151001175011.GD10653@dead.ccr.buffalo.edu> On Thu, Oct 01, 2015 at 05:40:34PM +0200, Martin Basti wrote: > > > On 10/01/2015 05:28 PM, Andrew E. Bruno wrote: > >On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote: > >> > >>On 10/01/2015 05:03 PM, Andrew E. Bruno wrote: > >>>Running CentOS 7.1.1503. > >>> > >>>Upgrading via yum update from: > >>> > >>> ipa-server.x86_64 0:4.1.0-18.el7.centos.3 > >>> > >>> --to-- > >>> > >>> ipa-server.x86_64 0:4.1.0-18.el7.centos.4 > >>> > >>>We have 3 replicates. Upgrading the first replicate (first-master) went > >>>fine. Upgrading the second replicate failed. > >>> > >>>Got the following error during the update on the second replicate: > >>> > >>>Pre schema upgrade failed with [Errno 111] Connection refused > >>>IPA upgrade failed. > >>> > >>>Where should I look for more info? Looked in the usual places and didn't > >>>see anything out of the ordinary. How can I fix/verify the upgrade? > >>> > >>>Thanks! > >>> > >>>--Andrew > >>> > >>Hello, > >> > >>can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for > >>more specific errors? > >Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time of the upgrade: > > > >[01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation threads - op stack size 84 max work q size 59 max work q stack size 59 > >[01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled > >[01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting up > >[01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B is less than db size 28639232B; We recommend to increase the entry cache size nsslapd-cachememsize. > >[01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. > >... > >tion. > >[01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 > >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 > >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated > >[01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/srv-d13-39-02.int.ccr.buffalo.edu at INT.CCR.BUFFALO.EDU] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) > >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" (srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to go into backoff mode. Will retry later. > >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated > >[01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > >... > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22231 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22232 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22233 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22234 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22235 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22236 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22237 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22238 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22239 (rc: 32) > >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22240 (rc: 32) > >.. > > > > > >These delete_changerecord are repeated all the way to 321722. > > > > > >Here's the errors from /var/log/ipaupgrade.log > > > > > >2015-10-01T14:44:49Z DEBUG [4/10]: starting directory server > >2015-10-01T14:44:49Z DEBUG Starting external process > >2015-10-01T14:44:49Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > >2015-10-01T14:44:50Z DEBUG Process finished, return code=0 > >2015-10-01T14:44:50Z DEBUG stdout= > >2015-10-01T14:44:50Z DEBUG stderr= > >2015-10-01T14:44:50Z DEBUG duration: 0 seconds > >2015-10-01T14:44:50Z DEBUG [5/10]: preparing server upgrade > >2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused > >2015-10-01T14:45:00Z DEBUG Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade > > ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ > > self.create_connection() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection > > dm_password=self.dm_password, pw_name=self.pw_name) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect > > conn.do_external_bind(pw_name) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind > > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait > > self.__wait_for_connection(timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection > > wait_for_open_socket(lurl.hostport, timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket > > raise e > >error: [Errno 111] Connection refused > > > >2015-10-01T14:45:00Z DEBUG duration: 10 seconds > >2015-10-01T14:45:00Z DEBUG [6/10]: updating schema > > > >... > > > >2015-10-01T14:45:43Z DEBUG duration: 2 seconds > >2015-10-01T14:45:43Z DEBUG [9/10]: restoring configuration > >2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > >2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > >2015-10-01T14:45:43Z DEBUG duration: 0 seconds > >2015-10-01T14:45:43Z DEBUG [10/10]: starting directory server > >2015-10-01T14:45:43Z DEBUG Starting external process > >2015-10-01T14:45:43Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > >2015-10-01T14:45:44Z DEBUG Process finished, return code=0 > >2015-10-01T14:45:44Z DEBUG stdout= > >2015-10-01T14:45:44Z DEBUG stderr= > >2015-10-01T14:45:44Z DEBUG Starting external process > >2015-10-01T14:45:44Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > >2015-10-01T14:45:44Z DEBUG Process finished, return code=0 > >2015-10-01T14:45:44Z DEBUG stdout=active > > > >2015-10-01T14:45:44Z DEBUG stderr= > >2015-10-01T14:45:44Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > >2015-10-01T14:45:51Z DEBUG duration: 7 seconds > >2015-10-01T14:45:51Z DEBUG Done. > >2015-10-01T14:45:51Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute > > return_value = self.run() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 151, in run > > raise admintool.ScriptError('IPA upgrade failed.', 1) > > > >2015-10-01T14:45:51Z DEBUG The ipa-ldap-updater command failed, exception: ScriptError: IPA upgrade failed. > >2015-10-01T14:45:51Z ERROR IPA upgrade failed. > >2015-10-01T14:45:51Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} > >2015-10-01T14:45:51Z DEBUG IPA version 4.1.0-18.el7.centos.4 > >2015-10-01T14:45:51Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > > > >... > > > >2015-10-01T14:48:37Z DEBUG The CA status is: running > >2015-10-01T14:48:37Z INFO The ipa-upgradeconfig command was successful > > > > > >But from looking through the ipaupgrade.log it seems like the schema changes were in fact applied? > > > > It looks like the DS has not been ready yet > > It started at: > > [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests > > But upgrade failed before: > > 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused > > > If there are no other errors listed, so other part of upgrade are > successful. > Pre-schema upgrade is done for DNS forward zones, but in case that this was > successfully done on master, dns forwardzones should be already updated. > This code is also removed in versions of IPA, so it should not cause issues > in future. Upgrading the 3rd replicate didn't fair so well either. I don't see any successful schema updates like I did in the previous 2 replicas in /var/log/ipaupgrade.log. Here's the errors from the 3rd replicate: 2015-10-01T17:20:06Z DEBUG duration: 0 seconds 2015-10-01T17:20:06Z DEBUG [5/10]: preparing server upgrade 2015-10-01T17:20:16Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused 2015-10-01T17:20:16Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-10-01T17:20:16Z DEBUG duration: 10 seconds 2015-10-01T17:20:16Z DEBUG [6/10]: updating schema 2015-10-01T17:20:27Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema fqdn=installutils.get_fqdn()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket raise e error: [Errno 111] Connection refused 2015-10-01T17:20:27Z DEBUG [error] error: [Errno 111] Connection refused 2015-10-01T17:20:27Z DEBUG [cleanup]: stopping directory server 2015-10-01T17:20:27Z DEBUG Starting external process 2015-10-01T17:20:27Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv at INT-CCR-BUFFALO-EDU.service' 2015-10-01T17:22:00Z DEBUG Process finished, return code=0 2015-10-01T17:22:00Z DEBUG [cleanup]: restoring configuration 2015-10-01T17:22:00Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-10-01T17:22:00Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-10-01T17:22:00Z DEBUG duration: 0 seconds 2015-10-01T17:22:00Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 144, in run upgrade.create_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 93, in create_instance show_service_name=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema fqdn=installutils.get_fqdn()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket raise e 2015-10-01T17:22:00Z DEBUG The ipa-ldap-updater command failed, exception: error: [Errno 111] Connection refused 2015-10-01T17:22:00Z ERROR [Errno 111] Connection refused 2015-10-01T17:22:01Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} 2015-10-01T17:22:01Z DEBUG IPA version 4.1.0-18.el7.centos.4 2015-10-01T17:22:01Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-10-01T17:22:01Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... 2015-10-01T17:22:01Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' Then these errors are repeated: 2015-10-01T17:22:05Z DEBUG stderr= 2015-10-01T17:22:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2015-10-01T17:22:09Z DEBUG Waiting until the CA is running 2015-10-01T17:22:09Z DEBUG request 'https://srv-d13-40-02.int.ccr.buffalo.edu:443/ca/admin/ca/getStatus' 2015-10-01T17:22:09Z DEBUG request body '' 2015-10-01T17:22:17Z DEBUG request status 500 2015-10-01T17:22:17Z DEBUG request reason_phrase u'Internal Server Error' 2015-10-01T17:22:17Z DEBUG request headers {'content-length': '2923', 'content-language': 'en', 'server': 'Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.16.2.3 Basic ECC mod_wsgi/3.4 Python/2.7.5', 'connection': 'close', 'date': 'Thu, 01 Oct 2015 17:22:09 GMT', 'content-type': 'text/html;charset=utf-8'} 2015-10-01T17:22:17Z DEBUG request body 'Apache Tomcat/7.0.54 - Error report

HTTP Status 500 - CS server is not ready to serve.

type Exception report

message CS server is not ready to serve.

description The server encountered an internal error that prevented it from fulfilling this request.

exception 

java.io.IOException: CS server is not ready to serve.\n\tcom.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)\n\tjavax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n\tsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)\n\tsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tjava.lang.reflect.Method.invoke(Method.java:606)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\tjavax.security.auth.Subject.doAsPrivileged(Subject.java:536)\n\torg.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)\n\torg.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\torg.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)\n\tsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)\n\tsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tjava.lang.reflect.Method.invoke(Method.java:606)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\tjavax.security.auth.Subject.doAsPrivileged(Subject.java:536)\n\torg.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)\n\torg.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)\n

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.54 logs.

Apache Tomcat/7.0.54

' 2015-10-01T17:22:17Z DEBUG The CA status is: check interrupted 2015-10-01T17:22:17Z DEBUG Waiting for CA to start... 2015-10-01T17:22:18Z DEBUG request 'https://srv-d13-40-02.int.ccr.buffalo.edu:443/ca/admin/ca/getStatus' 2015-10-01T17:22:18Z DEBUG request body '' 2015-10-01T17:22:18Z DEBUG request status 500 2015-10-01T17:22:18Z DEBUG request reason_phrase u'Internal Server Error' .... .... 2015-10-01T17:27:08Z DEBUG The CA status is: check interrupted 2015-10-01T17:27:08Z DEBUG Waiting for CA to start... 2015-10-01T17:27:09Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 1376, in main upgrade_pki(ca, fstore) File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ self.gen.next() File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 888, in stopped_service service_obj.start(instance_name) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 203, in start self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 197, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) 2015-10-01T17:27:09Z DEBUG The ipa-upgradeconfig command failed, exception: RuntimeError: CA did not start in 300.0s A few thoughts/concerns: 1. It looks like when the dirsrv is restarted as part of the upgrade it goes through thousands of iterations of: DSRetroclPlugin - delete_changerecord: could not delete change record 314605 (rc: 32) Before it finally becomes responsive and starts serving requests. This causes the ipa-upgrade to timeout. Should I have restarted the dirsrv first before performing the yum update? 2. I had (incorrectly?) assumed this to be a very minor upgrade from 4.1.0-18.el7.centos.3 to 4.1.0-18.el7.centos.4. Is there expected to be major schema upgrades in minor point releases like this? Curious what the schema updates do? 3. All servers have been rebooted and seem to be up and running. Should I be concerned about the upgrade failures and replicating dirty (old) data? How can I verify the upgrades when OK? Thanks again for all the help. --Andrew From rcritten at redhat.com Thu Oct 1 19:52:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Oct 2015 15:52:07 -0400 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <560D4BFA.2040303@mittwald.de> References: <560D4BFA.2040303@mittwald.de> Message-ID: <560D8EE7.8080004@redhat.com> Dominik Korittki wrote: > Hello folks, > > I am running two FreeIPA Servers with around 100 users and around 15.000 > hosts, which are used by users to login via ssh. The FreeIPA servers > (which are Centos 7.0) ran good for a while, but as more and more hosts > got migrated to serve as FreeIPA hosts, it started to get slow and > unstable. > > For example, its hard to maintain hostgroups, which have more than 1.000 > hosts. The ipa host-* commands are getting slower as the hostgroup > grows. Is this normal? You mean the ipa hostgroup-* commands? Whenever the entry is displayed (show and add) it needs to dereference all members so yes, it is understandable that it gets somewhat slower with more members. How slow are we talking about? > We also experience random dirsrv segfaults. Here's a dmesg line from the > latest: > > [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 > sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] You probably want to start here: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the > problem. > I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that > solve my problems? > > FreeIPA server version is 3.3.3-28.el7.centos > 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 > > > > Kind regards, > Dominik Korittki > From rmeggins at redhat.com Thu Oct 1 20:23:34 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 1 Oct 2015 14:23:34 -0600 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <560D8EE7.8080004@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> Message-ID: <560D9646.1020808@redhat.com> On 10/01/2015 01:52 PM, Rob Crittenden wrote: > Dominik Korittki wrote: >> Hello folks, >> >> I am running two FreeIPA Servers with around 100 users and around 15.000 >> hosts, which are used by users to login via ssh. The FreeIPA servers >> (which are Centos 7.0) ran good for a while, but as more and more hosts >> got migrated to serve as FreeIPA hosts, it started to get slow and >> unstable. >> >> For example, its hard to maintain hostgroups, which have more than 1.000 >> hosts. The ipa host-* commands are getting slower as the hostgroup >> grows. Is this normal? > You mean the ipa hostgroup-* commands? Whenever the entry is displayed > (show and add) it needs to dereference all members so yes, it is > understandable that it gets somewhat slower with more members. How slow > are we talking about? > >> We also experience random dirsrv segfaults. Here's a dmesg line from the >> latest: >> >> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 >> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] > You probably want to start here: > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > and debuginfo-install ipa-server slapi-nis in addition to the other packages >> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >> problem. >> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that >> solve my problems? >> >> FreeIPA server version is 3.3.3-28.el7.centos >> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >> >> >> >> Kind regards, >> Dominik Korittki >> From andrewm659 at yahoo.com Fri Oct 2 02:15:38 2015 From: andrewm659 at yahoo.com (Andrew Meyer) Date: Fri, 2 Oct 2015 02:15:38 +0000 (UTC) Subject: [Freeipa-users] FreeIPA install Message-ID: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> I just created a new FreeIPA setup at my home and i'm getting the following: [Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: INFO: *** PROCESS START *** [Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: INFO: *** PROCESS START *** [Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL Library Error: -12271 SSL client cannot verify your certificate [Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL Library Error: -12271 SSL client cannot verify your certificate I tried running the ipa-manage-cacert to generate a new one and install it.? But no go. Running CentOS 7.1 with latest updates.? Is there a bug in generating the SSL cert? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at mdevsys.com Fri Oct 2 04:38:58 2015 From: tk at mdevsys.com (TomK) Date: Fri, 2 Oct 2015 00:38:58 -0400 Subject: [Freeipa-users] HBAC In-Reply-To: <560D597E.7030205@redhat.com> References: <560B3A68.7020401@mdevsys.com> <560B3D73.9050704@mdevsys.com> <20150930055047.GG4539@redhat.com> <560BD190.7050401@redhat.com> <560C8AD1.5080105@mdevsys.com> <560D597E.7030205@redhat.com> Message-ID: <560E0A62.7020007@mdevsys.com> On 10/1/2015 12:04 PM, Simo Sorce wrote: > On 30/09/15 21:22, TomK wrote: >> >> >> On 9/30/2015 8:12 AM, Martin Kosek wrote: >>> On 09/30/2015 07:50 AM, Alexander Bokovoy wrote: >>>> On Tue, 29 Sep 2015, TomK wrote: >>>>> Hey Guy's, >>>>> >>>>> (Sending this again as I didn't have this email included in the >>>>> freeipa-users >>>>> mailing list so not sure if the other message will get posted.) >>>>> >>>>> Before I post a ticket to RH Support for an RFE, I'll post the >>>>> request here >>>>> to get some feedback on options and what ideas folks have. I've a >>>>> situation >>>>> as follows. I have the following setup in WS 2012 AD DC: >>>>> >>>>> TomK (user) >>>>> TomK Groups: >>>>> unixg >>>>> windowsg >>>>> >>>>> unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04' >>>>> windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09' >>>>> >>>>> TomK(user) also has the 'host' attribute defined as per the proper >>>>> RFC for >>>>> LDAP. With SSSD rules I can define the rules to read the user 'host' >>>>> attribute but not the group 'host' attribute: >>>>> >>>>> >>>>> |access_provider = ldap ldap_access_order = host >>>>> ldap_user_authorized_host = >>>>> host| >>>>> >>>>> >>>>> Essentially TomK to be given access to hosts listed in the 'host' >>>>> attribute >>>>> but denied entry into lab05 for example (not listed in any group >>>>> 'host' >>>>> attribute above) to the server. If I have a new user that has >>>>> joined that >>>>> particular team at our organization, I can simply add her/him to the >>>>> above >>>>> groups and this user would get access only to the listed servers in >>>>> 'host' >>>>> attribute by default. I don't need to specify new groups in >>>>> customized >>>>> sssd.conf or ldap.conf files or in sshd config files. Hence less to >>>>> update >>>>> with Salt or any other CM suite. I've managed to setup SUDO rules >>>>> and with >>>>> the openssh-ldap.diff schema SSH public keys could be stored in AD >>>>> as well >>>>> and be read by OpenSSH. So aside from the HBAC capability on groups, >>>>> virtually all our needs are handled by the WS2012 AD DC as it has to >>>>> follow >>>>> the OpenLDAP standard anyway. Now to get this we considered and are >>>>> still >>>>> considering FreeIPA. However this idea poses a set of challenges: >>>>> >>>>> 1) In large organizations where the AD support department are only >>>>> trained in >>>>> Windows AD setup and configuration (Only windows guy's) this would >>>>> require a >>>>> minimal of 3 bodies to support that know LDAP/Linux. This is a >>>>> large cost. >>>>> >>>>> 2) The additional server requires the same hardening as the Windows >>>>> AD DC >>>>> servers meaning a new procedure has to be carved out for the 2+ >>>>> FreeIPA >>>>> servers to be supported, hardened and maintained (upgraded). >>>>> >>>>> Now I probably sound somewhat anti-FreeIPA, however the challenges of >>>>> implementing it in large organizations surface after some >>>>> deliberation, so >>>>> probably better to list then as it may help direct development of >>>>> the product >>>>> to contend with the challenges (Like having a document fully >>>>> dedicated to >>>>> hardening a FreeIPA server with selinux and other technologies in >>>>> easy to >>>>> maintain configuration). I could be mistaken but some folks >>>>> mention that >>>>> it's 'better' to implement this sort of HBAC through other means (?? >>>>> iptables >>>>> ??) but never tried the alternatives yet. >>>>> >>>>> So, cutting to the end, would it be possible to add an attribute >>>>> like: >>>>> >>>>> |ldap_user_authorized_host| >>>>> >>>>> but perhaps called 'ldap_group_authorized_host' to the SSSD code to >>>>> enable >>>>> reading the 'host' attribute on AD/LDAP defined groups? >>>> In FreeIPA we support HBAC rules for AD users and groups. What exactly >>>> is wrong with that? >>>> >>>> See 'ipa help trust' for details how to map AD groups to IPA groups >>>> and >>>> then 'ipa help hbacrule' for how to limit access of those groups to >>>> specific hosts and services on them. >>>> >>>> This is all covered well in the guide: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html >>>> >>>> >>> More reading on External groups used for AD access control: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups >>> >>> >>> >>> I would also suggest a video with HBAC and Trust in action: >>> >>> https://www.youtube.com/watch?v=sQnNFJOzwa8 >>> >>> HTH, >>> Martin >> >> We already defined HBAC rules in the manner that all the links you >> pointed out indicate as an early implementation. As a product, there is >> no issue in IDM from that perspective. This is all great and the >> product is fine from that perspective. >> >> It would be good to have a dual option of either allowing SSSD or IDM / >> FreeIPA have full HBAC capability not just FreeIPA / IDM as in our >> organization that would be a huge cost savings vs implementing IDM as a >> separate Linux DC to be managed by a separate team. So for those >> customers that wish to go directly to AD or have already invested in AD >> can choose SSSD only (If MS bundles AD with certain purchases, for >> example, that is an actual cost savings for a company). Other customers >> who wish to keep the two separate so they do not flood AD DC's with non >> Windows AD settings can integrate IDM. >> >> There will be cases where there could be a potential to save on costs vs >> AD so the Linux IDM could be chosen as an Enterprise DC to which Windows >> server authenticate as well as Linux ones or vice versa, whereas those >> organizations already implementing Windows AD can have the option to >> have Linux servers connecting to the AD DC via SSSD. >> >> Since SSSD and IDM are so closely coupled, for someone who requires >> HBAC, the choice is either take both SSSD and IDM or neither. So other >> solutions are being explored instead. >> >> Do these reasons make sense as to why I posted the original ask? > > When SSSD is integrated directly in AD you can use Group Policies to > define access controls. See ad_gpo_access_control in sssd-ad(5) > > Simo. > > > This is one of the things we tried in AD to define on groups/users and use the ad_gpo_access_control but it was very cumbersome and to scale that to the number of groups and users we have it would make a much larger mess. Spent a bit of time with a few AD guy's to see if that would be doable but no. The reason for this is that if I have say 4000 groups, to deny access to all but 1 to a set of servers, I have to: 1) Specify to ALLOW for a group/user within that GPO policy. 2) Then specify 3999 times a DENY on all the other groups within that one policy. (I cannot specify an allow ahead of a deny like I can with iptables and the AD guy's didn't indicate any shortcuts with that. I can't do wild cards with GPO either nor can I specify ! or * and this makes it impossible to use for even small number of groups.) 3) Create an OU to then hold the systems that I want to give that one group access too. 4) Apply the GPO Policy to that OU. So this causes a much larger mess in AD, even if there were shortcuts, because: 1) I will now have to keep and maintain a huge list of OU's that hold host objects separately. AD teams will never go for that in large institutions. 2) I will also now have a huge list of GPO Policies to maintain as well. 3) Anytime I add a group, I then have to add it to the previous GPO Policies to restrict it's access to the rest of the hosts or users in that new group would get access in addition to adding a new host. And with such a large definition, it would become unsupportable and would cause a big mess where we do not need one. We also tried WMI that Microsoft suggested but that was no better and added another layer of complexity. IDM itself has wild cards and such which is convenient but again all the concerns come up with it with a large organization that I raised earlier. If such wildcard matches can be included in SSSD to read the 'host' attribute on a group, such as *mdm* that would make things even easier as I wouldn't have to keep adding new hosts in. With the host attribute on the user it's simple. If I don't specify any value for host, the user can't login anywhere. If I specify * he/she can login anywhere. If I specify a host list it restricts to that list. I can use ! as well. So much more practical and with REGEX added in, very powerfull. Hence the ask for reading the 'host' attribute. There's an libpam-python someone wrote that perhaps this could be achieved through that but that's more on the customization side so we would prefer to see an official feature add instead, if possible. This raises another question. Any thoughts about adding plugin mechanisms into SSSD? With that I could parse REGEX pressions in AD attributes and act on them. But I think that's more PAM then SSSD. Cheers, Tom From abokovoy at redhat.com Fri Oct 2 08:04:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 11:04:43 +0300 Subject: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI In-Reply-To: References: <20151001143311.GE4971@redhat.com> Message-ID: <20151002080443.GH4971@redhat.com> On Thu, 01 Oct 2015, Fujisan wrote: >I get this: > >----------------------------- >$ ldapsearch -D cn=directory\ manager -W -b cn=accounts,dc=mydomain >'(uid=user1*)' >Enter LDAP Password: ># extended LDIF ># ># LDAPv3 ># base with scope subtree ># filter: (uid=user1*) ># requesting: ALL ># > ># search result >search: 2 >result: 0 Success > ># numResponses: 1 >----------------------------- as it should be, i.e. no entry. Can you restart LDAP server? If compat tree entry persists after restart, it means there is indeed somewhere an entry that is turned into the compat one and we then can analyse it more. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 2 08:06:39 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 11:06:39 +0300 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <560D5A68.7070608@redhat.com> References: <560CDD7C.8090804@redhat.com> <560D5A68.7070608@redhat.com> Message-ID: <20151002080639.GI4971@redhat.com> On Thu, 01 Oct 2015, Simo Sorce wrote: >On 01/10/15 03:15, Petr Spacek wrote: >>On 30.9.2015 20:36, Matt Wells wrote: >>>Hi all, I hoped I may glean some brilliance from the group. >>>I have a Freeipa Server sitting atop a Fedora 21 server. The initial plan >>>was to replicate users+passwords with Windows 2012R2 server but following >>>some of the information in the other posts and docs we've moved to a >>>trust. The trust has been setup using the documentation and in short it's >>>worked without issue. I'm able to get principles from the Windows realm ( >>>marvel.comics.com). So what I'm attempting and failing to do is >>>authenticating my IPA users to the Windows 8 desktops. Ideally I don't >>>want any users in AD, it's simply there to deliver a GPO and in the next >>>year it will be phased out and we'll be replacing Windows 8 with linux >>>desktops. >>> >>>So >>>marvel.comics.com = windows >>>dc.comics.com = freeipa >>> >>># rpm -qi freeipa-server >>>Name : freeipa-server >>>Version : 4.1.4 >>>Release : 1.fc21 >>>Architecture: x86_64 >>>Install Date: Tue 25 Aug 2015 08:17:56 PM UTC >>>Group : System Environment/Base >>>Size : 4521059 >>>License : GPLv3+ >>>Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID >>>89ad4e8795a43f54 >>>Source RPM : freeipa-4.1.4-1.fc21.src.rpm >>>Build Date : Thu 26 Mar 2015 03:16:19 PM UTC >>>Build Host : buildhw-07.phx2.fedoraproject.org >>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a >>>Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17 >>>22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release >>>Fedora release 21 (Twenty One) >>> >>>To cut to the chase here's me logging into a Windows 8 desktop system. I >>>try to login 3 different ways; this system is a member of the marvel >>>domain. Time is extremely close, close enough that I feel really good >>>about ruling it out. Any light you all could shed on this would be >>>outstanding. Thank you all for your time on this, I really appreciate all >>>the time and effort this team puts into reading these posts. >>> >>>Username: dc/greenlantern >>>Password: ************ >>> >>>[root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i >>>greenlantern >>>[30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH >>>base="dc=dc,dc=comics,dc=com" scope=2 >>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink >>>objectClass" >>> >>>Username: greenlanter at dc >>>Password: ************ >>> >>> >>>[30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH >>>base="dc=dc,dc=comics,dc=com" scope=2 >>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink >>>objectClass" >>> >>> >>>Username: greenlanter at dc.comics.com >>>Password: ************ >>> >>>[30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH >>>base="dc=dc,dc=comics,dc=com" scope=2 >>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com >>>@DC.COMICS.COM >>>)(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM >>>)))" attrs="krbPrincipalName krbCanonicalName >>>ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference >>>krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >>>krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >>>krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData >>>krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >>>krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >>>ipaUserAuthType ipatokenRadiusConfigLink objectClass" >>> >>> >>>>From what I can tell, everything looks good to wbinfo; we see the domain >>>and he see's us. In the AD trust I can go under the trust and validate the >>>trust with no issues. >>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status >>>BUILTIN : online >>>DC : online >>>MARVEL : online >>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>marvel.comics.com >>>Name : MARVEL >>>Alt_Name : marvel.comics.com >>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>Active Directory : Yes >>>Native : Yes >>>Primary : No >>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n >>>'MARVEL.COMICS.COM\Domain >>>Admins' >>>S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) >>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>marvel.comics.com >>>Name : MARVEL >>>Alt_Name : marvel.comics.com >>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>Active Directory : Yes >>>Native : Yes >>>Primary : No >> >>Unfortunately you will not be able to log into Windows workstations using IPA >>users because FreeIPA is (at the moment) missing Global Catalog component >>which prevents Windows from working with IPA users. >> >>It should work the other way around, but there is nothing you can do at the >>moment to make it working with IPA users in Windows. Global Catalog is several >>months away in the best case. > >This is not entirely true. >There is no way to add IPA SIDs to the relevant authorization groups >using the GUI tools in AD, but technically you can do that using >command line tools and pasting in SIDs directly. >Authentication would be possible then, however Windows clients will >never be able to resolve SID to Names, so looking at file permissions >you will not be able to see user names, but only SIDs for IPA users. >Some tools that may depend on SID->Name translation may also fail in >unexpected ways. practically, you will not be able to login into Windows workstations because login screen will have to do Name->SID translation which it wouldn't be able to do. >This is why we do not recommend to try this, but it is technically >possible if you know very well how to handle everything through >Windows CLIs (I don't so don't ask :-) It will not work for Name->SID translations, thus making it practially unusable. -- / Alexander Bokovoy From mkosek at redhat.com Fri Oct 2 08:09:23 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 2 Oct 2015 10:09:23 +0200 Subject: [Freeipa-users] FreeIPA install In-Reply-To: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> References: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> Message-ID: <560E3BB3.5070103@redhat.com> On 10/02/2015 04:15 AM, Andrew Meyer wrote: > I just created a new FreeIPA setup at my home and i'm getting the following: > > [Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] AH00094: Command > line: '/usr/sbin/httpd -D FOREGROUND' > [Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL Library Error: > -12271 SSL client cannot verify your certificate > [Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL Library Error: > -12271 SSL client cannot verify your certificate > > I tried running the ipa-manage-cacert to generate a new one and install it. > But no go. > > Running CentOS 7.1 with latest updates. Is there a bug in generating the SSL cert? > > > This rather seems that your client browser does not trust FreeIPA CA certificate. Related thread: https://www.redhat.com/archives/freeipa-devel/2009-June/msg00188.html More related info: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/using-the-ui.html#config-browser Martin From fujisan43 at gmail.com Fri Oct 2 08:35:15 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 10:35:15 +0200 Subject: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI In-Reply-To: <20151002080443.GH4971@redhat.com> References: <20151001143311.GE4971@redhat.com> <20151002080443.GH4971@redhat.com> Message-ID: Yep! Rebooting is just what I needed. It just cleaned LDAP from user1. I could create 'user1' again within the FreeIPA web UI. $ ldapsearch -x -h ipasrv uid=user1 # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=user1 # requesting: ALL # # user1, users, compat, mydomain dn: uid=user1,cn=users,cn=compat,dc=mydomain cn: user one objectClass: posixAccount objectClass: top gidNumber: 1034 gecos: user one uidNumber: 1034 loginShell: /bin/bash homeDirectory: /home/user1 uid: user1 # user1, users, accounts, mydomain dn: uid=user1,cn=users,cn=accounts,dc=mydomain displayName: user one cn: user one objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry objectClass: ipantuserattrs loginShell: /bin/bash initials: uo gecos: user one homeDirectory: /home/user1 uid: user1 givenName: user sn: one uidNumber: 1034 gidNumber: 1034 ipaNTSecurityIdentifier: S-1-5-21-1490379376-134147230-3409394544-1034 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 And after deleting it again: $ ldapsearch -x -h ipasrv uid=user1 # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=user1 # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I probably messed around a bit while configuring with IPA. Thank you. On Fri, Oct 2, 2015 at 10:04 AM, Alexander Bokovoy wrote: > On Thu, 01 Oct 2015, Fujisan wrote: > >> I get this: >> >> ----------------------------- >> $ ldapsearch -D cn=directory\ manager -W -b cn=accounts,dc=mydomain >> '(uid=user1*)' >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=user1*) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> ----------------------------- >> > as it should be, i.e. no entry. > > Can you restart LDAP server? If compat tree entry persists after > restart, it means there is indeed somewhere an entry that is turned into > the compat one and we then can analyse it more. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 2 10:28:56 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 12:28:56 +0200 Subject: [Freeipa-users] ipa upgrade failed In-Reply-To: <20151001175011.GD10653@dead.ccr.buffalo.edu> References: <20151001150309.GA10653@dead.ccr.buffalo.edu> <560D4CA3.8080609@redhat.com> <20151001152835.GB10653@dead.ccr.buffalo.edu> <560D53F2.5@redhat.com> <20151001175011.GD10653@dead.ccr.buffalo.edu> Message-ID: <560E5C68.7080504@redhat.com> On 10/01/2015 07:50 PM, Andrew E. Bruno wrote: > On Thu, Oct 01, 2015 at 05:40:34PM +0200, Martin Basti wrote: >> >> On 10/01/2015 05:28 PM, Andrew E. Bruno wrote: >>> On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote: >>>> On 10/01/2015 05:03 PM, Andrew E. Bruno wrote: >>>>> Running CentOS 7.1.1503. >>>>> >>>>> Upgrading via yum update from: >>>>> >>>>> ipa-server.x86_64 0:4.1.0-18.el7.centos.3 >>>>> >>>>> --to-- >>>>> >>>>> ipa-server.x86_64 0:4.1.0-18.el7.centos.4 >>>>> >>>>> We have 3 replicates. Upgrading the first replicate (first-master) went >>>>> fine. Upgrading the second replicate failed. >>>>> >>>>> Got the following error during the update on the second replicate: >>>>> >>>>> Pre schema upgrade failed with [Errno 111] Connection refused >>>>> IPA upgrade failed. >>>>> >>>>> Where should I look for more info? Looked in the usual places and didn't >>>>> see anything out of the ordinary. How can I fix/verify the upgrade? >>>>> >>>>> Thanks! >>>>> >>>>> --Andrew >>>>> >>>> Hello, >>>> >>>> can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for >>>> more specific errors? >>> Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time of the upgrade: >>> >>> [01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation threads - op stack size 84 max work q size 59 max work q stack size 59 >>> [01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled >>> [01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting up >>> [01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B is less than db size 28639232B; We recommend to increase the entry cache size nsslapd-cachememsize. >>> [01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. >>> ... >>> tion. >>> [01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 >>> [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema; NSPR error - -5943 >>> [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated >>> [01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/srv-d13-39-02.int.ccr.buffalo.edu at INT.CCR.BUFFALO.EDU] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) >>> [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" (srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to go into backoff mode. Will retry later. >>> [01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated >>> [01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) >>> ... >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22231 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22232 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22233 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22234 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22235 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22236 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22237 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22238 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22239 (rc: 32) >>> [01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not delete change record 22240 (rc: 32) >>> .. >>> >>> >>> These delete_changerecord are repeated all the way to 321722. >>> >>> >>> Here's the errors from /var/log/ipaupgrade.log >>> >>> >>> 2015-10-01T14:44:49Z DEBUG [4/10]: starting directory server >>> 2015-10-01T14:44:49Z DEBUG Starting external process >>> 2015-10-01T14:44:49Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' >>> 2015-10-01T14:44:50Z DEBUG Process finished, return code=0 >>> 2015-10-01T14:44:50Z DEBUG stdout= >>> 2015-10-01T14:44:50Z DEBUG stderr= >>> 2015-10-01T14:44:50Z DEBUG duration: 0 seconds >>> 2015-10-01T14:44:50Z DEBUG [5/10]: preparing server upgrade >>> 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused >>> 2015-10-01T14:45:00Z DEBUG Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade >>> ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ >>> self.create_connection() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection >>> dm_password=self.dm_password, pw_name=self.pw_name) >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect >>> conn.do_external_bind(pw_name) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind >>> self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection >>> wait_for_open_socket(lurl.hostport, timeout) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket >>> raise e >>> error: [Errno 111] Connection refused >>> >>> 2015-10-01T14:45:00Z DEBUG duration: 10 seconds >>> 2015-10-01T14:45:00Z DEBUG [6/10]: updating schema >>> >>> ... >>> >>> 2015-10-01T14:45:43Z DEBUG duration: 2 seconds >>> 2015-10-01T14:45:43Z DEBUG [9/10]: restoring configuration >>> 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-10-01T14:45:43Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-10-01T14:45:43Z DEBUG duration: 0 seconds >>> 2015-10-01T14:45:43Z DEBUG [10/10]: starting directory server >>> 2015-10-01T14:45:43Z DEBUG Starting external process >>> 2015-10-01T14:45:43Z DEBUG args='/bin/systemctl' 'start' 'dirsrv at INT-CCR-BUFFALO-EDU.service' >>> 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 >>> 2015-10-01T14:45:44Z DEBUG stdout= >>> 2015-10-01T14:45:44Z DEBUG stderr= >>> 2015-10-01T14:45:44Z DEBUG Starting external process >>> 2015-10-01T14:45:44Z DEBUG args='/bin/systemctl' 'is-active' 'dirsrv at INT-CCR-BUFFALO-EDU.service' >>> 2015-10-01T14:45:44Z DEBUG Process finished, return code=0 >>> 2015-10-01T14:45:44Z DEBUG stdout=active >>> >>> 2015-10-01T14:45:44Z DEBUG stderr= >>> 2015-10-01T14:45:44Z DEBUG wait_for_open_ports: localhost [389] timeout 300 >>> 2015-10-01T14:45:51Z DEBUG duration: 7 seconds >>> 2015-10-01T14:45:51Z DEBUG Done. >>> 2015-10-01T14:45:51Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute >>> return_value = self.run() >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 151, in run >>> raise admintool.ScriptError('IPA upgrade failed.', 1) >>> >>> 2015-10-01T14:45:51Z DEBUG The ipa-ldap-updater command failed, exception: ScriptError: IPA upgrade failed. >>> 2015-10-01T14:45:51Z ERROR IPA upgrade failed. >>> 2015-10-01T14:45:51Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} >>> 2015-10-01T14:45:51Z DEBUG IPA version 4.1.0-18.el7.centos.4 >>> 2015-10-01T14:45:51Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' >>> >>> ... >>> >>> 2015-10-01T14:48:37Z DEBUG The CA status is: running >>> 2015-10-01T14:48:37Z INFO The ipa-upgradeconfig command was successful >>> >>> >>> But from looking through the ipaupgrade.log it seems like the schema changes were in fact applied? >>> >> It looks like the DS has not been ready yet >> >> It started at: >> >> [01/Oct/2015:10:45:09 -0400] - slapd started. Listening on /var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests >> >> But upgrade failed before: >> >> 2015-10-01T14:45:00Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused >> >> >> If there are no other errors listed, so other part of upgrade are >> successful. >> Pre-schema upgrade is done for DNS forward zones, but in case that this was >> successfully done on master, dns forwardzones should be already updated. >> This code is also removed in versions of IPA, so it should not cause issues >> in future. > Upgrading the 3rd replicate didn't fair so well either. I don't see any > successful schema updates like I did in the previous 2 replicas in > /var/log/ipaupgrade.log. Here's the errors from the 3rd replicate: > > > 2015-10-01T17:20:06Z DEBUG duration: 0 seconds > 2015-10-01T17:20:06Z DEBUG [5/10]: preparing server upgrade > 2015-10-01T17:20:16Z ERROR Pre schema upgrade failed with [Errno 111] Connection refused > 2015-10-01T17:20:16Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade > ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ > self.create_connection() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection > dm_password=self.dm_password, pw_name=self.pw_name) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect > conn.do_external_bind(pw_name) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > > 2015-10-01T17:20:16Z DEBUG duration: 10 seconds > 2015-10-01T17:20:16Z DEBUG [6/10]: updating schema > 2015-10-01T17:20:27Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema > dm_password='', ldapi=True, live_run=self.live_run) or self.modified > File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema > fqdn=installutils.get_fqdn()) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect > conn.do_external_bind(pw_name) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket > raise e > error: [Errno 111] Connection refused > > 2015-10-01T17:20:27Z DEBUG [error] error: [Errno 111] Connection refused > 2015-10-01T17:20:27Z DEBUG [cleanup]: stopping directory server > 2015-10-01T17:20:27Z DEBUG Starting external process > 2015-10-01T17:20:27Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv at INT-CCR-BUFFALO-EDU.service' > 2015-10-01T17:22:00Z DEBUG Process finished, return code=0 > > > > 2015-10-01T17:22:00Z DEBUG [cleanup]: restoring configuration > 2015-10-01T17:22:00Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-10-01T17:22:00Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-10-01T17:22:00Z DEBUG duration: 0 seconds > 2015-10-01T17:22:00Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute > return_value = self.run() > File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py", line 144, in run > upgrade.create_instance() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 93, in create_instance > show_service_name=False) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step > method() > File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema > dm_password='', ldapi=True, live_run=self.live_run) or self.modified > File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema > fqdn=installutils.get_fqdn()) > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect > conn.do_external_bind(pw_name) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket > raise e > > 2015-10-01T17:22:00Z DEBUG The ipa-ldap-updater command failed, exception: error: [Errno 111] Connection refused > 2015-10-01T17:22:00Z ERROR [Errno 111] Connection refused > 2015-10-01T17:22:01Z DEBUG /usr/sbin/ipa-upgradeconfig was invoked with options: {'debug': False, 'quiet': True} > 2015-10-01T17:22:01Z DEBUG IPA version 4.1.0-18.el7.centos.4 > 2015-10-01T17:22:01Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-10-01T17:22:01Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... > 2015-10-01T17:22:01Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > > > Then these errors are repeated: > > 2015-10-01T17:22:05Z DEBUG stderr= > 2015-10-01T17:22:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 > 2015-10-01T17:22:09Z DEBUG Waiting until the CA is running > 2015-10-01T17:22:09Z DEBUG request 'https://srv-d13-40-02.int.ccr.buffalo.edu:443/ca/admin/ca/getStatus' > 2015-10-01T17:22:09Z DEBUG request body '' > 2015-10-01T17:22:17Z DEBUG request status 500 > 2015-10-01T17:22:17Z DEBUG request reason_phrase u'Internal Server Error' > 2015-10-01T17:22:17Z DEBUG request headers {'content-length': '2923', 'content-language': 'en', 'server': 'Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.16.2.3 Basic ECC mod_wsgi/3.4 Python/2.7.5', 'connection': 'close', 'date': 'Thu, 01 Oct 2015 17:22:09 GMT', 'content-type': 'text/html;charset=utf-8'} > 2015-10-01T17:22:17Z DEBUG request body 'Apache Tomcat/7.0.54 - Error report

HTTP Status 500 - CS server is not ready to serve.

type Exception report

message CS server is not ready to serve.

description The server encountered an internal error that prevented it from fulfilling this request.

exception 

java.io.IOException: CS server is not ready to serve.\n\tcom.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)\n\tjavax.servlet.http.HttpServlet.service(HttpServlet.java:727)\n\tsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)\n\tsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tjava.lang.reflect.Method.invoke(Method.java:606)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\tjavax.security.auth.Subject.doAsPrivileged(Subject.java:536)\n\torg.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)\n\torg.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\torg.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)\n\tsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)\n\tsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tjava.lang.reflect.Method.invoke(Method.java:606)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)\n\torg.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)\n\tjava.security.AccessController.doPrivileged(Native Method)\n\tjavax.security.auth.Subject.doAsPrivileged(Subject.java:536)\n\torg.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)\n\torg.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)\n

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.54 logs.

Apache Tomcat/7.0.54

' > 2015-10-01T17:22:17Z DEBUG The CA status is: check interrupted > 2015-10-01T17:22:17Z DEBUG Waiting for CA to start... > 2015-10-01T17:22:18Z DEBUG request 'https://srv-d13-40-02.int.ccr.buffalo.edu:443/ca/admin/ca/getStatus' > 2015-10-01T17:22:18Z DEBUG request body '' > 2015-10-01T17:22:18Z DEBUG request status 500 > 2015-10-01T17:22:18Z DEBUG request reason_phrase u'Internal Server Error' > .... > .... > > 2015-10-01T17:27:08Z DEBUG The CA status is: check interrupted > 2015-10-01T17:27:08Z DEBUG Waiting for CA to start... > 2015-10-01T17:27:09Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-upgradeconfig", line 1376, in main > upgrade_pki(ca, fstore) > > File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ > self.gen.next() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 888, in stopped_service > service_obj.start(instance_name) > > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 203, in start > self.wait_until_running() > > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 197, in wait_until_running > raise RuntimeError('CA did not start in %ss' % timeout) > > 2015-10-01T17:27:09Z DEBUG The ipa-upgradeconfig command failed, exception: RuntimeError: CA did not start in 300.0s This is interesting, can you check logs in /var/log/pki/pki-tomcat/ca/debug > > > A few thoughts/concerns: > > 1. It looks like when the dirsrv is restarted as part of the upgrade it goes > through thousands of iterations of: > > DSRetroclPlugin - delete_changerecord: could not delete change record 314605 (rc: 32) > > Before it finally becomes responsive and starts serving requests. This causes > the ipa-upgrade to timeout. Should I have restarted the dirsrv first before > performing the yum update? You can try, but I'm not sure if this will help. > > 2. I had (incorrectly?) assumed this to be a very minor upgrade from > 4.1.0-18.el7.centos.3 to 4.1.0-18.el7.centos.4. Is there expected to be major > schema upgrades in minor point releases like this? Curious what the schema > updates do? It is minor upgrade, it contains just one fix which does not require upgrade of LDAP data. Schema upgrade checks if schema is up to date. Schema is replicated, so if update on master was successful, schema is also updated on replicas too. > > 3. All servers have been rebooted and seem to be up and running. Should I be > concerned about the upgrade failures and replicating dirty (old) data? How can > I verify the upgrades when OK? You can try manually run ipa-ldap-updater --upgrade after yum upgrade. Upgrade is idempotent, it should work. But as I said before, it should work even if upgrade failed, because the fix in minor version does not require schema/data upgrade. > > Thanks again for all the help. > > --Andrew > Martin From fujisan43 at gmail.com Fri Oct 2 12:26:50 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 14:26:50 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore Message-ID: Hello, I cannot login to the web UI anymore. The password or username you entered is incorrect. Log says: Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, Additional pre-authentication required Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, Decrypt integrity check failed Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 I have no idea what went wrong. What can I do? ?Regards, Fuji? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Fri Oct 2 12:52:25 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 14:52:25 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: Message-ID: More info: I can initiate a ticket: $ kdestroy $ kinit admin but cannot view user admin: $ ipa user-show admin ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized $ 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-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful /var/log/messages: Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection. On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: > Hello, > > I cannot login to the web UI anymore. > > The password or username you entered is incorrect. > > Log says: > > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 > 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA > for krbtgt/OPERA at OPERA, Additional pre-authentication required > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth > (encrypted_timestamp) verify failure: Decrypt integrity check failed > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 > 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: HTTP/zaira2.opera at OPERA > for krbtgt/OPERA at OPERA, Decrypt integrity check failed > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 > > > I have no idea what went wrong. > > What can I do? > > ?Regards, > Fuji? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.zoske at euroimmun.de Fri Oct 2 06:35:41 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Fri, 2 Oct 2015 06:35:41 +0000 Subject: [Freeipa-users] SUDO does not always works on first try Message-ID: Hi folks, we recently setup an IPA-Server on Centos 7.1 and connected some Ubuntu 14.04 LTS machines to this server. The IPA-Realm is just for configuring the clients, such as HBAC and SUDO. The user information are stored in an AD to which we established a two-way trust. Our problem is now, that sudo sometimes tells us, that a user is not allowed to run SUDO on that machine. But on the second try he can execute the command which failed the first time. Any ideas, whats wrong? Best regards, Fabian Zoske -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Oct 2 13:05:08 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 2 Oct 2015 15:05:08 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: Message-ID: <20151002130508.GA3127@hendrix.redhat.com> On Fri, Oct 02, 2015 at 06:35:41AM +0000, Zoske, Fabian wrote: > Hi folks, > > we recently setup an IPA-Server on Centos 7.1 and connected some Ubuntu 14.04 LTS machines to this server. > The IPA-Realm is just for configuring the clients, such as HBAC and SUDO. The user information are stored in an AD to which we established a two-way trust. > > Our problem is now, that sudo sometimes tells us, that a user is not allowed to run SUDO on that machine. But on the second try he can execute the command which failed the first time. > > Any ideas, whats wrong? Not without logs, sorry. We need both from sudo itself and SSSD. But the closes that comes to mind is: https://bugzilla.redhat.com/show_bug.cgi?id=1247539 From simo at redhat.com Fri Oct 2 13:18:26 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 2 Oct 2015 09:18:26 -0400 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <20151002080639.GI4971@redhat.com> References: <560CDD7C.8090804@redhat.com> <560D5A68.7070608@redhat.com> <20151002080639.GI4971@redhat.com> Message-ID: <560E8422.60709@redhat.com> On 02/10/15 04:06, Alexander Bokovoy wrote: > On Thu, 01 Oct 2015, Simo Sorce wrote: >> On 01/10/15 03:15, Petr Spacek wrote: >>> On 30.9.2015 20:36, Matt Wells wrote: >>>> Hi all, I hoped I may glean some brilliance from the group. >>>> I have a Freeipa Server sitting atop a Fedora 21 server. The >>>> initial plan >>>> was to replicate users+passwords with Windows 2012R2 server but >>>> following >>>> some of the information in the other posts and docs we've moved to a >>>> trust. The trust has been setup using the documentation and in >>>> short it's >>>> worked without issue. I'm able to get principles from the Windows >>>> realm ( >>>> marvel.comics.com). So what I'm attempting and failing to do is >>>> authenticating my IPA users to the Windows 8 desktops. Ideally I don't >>>> want any users in AD, it's simply there to deliver a GPO and in the >>>> next >>>> year it will be phased out and we'll be replacing Windows 8 with linux >>>> desktops. >>>> >>>> So >>>> marvel.comics.com = windows >>>> dc.comics.com = freeipa >>>> >>>> # rpm -qi freeipa-server >>>> Name : freeipa-server >>>> Version : 4.1.4 >>>> Release : 1.fc21 >>>> Architecture: x86_64 >>>> Install Date: Tue 25 Aug 2015 08:17:56 PM UTC >>>> Group : System Environment/Base >>>> Size : 4521059 >>>> License : GPLv3+ >>>> Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID >>>> 89ad4e8795a43f54 >>>> Source RPM : freeipa-4.1.4-1.fc21.src.rpm >>>> Build Date : Thu 26 Mar 2015 03:16:19 PM UTC >>>> Build Host : buildhw-07.phx2.fedoraproject.org >>>> [root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a >>>> Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon >>>> Aug 17 >>>> 22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> [root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release >>>> Fedora release 21 (Twenty One) >>>> >>>> To cut to the chase here's me logging into a Windows 8 desktop >>>> system. I >>>> try to login 3 different ways; this system is a member of the marvel >>>> domain. Time is extremely close, close enough that I feel really good >>>> about ruling it out. Any light you all could shed on this would be >>>> outstanding. Thank you all for your time on this, I really >>>> appreciate all >>>> the time and effort this team puts into reading these posts. >>>> >>>> Username: dc/greenlantern >>>> Password: ************ >>>> >>>> [root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i >>>> greenlantern >>>> [30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH >>>> base="dc=dc,dc=comics,dc=com" scope=2 >>>> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>> >>>> )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>> passwordHistory ipaKrbAuthzData ipaUserAuthType >>>> ipatokenRadiusConfigLink >>>> objectClass" >>>> >>>> Username: greenlanter at dc >>>> Password: ************ >>>> >>>> >>>> [30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH >>>> base="dc=dc,dc=comics,dc=com" scope=2 >>>> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>> >>>> )(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>> passwordHistory ipaKrbAuthzData ipaUserAuthType >>>> ipatokenRadiusConfigLink >>>> objectClass" >>>> >>>> >>>> Username: greenlanter at dc.comics.com >>>> Password: ************ >>>> >>>> [30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH >>>> base="dc=dc,dc=comics,dc=com" scope=2 >>>> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com >>>> >>>> @DC.COMICS.COM >>>> )(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM >>>> )))" attrs="krbPrincipalName krbCanonicalName >>>> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>> krbTicketPolicyReference >>>> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >>>> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >>>> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >>>> krbExtraData >>>> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >>>> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >>>> ipaUserAuthType ipatokenRadiusConfigLink objectClass" >>>> >>>> >>>>> From what I can tell, everything looks good to wbinfo; we see the >>>>> domain >>>> and he see's us. In the AD trust I can go under the trust and >>>> validate the >>>> trust with no issues. >>>> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status >>>> BUILTIN : online >>>> DC : online >>>> MARVEL : online >>>> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>> marvel.comics.com >>>> Name : MARVEL >>>> Alt_Name : marvel.comics.com >>>> SID : S-1-5-21-3495301974-2766379234-3984916731 >>>> Active Directory : Yes >>>> Native : Yes >>>> Primary : No >>>> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n >>>> 'MARVEL.COMICS.COM\Domain >>>> Admins' >>>> S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) >>>> [root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>> marvel.comics.com >>>> Name : MARVEL >>>> Alt_Name : marvel.comics.com >>>> SID : S-1-5-21-3495301974-2766379234-3984916731 >>>> Active Directory : Yes >>>> Native : Yes >>>> Primary : No >>> >>> Unfortunately you will not be able to log into Windows workstations >>> using IPA >>> users because FreeIPA is (at the moment) missing Global Catalog >>> component >>> which prevents Windows from working with IPA users. >>> >>> It should work the other way around, but there is nothing you can do >>> at the >>> moment to make it working with IPA users in Windows. Global Catalog >>> is several >>> months away in the best case. >> >> This is not entirely true. >> There is no way to add IPA SIDs to the relevant authorization groups >> using the GUI tools in AD, but technically you can do that using >> command line tools and pasting in SIDs directly. >> Authentication would be possible then, however Windows clients will >> never be able to resolve SID to Names, so looking at file permissions >> you will not be able to see user names, but only SIDs for IPA users. >> Some tools that may depend on SID->Name translation may also fail in >> unexpected ways. > practically, you will not be able to login into Windows workstations > because login screen will have to do Name->SID translation which it > wouldn't be able to do. I do not think this is really true, I tested a while back that the PAC is used for Name -> SID of the logging in user, but I do not know if all versions of Windows will work flawlessly this way. >> This is why we do not recommend to try this, but it is technically >> possible if you know very well how to handle everything through >> Windows CLIs (I don't so don't ask :-) > It will not work for Name->SID translations, thus making it practially > unusable. It really depends on what you are doing, but I agree it will have issues, therefore we do not recommend it. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbabinsk at redhat.com Fri Oct 2 13:27:03 2015 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 2 Oct 2015 15:27:03 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: Message-ID: <560E8627.2030404@redhat.com> On 10/02/2015 02:52 PM, Fujisan wrote: > More info: > > I can initiate a ticket: > $ kdestroy > $ kinit admin > > but cannot view user admin: > $ ipa user-show admin > ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized > > $ 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-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > /var/log/messages: > Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize > credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity > check failed. Unable to create GSSAPI-encrypted LDAP connection. > > > > On Fri, Oct 2, 2015 at 2:26 PM, Fujisan > wrote: > > Hello, > > I cannot login to the web UI anymore. > > The password or username you entered is incorrect. > > Log says: > > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes > {18 17 16 23 25 26 1 3 2}) 10.0.21.18 : > NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, > Additional pre-authentication required > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth > (encrypted_timestamp) verify failure: Decrypt integrity check failed > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes > {18 17 16 23 25 26 1 3 2}) 10.0.21.18 : > PREAUTH_FAILED: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, > Decrypt integrity check failed > Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 > > > I have no idea what went wrong. > > What can I do? > > ?Regards, > Fuji? > > > > What version of FreeIPA are you running? -- Martin^3 Babinsky From fujisan43 at gmail.com Fri Oct 2 13:33:58 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 15:33:58 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <560E8627.2030404@redhat.com> References: <560E8627.2030404@redhat.com> Message-ID: Sorry. I'm running the latest one, 4.1.4. On Fri, Oct 2, 2015 at 3:27 PM, Martin Babinsky wrote: > On 10/02/2015 02:52 PM, Fujisan wrote: > >> More info: >> >> I can initiate a ticket: >> $ kdestroy >> $ kinit admin >> >> but cannot view user admin: >> $ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> >> $ 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-dnskeysyncd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> /var/log/messages: >> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >> check failed. Unable to create GSSAPI-encrypted LDAP connection. >> >> >> >> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan > > wrote: >> >> Hello, >> >> I cannot login to the web UI anymore. >> >> The password or username you entered is incorrect. >> >> Log says: >> >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >> {18 17 16 23 25 26 1 3 2}) 10.0.21.18 : >> NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, >> Additional pre-authentication required >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >> (encrypted_timestamp) verify failure: Decrypt integrity check failed >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >> {18 17 16 23 25 26 1 3 2}) 10.0.21.18 : >> PREAUTH_FAILED: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, >> Decrypt integrity check failed >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >> >> >> I have no idea what went wrong. >> >> What can I do? >> >> ?Regards, >> Fuji? >> >> >> >> >> What version of FreeIPA are you running? > > -- > Martin^3 Babinsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewm659 at yahoo.com Fri Oct 2 13:29:33 2015 From: andrewm659 at yahoo.com (Andrew Meyer) Date: Fri, 2 Oct 2015 13:29:33 +0000 (UTC) Subject: [Freeipa-users] FreeIPA install In-Reply-To: <560E3BB3.5070103@redhat.com> References: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> <560E3BB3.5070103@redhat.com> Message-ID: <135413725.253302.1443792573727.JavaMail.yahoo@mail.yahoo.com> I tried to clear them out of the preferences. ?No go.Still getting this: Secure Connection Failed An error occurred during a connection to asm-dns01.borg.local. You have received an invalid certificate. Please contact the server administrator or email correspondent and give them the following information: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial) ? ? The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.? ? Please contact the website owners to inform them of this problem. On Friday, October 2, 2015 3:09 AM, Martin Kosek wrote: On 10/02/2015 04:15 AM, Andrew Meyer wrote: > I just created a new FreeIPA setup at my home and i'm getting the following: > > [Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] AH00094: Command > line: '/usr/sbin/httpd -D FOREGROUND' > [Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL Library Error: > -12271 SSL client cannot verify your certificate > [Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL Library Error: > -12271 SSL client cannot verify your certificate > > I tried running the ipa-manage-cacert to generate a new one and install it. > But no go. > > Running CentOS 7.1 with latest updates.? Is there a bug in generating the SSL cert? > > > This rather seems that your client browser does not trust FreeIPA CA certificate. Related thread: https://www.redhat.com/archives/freeipa-devel/2009-June/msg00188.html More related info: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/using-the-ui.html#config-browser Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 2 13:43:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 16:43:00 +0300 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <560E8422.60709@redhat.com> References: <560CDD7C.8090804@redhat.com> <560D5A68.7070608@redhat.com> <20151002080639.GI4971@redhat.com> <560E8422.60709@redhat.com> Message-ID: <20151002134300.GA5035@redhat.com> On Fri, 02 Oct 2015, Simo Sorce wrote: >On 02/10/15 04:06, Alexander Bokovoy wrote: >>On Thu, 01 Oct 2015, Simo Sorce wrote: >>>On 01/10/15 03:15, Petr Spacek wrote: >>>>On 30.9.2015 20:36, Matt Wells wrote: >>>>>Hi all, I hoped I may glean some brilliance from the group. >>>>>I have a Freeipa Server sitting atop a Fedora 21 server. The >>>>>initial plan >>>>>was to replicate users+passwords with Windows 2012R2 server but >>>>>following >>>>>some of the information in the other posts and docs we've moved to a >>>>>trust. The trust has been setup using the documentation and in >>>>>short it's >>>>>worked without issue. I'm able to get principles from the Windows >>>>>realm ( >>>>>marvel.comics.com). So what I'm attempting and failing to do is >>>>>authenticating my IPA users to the Windows 8 desktops. Ideally I don't >>>>>want any users in AD, it's simply there to deliver a GPO and in the >>>>>next >>>>>year it will be phased out and we'll be replacing Windows 8 with linux >>>>>desktops. >>>>> >>>>>So >>>>>marvel.comics.com = windows >>>>>dc.comics.com = freeipa >>>>> >>>>># rpm -qi freeipa-server >>>>>Name : freeipa-server >>>>>Version : 4.1.4 >>>>>Release : 1.fc21 >>>>>Architecture: x86_64 >>>>>Install Date: Tue 25 Aug 2015 08:17:56 PM UTC >>>>>Group : System Environment/Base >>>>>Size : 4521059 >>>>>License : GPLv3+ >>>>>Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID >>>>>89ad4e8795a43f54 >>>>>Source RPM : freeipa-4.1.4-1.fc21.src.rpm >>>>>Build Date : Thu 26 Mar 2015 03:16:19 PM UTC >>>>>Build Host : buildhw-07.phx2.fedoraproject.org >>>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a >>>>>Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon >>>>>Aug 17 >>>>>22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release >>>>>Fedora release 21 (Twenty One) >>>>> >>>>>To cut to the chase here's me logging into a Windows 8 desktop >>>>>system. I >>>>>try to login 3 different ways; this system is a member of the marvel >>>>>domain. Time is extremely close, close enough that I feel really good >>>>>about ruling it out. Any light you all could shed on this would be >>>>>outstanding. Thank you all for your time on this, I really >>>>>appreciate all >>>>>the time and effort this team puts into reading these posts. >>>>> >>>>>Username: dc/greenlantern >>>>>Password: ************ >>>>> >>>>>[root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i >>>>>greenlantern >>>>>[30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>>> >>>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>>>passwordHistory ipaKrbAuthzData ipaUserAuthType >>>>>ipatokenRadiusConfigLink >>>>>objectClass" >>>>> >>>>>Username: greenlanter at dc >>>>>Password: ************ >>>>> >>>>> >>>>>[30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>>> >>>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>>>passwordHistory ipaKrbAuthzData ipaUserAuthType >>>>>ipatokenRadiusConfigLink >>>>>objectClass" >>>>> >>>>> >>>>>Username: greenlanter at dc.comics.com >>>>>Password: ************ >>>>> >>>>>[30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com >>>>> >>>>>@DC.COMICS.COM >>>>>)(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM >>>>>)))" attrs="krbPrincipalName krbCanonicalName >>>>>ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference >>>>>krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >>>>>krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >>>>>krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >>>>>krbExtraData >>>>>krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >>>>>krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >>>>>ipaUserAuthType ipatokenRadiusConfigLink objectClass" >>>>> >>>>> >>>>>>From what I can tell, everything looks good to wbinfo; we see the >>>>>>domain >>>>>and he see's us. In the AD trust I can go under the trust and >>>>>validate the >>>>>trust with no issues. >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status >>>>>BUILTIN : online >>>>>DC : online >>>>>MARVEL : online >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>>>marvel.comics.com >>>>>Name : MARVEL >>>>>Alt_Name : marvel.comics.com >>>>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>>>Active Directory : Yes >>>>>Native : Yes >>>>>Primary : No >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n >>>>>'MARVEL.COMICS.COM\Domain >>>>>Admins' >>>>>S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>>>marvel.comics.com >>>>>Name : MARVEL >>>>>Alt_Name : marvel.comics.com >>>>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>>>Active Directory : Yes >>>>>Native : Yes >>>>>Primary : No >>>> >>>>Unfortunately you will not be able to log into Windows workstations >>>>using IPA >>>>users because FreeIPA is (at the moment) missing Global Catalog >>>>component >>>>which prevents Windows from working with IPA users. >>>> >>>>It should work the other way around, but there is nothing you can do >>>>at the >>>>moment to make it working with IPA users in Windows. Global Catalog >>>>is several >>>>months away in the best case. >>> >>>This is not entirely true. >>>There is no way to add IPA SIDs to the relevant authorization groups >>>using the GUI tools in AD, but technically you can do that using >>>command line tools and pasting in SIDs directly. >>>Authentication would be possible then, however Windows clients will >>>never be able to resolve SID to Names, so looking at file permissions >>>you will not be able to see user names, but only SIDs for IPA users. >>>Some tools that may depend on SID->Name translation may also fail in >>>unexpected ways. >>practically, you will not be able to login into Windows workstations >>because login screen will have to do Name->SID translation which it >>wouldn't be able to do. > >I do not think this is really true, I tested a while back that the PAC >is used for Name -> SID of the logging in user, but I do not know if >all versions of Windows will work flawlessly this way. At least Windows Server 2012 does following when I try to login interactively as EXAMPLE\admin (IPA admin) or admin at EXAMPLE.COM: 16:34:20.903405 IP (tos 0x2,ECT(0), ttl 128, id 18136, offset 0, flags [DF], proto TCP (6), length 52) wdc.adx.test.63757 > m1.example.com.kerberos: Flags [SEW], cksum 0xe350 (correct), seq 713019514, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 16:34:20.903539 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) m1.example.com.kerberos > wdc.adx.test.63757: Flags [S.], cksum 0x76c6 (incorrect -> 0xb654), seq 1716548939, ack 713019515, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 16:34:20.903674 IP (tos 0x0, ttl 128, id 18137, offset 0, flags [DF], proto TCP (6), length 40) wdc.adx.test.63757 > m1.example.com.kerberos: Flags [.], cksum 0x6837 (correct), seq 1, ack 1, win 256, length 0 16:34:20.903788 IP (tos 0x0, ttl 128, id 18138, offset 0, flags [DF], proto TCP (6), length 259) wdc.adx.test.63757 > m1.example.com.kerberos: Flags [P.], cksum 0xe08f (correct), seq 1:220, ack 1, win 256, length 219 16:34:20.903821 IP (tos 0x0, ttl 64, id 40856, offset 0, flags [DF], proto TCP (6), length 40) m1.example.com.kerberos > wdc.adx.test.63757: Flags [.], cksum 0x76ba (incorrect -> 0x676f), seq 1, ack 220, win 237, length 0 16:34:20.904727 IP (tos 0x0, ttl 64, id 40857, offset 0, flags [DF] proto TCP (6), length 202) m1.example.com.kerberos > wdc.adx.test.63757: Flags [P.], cksum 0x775c (incorrect -> 0x89b3), seq 1:163, ack 220, win 237, length 162 16:34:20.904778 IP (tos 0x0, ttl 64, id 40858, offset 0, flags [DF], proto TCP (6), length 40) m1.example.com.kerberos > wdc.adx.test.63757: Flags [F.], cksum 0x76ba (incorrect -> 0x66cc), seq 163, ack 220, win 237, length 0 16:34:20.904917 IP (tos 0x0, ttl 128, id 18139, offset 0, flags [DF], proto TCP (6), length 40) wdc.adx.test.63757 > m1.example.com.kerberos: Flags [.], cksum 0x66b9 (correct), seq 220, ack 164, win 256, length 0 16:34:20.905073 IP (tos 0x0, ttl 128, id 18140, offset 0, flags [DF], proto TCP (6), length 40) wdc.adx.test.63757 > m1.example.com.kerberos: Flags [F.], cksum 0x66b8 (correct), seq 220, ack 164, win 256, length 0 16:34:20.905133 IP (tos 0x0, ttl 64, id 33156, offset 0, flags [DF], proto TCP (6), length 40) m1.example.com.kerberos > wdc.adx.test.63757: Flags [.], cksum 0x66cb (correct), seq 164, ack 221, win 237, length 0 16:34:20.906033 IP (tos 0x0, ttl 128, id 18141, offset 0, flags [none], proto UDP (17), length 217) wdc.adx.test.50485 > m1.example.com.ldap: [udp sum ok] UDP, length 189 16:34:20.906434 IP (tos 0x0, ttl 64, id 64131, offset 0, flags [DF], proto UDP (17), length 190) m1.example.com.ldap > wdc.adx.test.50485: [bad udp cksum 0x775b -> 0xa778!] UDP, length 162 E.g. it tried to talk to IPA KDC and when failed, it did CLDAP ping to pick up information about IPA domain. KDC log has following: Oct 02 13:33:41 m1.example.com krb5kdc[924](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 192.168.122.235: CLIENT_NOT_FOUND: admin at EXAMPLE for krbtgt/EXAMPLE at EXAMPLE, Client not found in Kerberos database Oct 02 13:33:41 m1.example.com krb5kdc[924](info): closing down fd 12 Oct 02 13:34:20 m1.example.com krb5kdc[924](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 192.168.122.235: CLIENT_NOT_FOUND: admin at EXAMPLE for krbtgt/EXAMPLE at EXAMPLE, Client not found in Kerberos database Oct 02 13:34:20 m1.example.com krb5kdc[924](info): closing down fd 12 Oct 02 13:35:08 m1.example.com krb5kdc[924](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 192.168.122.235: CLIENT_NOT_FOUND: admin\@EXAMPLE.COM at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Client not found in Kerberos database Oct 02 13:35:08 m1.example.com krb5kdc[924](info): closing down fd 12 This is something more reasonable -- e.g. our DAL driver doesn't support domain flat name as a realm and doesn't support proper handling of enterprise principals. This is something I have patches for to cover trusted forests' realms but not our own. Maybe this is worth to investigate first. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 2 13:45:58 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 16:45:58 +0300 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: Message-ID: <20151002134558.GB5035@redhat.com> On Fri, 02 Oct 2015, Fujisan wrote: >More info: > >I can initiate a ticket: >$ kdestroy >$ kinit admin > >but cannot view user admin: >$ ipa user-show admin >ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized > >$ 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-dnskeysyncd Service: RUNNING >ipa: INFO: The ipactl command was successful > >/var/log/messages: >Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check >failed. Unable to create GSSAPI-encrypted LDAP connection. What did you do? This and the log below about HTTP/zaira2.opera at OPERA show that you have different keys in LDAP and in your keytab files for host/zaira2.opera and HTTP/zaira2.opera principals. This might happen if somebody removed the principals from LDAP (ipa service-del/ipa service-add, or ipa host-del/ipa host-add) so that they become non-synchronized with whatever you have in the keytab files. >On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: > >> Hello, >> >> I cannot login to the web UI anymore. >> >> The password or username you entered is incorrect. >> >> Log says: >> >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >> for krbtgt/OPERA at OPERA, Additional pre-authentication required >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >> (encrypted_timestamp) verify failure: Decrypt integrity check failed >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: HTTP/zaira2.opera at OPERA >> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >> >> >> I have no idea what went wrong. >> >> What can I do? >> >> ?Regards, >> Fuji? >> >> >-- >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 -- / Alexander Bokovoy From andrewm659 at yahoo.com Fri Oct 2 13:41:52 2015 From: andrewm659 at yahoo.com (Andrew Meyer) Date: Fri, 2 Oct 2015 13:41:52 +0000 (UTC) Subject: [Freeipa-users] FreeIPA install In-Reply-To: <560E3BB3.5070103@redhat.com> References: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> <560E3BB3.5070103@redhat.com> Message-ID: <184547654.266809.1443793312510.JavaMail.yahoo@mail.yahoo.com> works in chrome and not firefox, creating new FF profile. On Friday, October 2, 2015 3:09 AM, Martin Kosek wrote: On 10/02/2015 04:15 AM, Andrew Meyer wrote: > I just created a new FreeIPA setup at my home and i'm getting the following: > > [Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] AH00094: Command > line: '/usr/sbin/httpd -D FOREGROUND' > [Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: INFO: *** PROCESS > START *** > [Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL Library Error: > -12271 SSL client cannot verify your certificate > [Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL Library Error: > -12271 SSL client cannot verify your certificate > > I tried running the ipa-manage-cacert to generate a new one and install it. > But no go. > > Running CentOS 7.1 with latest updates.? Is there a bug in generating the SSL cert? > > > This rather seems that your client browser does not trust FreeIPA CA certificate. Related thread: https://www.redhat.com/archives/freeipa-devel/2009-June/msg00188.html More related info: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/using-the-ui.html#config-browser Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 2 13:50:16 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 2 Oct 2015 15:50:16 +0200 Subject: [Freeipa-users] FreeIPA install In-Reply-To: <184547654.266809.1443793312510.JavaMail.yahoo@mail.yahoo.com> References: <49946488.84105.1443752138529.JavaMail.yahoo@mail.yahoo.com> <560E3BB3.5070103@redhat.com> <184547654.266809.1443793312510.JavaMail.yahoo@mail.yahoo.com> Message-ID: <560E8B98.6060106@redhat.com> On 10/02/2015 03:41 PM, Andrew Meyer wrote: > works in chrome and not firefox, creating new FF profile. > Hi, try to remove IPA certificates from firefox in ff settings Martin > > > On Friday, October 2, 2015 3:09 AM, Martin Kosek > wrote: > > > > On 10/02/2015 04:15 AM, Andrew Meyer wrote: > > > I just created a new FreeIPA setup at my home and i'm getting > the following: > > > > [Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] > AH00094: Command > > line: '/usr/sbin/httpd -D FOREGROUND' > > [Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: > INFO: *** PROCESS > > START *** > > [Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: > INFO: *** PROCESS > > START *** > > [Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL > Library Error: > > -12271 SSL client cannot verify your certificate > > [Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL > Library Error: > > -12271 SSL client cannot verify your certificate > > > > I tried running the ipa-manage-cacert to generate a new one and > install it. > > But no go. > > > > Running CentOS 7.1 with latest updates. Is there a bug in > generating the SSL cert? > > > > > > > > > This rather seems that your client browser does not trust FreeIPA > CA certificate. > > Related thread: > https://www.redhat.com/archives/freeipa-devel/2009-June/msg00188.html > > More related info: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/using-the-ui.html#config-browser > > Martin > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aebruno2 at buffalo.edu Fri Oct 2 13:56:47 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Fri, 2 Oct 2015 09:56:47 -0400 Subject: [Freeipa-users] re-initialize replica Message-ID: <20151002135647.GA18409@dead.ccr.buffalo.edu> What's the best way to re-initialize a replica? Suppose one of your replicas goes south.. is there a command to tell that replicate to re-initialize from the first master (instead of removing/re-adding the replica from the topology)? Thanks, --Andrew From abokovoy at redhat.com Fri Oct 2 14:03:04 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 17:03:04 +0300 Subject: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops In-Reply-To: <560E8422.60709@redhat.com> References: <560CDD7C.8090804@redhat.com> <560D5A68.7070608@redhat.com> <20151002080639.GI4971@redhat.com> <560E8422.60709@redhat.com> Message-ID: <20151002140304.GC5035@redhat.com> On Fri, 02 Oct 2015, Simo Sorce wrote: >On 02/10/15 04:06, Alexander Bokovoy wrote: >>On Thu, 01 Oct 2015, Simo Sorce wrote: >>>On 01/10/15 03:15, Petr Spacek wrote: >>>>On 30.9.2015 20:36, Matt Wells wrote: >>>>>Hi all, I hoped I may glean some brilliance from the group. >>>>>I have a Freeipa Server sitting atop a Fedora 21 server. The >>>>>initial plan >>>>>was to replicate users+passwords with Windows 2012R2 server but >>>>>following >>>>>some of the information in the other posts and docs we've moved to a >>>>>trust. The trust has been setup using the documentation and in >>>>>short it's >>>>>worked without issue. I'm able to get principles from the Windows >>>>>realm ( >>>>>marvel.comics.com). So what I'm attempting and failing to do is >>>>>authenticating my IPA users to the Windows 8 desktops. Ideally I don't >>>>>want any users in AD, it's simply there to deliver a GPO and in the >>>>>next >>>>>year it will be phased out and we'll be replacing Windows 8 with linux >>>>>desktops. >>>>> >>>>>So >>>>>marvel.comics.com = windows >>>>>dc.comics.com = freeipa >>>>> >>>>># rpm -qi freeipa-server >>>>>Name : freeipa-server >>>>>Version : 4.1.4 >>>>>Release : 1.fc21 >>>>>Architecture: x86_64 >>>>>Install Date: Tue 25 Aug 2015 08:17:56 PM UTC >>>>>Group : System Environment/Base >>>>>Size : 4521059 >>>>>License : GPLv3+ >>>>>Signature : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID >>>>>89ad4e8795a43f54 >>>>>Source RPM : freeipa-4.1.4-1.fc21.src.rpm >>>>>Build Date : Thu 26 Mar 2015 03:16:19 PM UTC >>>>>Build Host : buildhw-07.phx2.fedoraproject.org >>>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a >>>>>Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon >>>>>Aug 17 >>>>>22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>[root at freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release >>>>>Fedora release 21 (Twenty One) >>>>> >>>>>To cut to the chase here's me logging into a Windows 8 desktop >>>>>system. I >>>>>try to login 3 different ways; this system is a member of the marvel >>>>>domain. Time is extremely close, close enough that I feel really good >>>>>about ruling it out. Any light you all could shed on this would be >>>>>outstanding. Thank you all for your time on this, I really >>>>>appreciate all >>>>>the time and effort this team puts into reading these posts. >>>>> >>>>>Username: dc/greenlantern >>>>>Password: ************ >>>>> >>>>>[root at freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i >>>>>greenlantern >>>>>[30/Sep/2015:17:55:33 +0000] conn=1172 op=46 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>>> >>>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>>>passwordHistory ipaKrbAuthzData ipaUserAuthType >>>>>ipatokenRadiusConfigLink >>>>>objectClass" >>>>> >>>>>Username: greenlanter at dc >>>>>Password: ************ >>>>> >>>>> >>>>>[30/Sep/2015:17:59:48 +0000] conn=1172 op=86 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern at dc >>>>> >>>>>)(krbPrincipalName=greenlantern at dc)))" attrs="krbPrincipalName >>>>>krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration >>>>>krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange >>>>>krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth >>>>>krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences >>>>>krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock >>>>>passwordHistory ipaKrbAuthzData ipaUserAuthType >>>>>ipatokenRadiusConfigLink >>>>>objectClass" >>>>> >>>>> >>>>>Username: greenlanter at dc.comics.com >>>>>Password: ************ >>>>> >>>>>[30/Sep/2015:17:59:35 +0000] conn=1172 op=84 SRCH >>>>>base="dc=dc,dc=comics,dc=com" scope=2 >>>>>filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5C at dc.COMICS.com >>>>> >>>>>@DC.COMICS.COM >>>>>)(krbPrincipalName=greenlantern\5C at dc.COMICS.com@DC.COMICS.COM >>>>>)))" attrs="krbPrincipalName krbCanonicalName >>>>>ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey >>>>>krbTicketPolicyReference >>>>>krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference >>>>>krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases >>>>>krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount >>>>>krbExtraData >>>>>krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife >>>>>krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData >>>>>ipaUserAuthType ipatokenRadiusConfigLink objectClass" >>>>> >>>>> >>>>>>From what I can tell, everything looks good to wbinfo; we see the >>>>>>domain >>>>>and he see's us. In the AD trust I can go under the trust and >>>>>validate the >>>>>trust with no issues. >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --online-status >>>>>BUILTIN : online >>>>>DC : online >>>>>MARVEL : online >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>>>marvel.comics.com >>>>>Name : MARVEL >>>>>Alt_Name : marvel.comics.com >>>>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>>>Active Directory : Yes >>>>>Native : Yes >>>>>Primary : No >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo -n >>>>>'MARVEL.COMICS.COM\Domain >>>>>Admins' >>>>>S-1-5-21-3495301974-2766379234-3984916731-512 SID_DOM_GROUP (2) >>>>>[root at freeipaServer slapd-MARVEL-COMICS-COM]# wbinfo --domain-info >>>>>marvel.comics.com >>>>>Name : MARVEL >>>>>Alt_Name : marvel.comics.com >>>>>SID : S-1-5-21-3495301974-2766379234-3984916731 >>>>>Active Directory : Yes >>>>>Native : Yes >>>>>Primary : No >>>> >>>>Unfortunately you will not be able to log into Windows workstations >>>>using IPA >>>>users because FreeIPA is (at the moment) missing Global Catalog >>>>component >>>>which prevents Windows from working with IPA users. >>>> >>>>It should work the other way around, but there is nothing you can do >>>>at the >>>>moment to make it working with IPA users in Windows. Global Catalog >>>>is several >>>>months away in the best case. >>> >>>This is not entirely true. >>>There is no way to add IPA SIDs to the relevant authorization groups >>>using the GUI tools in AD, but technically you can do that using >>>command line tools and pasting in SIDs directly. >>>Authentication would be possible then, however Windows clients will >>>never be able to resolve SID to Names, so looking at file permissions >>>you will not be able to see user names, but only SIDs for IPA users. >>>Some tools that may depend on SID->Name translation may also fail in >>>unexpected ways. >>practically, you will not be able to login into Windows workstations >>because login screen will have to do Name->SID translation which it >>wouldn't be able to do. > >I do not think this is really true, I tested a while back that the PAC >is used for Name -> SID of the logging in user, but I do not know if >all versions of Windows will work flawlessly this way. When I tried to login as EXAMPLE.COM\admin (my IPA admin) to Windows Server 2012 over two-way trust, I've got following message: https://abbra.fedorapeople.org/.paste/wrong-sign-in-method.png This simply means EXAMPLE.COM\admin lacks interactive logon rights because nobody assigned them. I agree that theoretically one could assign them one way or another but this has to be done manually for every IPA member (via some group's SID?) and at every machine in the domain to even check whether we'll be able to proceed further and find out that we need Global Catalog to continue. ;) -- / Alexander Bokovoy From fujisan43 at gmail.com Fri Oct 2 14:06:00 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 16:06:00 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <20151002134558.GB5035@redhat.com> References: <20151002134558.GB5035@redhat.com> Message-ID: Well, I think I messed up when trying to configure cockpit to use kerberos. What should I do to fix this? I have this on the ipa server: $ klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/zaira2.opera at OPERA 2 host/zaira2.opera at OPERA 2 host/zaira2.opera at OPERA 2 host/zaira2.opera at OPERA 1 nfs/zaira2.opera at OPERA 1 nfs/zaira2.opera at OPERA 1 nfs/zaira2.opera at OPERA 1 nfs/zaira2.opera at OPERA 3 HTTP/zaira2.opera at OPERA 3 HTTP/zaira2.opera at OPERA 3 HTTP/zaira2.opera at OPERA 3 HTTP/zaira2.opera at OPERA On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy wrote: > On Fri, 02 Oct 2015, Fujisan wrote: > >> More info: >> >> I can initiate a ticket: >> $ kdestroy >> $ kinit admin >> >> but cannot view user admin: >> $ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> >> $ 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-dnskeysyncd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> /var/log/messages: >> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >> check >> failed. Unable to create GSSAPI-encrypted LDAP connection. >> > What did you do? > > This and the log below about HTTP/zaira2.opera at OPERA show that you have > different keys in LDAP and in your keytab files for host/zaira2.opera > and HTTP/zaira2.opera principals. This might happen if somebody removed > the principals from LDAP (ipa service-del/ipa service-add, or ipa > host-del/ipa host-add) so that they become non-synchronized with > whatever you have in the keytab files. > > > On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >> >> Hello, >>> >>> I cannot login to the web UI anymore. >>> >>> The password or username you entered is incorrect. >>> >>> Log says: >>> >>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: HTTP/zaira2.opera at OPERA >>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>> >>> >>> I have no idea what went wrong. >>> >>> What can I do? >>> >>> ?Regards, >>> Fuji? >>> >>> >>> > -- >> 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 >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 2 14:25:25 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 17:25:25 +0300 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> Message-ID: <20151002142525.GD5035@redhat.com> On Fri, 02 Oct 2015, Fujisan wrote: >Well, I think I messed up when trying to configure cockpit to use kerberos. > >What should I do to fix this? > >I have this on the ipa server: >$ klist -k >Keytab name: FILE:/etc/krb5.keytab >KVNO Principal >---- >-------------------------------------------------------------------------- > 2 host/zaira2.opera at OPERA > 2 host/zaira2.opera at OPERA > 2 host/zaira2.opera at OPERA > 2 host/zaira2.opera at OPERA > 1 nfs/zaira2.opera at OPERA > 1 nfs/zaira2.opera at OPERA > 1 nfs/zaira2.opera at OPERA > 1 nfs/zaira2.opera at OPERA > 3 HTTP/zaira2.opera at OPERA > 3 HTTP/zaira2.opera at OPERA > 3 HTTP/zaira2.opera at OPERA > 3 HTTP/zaira2.opera at OPERA > You can start by: 0. backup every file mentioned below 1. Move /etc/krb5.keytab somewhere 2. kinit as admin 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab 4. restart SSSD 5. Move /etc/httpd/conf/ipa.keytab somewhere 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k /etc/httpd/conf/ipa.keytab 7. Restart httpd Every time you run 'ipa-getkeytab', Kerberos key for the service specified by you is replaced on the server side so that keys in the keytabs become unusable. I guess cockpit instructions were for something that was not supposed to run on IPA master. On IPA master there are already all needed services (host/ and HTTP/) and their keytabs are in place. > >On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >wrote: > >> On Fri, 02 Oct 2015, Fujisan wrote: >> >>> More info: >>> >>> I can initiate a ticket: >>> $ kdestroy >>> $ kinit admin >>> >>> but cannot view user admin: >>> $ ipa user-show admin >>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>> Unauthorized >>> >>> $ 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-dnskeysyncd Service: RUNNING >>> ipa: INFO: The ipactl command was successful >>> >>> /var/log/messages: >>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>> check >>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>> >> What did you do? >> >> This and the log below about HTTP/zaira2.opera at OPERA show that you have >> different keys in LDAP and in your keytab files for host/zaira2.opera >> and HTTP/zaira2.opera principals. This might happen if somebody removed >> the principals from LDAP (ipa service-del/ipa service-add, or ipa >> host-del/ipa host-add) so that they become non-synchronized with >> whatever you have in the keytab files. >> >> >> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>> >>> Hello, >>>> >>>> I cannot login to the web UI anymore. >>>> >>>> The password or username you entered is incorrect. >>>> >>>> Log says: >>>> >>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 17 >>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: HTTP/zaira2.opera at OPERA >>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>> >>>> >>>> I have no idea what went wrong. >>>> >>>> What can I do? >>>> >>>> ?Regards, >>>> Fuji? >>>> >>>> >>>> >> -- >>> 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 >>> >> >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From simo at redhat.com Fri Oct 2 14:33:20 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 2 Oct 2015 10:33:20 -0400 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <20151002142525.GD5035@redhat.com> References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> Message-ID: <560E95B0.4080602@redhat.com> On 02/10/15 10:25, Alexander Bokovoy wrote: > On Fri, 02 Oct 2015, Fujisan wrote: >> Well, I think I messed up when trying to configure cockpit to use >> kerberos. >> >> What should I do to fix this? >> >> I have this on the ipa server: >> $ klist -k >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> > You can start by: > 0. backup every file mentioned below > 1. Move /etc/krb5.keytab somewhere > 2. kinit as admin > 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab > 4. restart SSSD > 5. Move /etc/httpd/conf/ipa.keytab somewhere > 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k > /etc/httpd/conf/ipa.keytab > 7. Restart httpd > > Every time you run 'ipa-getkeytab', Kerberos key for the service > specified by you is replaced on the server side so that keys in the > keytabs become unusable. Note you can use the -r switch to just retrieve (w/o resetting the key) the HTTP/name key in the ipa.keytab and not move away any keytabs. Higher kvno will win. You can use ktutil if you really want to remove keys from /etc/krb5.keytab HTH, Simo. > I guess cockpit instructions were for something that was not supposed to > run on IPA master. On IPA master there are already all needed services > (host/ and HTTP/) and their keytabs are in place. > >> >> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >> wrote: >> >>> On Fri, 02 Oct 2015, Fujisan wrote: >>> >>>> More info: >>>> >>>> I can initiate a ticket: >>>> $ kdestroy >>>> $ kinit admin >>>> >>>> but cannot view user admin: >>>> $ ipa user-show admin >>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>> Unauthorized >>>> >>>> $ 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-dnskeysyncd Service: RUNNING >>>> ipa: INFO: The ipactl command was successful >>>> >>>> /var/log/messages: >>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>>> check >>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>> >>> What did you do? >>> >>> This and the log below about HTTP/zaira2.opera at OPERA show that you have >>> different keys in LDAP and in your keytab files for host/zaira2.opera >>> and HTTP/zaira2.opera principals. This might happen if somebody removed >>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>> host-del/ipa host-add) so that they become non-synchronized with >>> whatever you have in the keytab files. >>> >>> >>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>>> >>>> Hello, >>>>> >>>>> I cannot login to the web UI anymore. >>>>> >>>>> The password or username you entered is incorrect. >>>>> >>>>> Log says: >>>>> >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>> {18 17 >>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>> HTTP/zaira2.opera at OPERA >>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>> {18 17 >>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>> HTTP/zaira2.opera at OPERA >>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>> >>>>> >>>>> I have no idea what went wrong. >>>>> >>>>> What can I do? >>>>> >>>>> ?Regards, >>>>> Fuji? >>>>> >>>>> >>>>> >>> -- >>>> 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 >>>> >>> >>> >>> -- >>> / Alexander Bokovoy >>> > -- Simo Sorce * Red Hat, Inc * New York From fujisan43 at gmail.com Fri Oct 2 14:44:50 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 16:44:50 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <20151002142525.GD5035@redhat.com> References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> Message-ID: I still cannot login to the web UI. Here is what I did: 1. mv /etc/krb5.keytab /etc/krb5.keytab.save 2. kinit admin Password for admin at OPERA: 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k /etc/krb5.keytab 4. systemctl restart sssd.service 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k /etc/httpd/conf/ipa.keytab 7. systemctl restart httpd.service The log says now: Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 17 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA for krbtgt/OPERA at OPERA, Additional pre-authentication required On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy wrote: > On Fri, 02 Oct 2015, Fujisan wrote: > >> Well, I think I messed up when trying to configure cockpit to use >> kerberos. >> >> What should I do to fix this? >> >> I have this on the ipa server: >> $ klist -k >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 2 host/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 1 nfs/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> 3 HTTP/zaira2.opera at OPERA >> >> You can start by: > 0. backup every file mentioned below > 1. Move /etc/krb5.keytab somewhere > 2. kinit as admin > 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab > 4. restart SSSD > 5. Move /etc/httpd/conf/ipa.keytab somewhere > 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k > /etc/httpd/conf/ipa.keytab > 7. Restart httpd > > Every time you run 'ipa-getkeytab', Kerberos key for the service > specified by you is replaced on the server side so that keys in the > keytabs become unusable. > > I guess cockpit instructions were for something that was not supposed to > run on IPA master. On IPA master there are already all needed services > (host/ and HTTP/) and their keytabs are in place. > > > >> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >> wrote: >> >> On Fri, 02 Oct 2015, Fujisan wrote: >>> >>> More info: >>>> >>>> I can initiate a ticket: >>>> $ kdestroy >>>> $ kinit admin >>>> >>>> but cannot view user admin: >>>> $ ipa user-show admin >>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>> Unauthorized >>>> >>>> $ 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-dnskeysyncd Service: RUNNING >>>> ipa: INFO: The ipactl command was successful >>>> >>>> /var/log/messages: >>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>>> check >>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>> >>>> What did you do? >>> >>> This and the log below about HTTP/zaira2.opera at OPERA show that you have >>> different keys in LDAP and in your keytab files for host/zaira2.opera >>> and HTTP/zaira2.opera principals. This might happen if somebody removed >>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>> host-del/ipa host-add) so that they become non-synchronized with >>> whatever you have in the keytab files. >>> >>> >>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>> >>>> >>>> Hello, >>>> >>>>> >>>>> I cannot login to the web UI anymore. >>>>> >>>>> The password or username you entered is incorrect. >>>>> >>>>> Log says: >>>>> >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 >>>>> 17 >>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>> HTTP/zaira2.opera at OPERA >>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes {18 >>>>> 17 >>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>> HTTP/zaira2.opera at OPERA >>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>> >>>>> >>>>> I have no idea what went wrong. >>>>> >>>>> What can I do? >>>>> >>>>> ?Regards, >>>>> Fuji? >>>>> >>>>> >>>>> >>>>> -- >>> >>>> 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 >>>> >>>> >>> >>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Fri Oct 2 14:46:36 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 16:46:36 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> Message-ID: I forgot to mention that $ ipa user-show admin ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: > I still cannot login to the web UI. > > Here is what I did: > > 1. mv /etc/krb5.keytab /etc/krb5.keytab.save > 2. kinit admin > Password for admin at OPERA: > 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k > /etc/krb5.keytab > 4. systemctl restart sssd.service > 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save > 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k > /etc/httpd/conf/ipa.keytab > 7. systemctl restart httpd.service > > The log says now: > > Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 17 > 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA > for krbtgt/OPERA at OPERA, Additional pre-authentication required > > > > On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy > wrote: > >> On Fri, 02 Oct 2015, Fujisan wrote: >> >>> Well, I think I messed up when trying to configure cockpit to use >>> kerberos. >>> >>> What should I do to fix this? >>> >>> I have this on the ipa server: >>> $ klist -k >>> Keytab name: FILE:/etc/krb5.keytab >>> KVNO Principal >>> ---- >>> >>> -------------------------------------------------------------------------- >>> 2 host/zaira2.opera at OPERA >>> 2 host/zaira2.opera at OPERA >>> 2 host/zaira2.opera at OPERA >>> 2 host/zaira2.opera at OPERA >>> 1 nfs/zaira2.opera at OPERA >>> 1 nfs/zaira2.opera at OPERA >>> 1 nfs/zaira2.opera at OPERA >>> 1 nfs/zaira2.opera at OPERA >>> 3 HTTP/zaira2.opera at OPERA >>> 3 HTTP/zaira2.opera at OPERA >>> 3 HTTP/zaira2.opera at OPERA >>> 3 HTTP/zaira2.opera at OPERA >>> >>> You can start by: >> 0. backup every file mentioned below >> 1. Move /etc/krb5.keytab somewhere >> 2. kinit as admin >> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >> 4. restart SSSD >> 5. Move /etc/httpd/conf/ipa.keytab somewhere >> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >> /etc/httpd/conf/ipa.keytab >> 7. Restart httpd >> >> Every time you run 'ipa-getkeytab', Kerberos key for the service >> specified by you is replaced on the server side so that keys in the >> keytabs become unusable. >> >> I guess cockpit instructions were for something that was not supposed to >> run on IPA master. On IPA master there are already all needed services >> (host/ and HTTP/) and their keytabs are in place. >> >> >> >>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >>> wrote: >>> >>> On Fri, 02 Oct 2015, Fujisan wrote: >>>> >>>> More info: >>>>> >>>>> I can initiate a ticket: >>>>> $ kdestroy >>>>> $ kinit admin >>>>> >>>>> but cannot view user admin: >>>>> $ ipa user-show admin >>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>> Unauthorized >>>>> >>>>> $ 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-dnskeysyncd Service: RUNNING >>>>> ipa: INFO: The ipactl command was successful >>>>> >>>>> /var/log/messages: >>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>>>> check >>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>> >>>>> What did you do? >>>> >>>> This and the log below about HTTP/zaira2.opera at OPERA show that you have >>>> different keys in LDAP and in your keytab files for host/zaira2.opera >>>> and HTTP/zaira2.opera principals. This might happen if somebody removed >>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>> host-del/ipa host-add) so that they become non-synchronized with >>>> whatever you have in the keytab files. >>>> >>>> >>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> I cannot login to the web UI anymore. >>>>>> >>>>>> The password or username you entered is incorrect. >>>>>> >>>>>> Log says: >>>>>> >>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>> {18 17 >>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>> HTTP/zaira2.opera at OPERA >>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>> {18 17 >>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>> HTTP/zaira2.opera at OPERA >>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>> >>>>>> >>>>>> I have no idea what went wrong. >>>>>> >>>>>> What can I do? >>>>>> >>>>>> ?Regards, >>>>>> Fuji? >>>>>> >>>>>> >>>>>> >>>>>> -- >>>> >>>>> 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 >>>>> >>>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 2 15:01:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Oct 2015 18:01:45 +0300 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> Message-ID: <20151002150145.GG5035@redhat.com> On Fri, 02 Oct 2015, Fujisan wrote: >I forgot to mention that > >$ ipa user-show admin >ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized This is most likely because of the cached session to your server. You can check if keyctl list @s returns you something like [root at m1 ~]# keyctl list @s 2 keys in keyring: 496745412: --alswrv 0 65534 keyring: _uid.0 215779962: --alswrv 0 0 user: ipa_session_cookie:admin at EXAMPLE.COM If so, then notice the key number (215779962) for the session cookie, and do: keyctl purge 215779962 keyctl reap This should make a next 'ipa ...' command run to ask for new cookie. > >On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: > >> I still cannot login to the web UI. >> >> Here is what I did: >> >> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >> 2. kinit admin >> Password for admin at OPERA: >> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >> /etc/krb5.keytab >> 4. systemctl restart sssd.service >> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >> /etc/httpd/conf/ipa.keytab >> 7. systemctl restart httpd.service >> >> The log says now: >> >> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 17 >> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >> for krbtgt/OPERA at OPERA, Additional pre-authentication required >> >> >> >> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy >> wrote: >> >>> On Fri, 02 Oct 2015, Fujisan wrote: >>> >>>> Well, I think I messed up when trying to configure cockpit to use >>>> kerberos. >>>> >>>> What should I do to fix this? >>>> >>>> I have this on the ipa server: >>>> $ klist -k >>>> Keytab name: FILE:/etc/krb5.keytab >>>> KVNO Principal >>>> ---- >>>> >>>> -------------------------------------------------------------------------- >>>> 2 host/zaira2.opera at OPERA >>>> 2 host/zaira2.opera at OPERA >>>> 2 host/zaira2.opera at OPERA >>>> 2 host/zaira2.opera at OPERA >>>> 1 nfs/zaira2.opera at OPERA >>>> 1 nfs/zaira2.opera at OPERA >>>> 1 nfs/zaira2.opera at OPERA >>>> 1 nfs/zaira2.opera at OPERA >>>> 3 HTTP/zaira2.opera at OPERA >>>> 3 HTTP/zaira2.opera at OPERA >>>> 3 HTTP/zaira2.opera at OPERA >>>> 3 HTTP/zaira2.opera at OPERA >>>> >>>> You can start by: >>> 0. backup every file mentioned below >>> 1. Move /etc/krb5.keytab somewhere >>> 2. kinit as admin >>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >>> 4. restart SSSD >>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>> /etc/httpd/conf/ipa.keytab >>> 7. Restart httpd >>> >>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>> specified by you is replaced on the server side so that keys in the >>> keytabs become unusable. >>> >>> I guess cockpit instructions were for something that was not supposed to >>> run on IPA master. On IPA master there are already all needed services >>> (host/ and HTTP/) and their keytabs are in place. >>> >>> >>> >>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >>>> wrote: >>>> >>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>> >>>>> More info: >>>>>> >>>>>> I can initiate a ticket: >>>>>> $ kdestroy >>>>>> $ kinit admin >>>>>> >>>>>> but cannot view user admin: >>>>>> $ ipa user-show admin >>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>> Unauthorized >>>>>> >>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>> ipa: INFO: The ipactl command was successful >>>>>> >>>>>> /var/log/messages: >>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>>>>> check >>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>> >>>>>> What did you do? >>>>> >>>>> This and the log below about HTTP/zaira2.opera at OPERA show that you have >>>>> different keys in LDAP and in your keytab files for host/zaira2.opera >>>>> and HTTP/zaira2.opera principals. This might happen if somebody removed >>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>> whatever you have in the keytab files. >>>>> >>>>> >>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>>> >>>>>>> I cannot login to the web UI anymore. >>>>>>> >>>>>>> The password or username you entered is incorrect. >>>>>>> >>>>>>> Log says: >>>>>>> >>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>> {18 17 >>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>> HTTP/zaira2.opera at OPERA >>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>> {18 17 >>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>> HTTP/zaira2.opera at OPERA >>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>>> >>>>>>> >>>>>>> I have no idea what went wrong. >>>>>>> >>>>>>> What can I do? >>>>>>> >>>>>>> ?Regards, >>>>>>> Fuji? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>> -- >>> / 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 -- / Alexander Bokovoy From fujisan43 at gmail.com Fri Oct 2 15:04:46 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Oct 2015 17:04:46 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <20151002150145.GG5035@redhat.com> References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: I only have this: $ keyctl list @s 1 key in keyring: 641467419: --alswrv 0 65534 keyring: _uid.0 $ On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy wrote: > On Fri, 02 Oct 2015, Fujisan wrote: > >> I forgot to mention that >> >> $ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> > This is most likely because of the cached session to your server. > > You can check if keyctl list @s > returns you something like > [root at m1 ~]# keyctl list @s > 2 keys in keyring: > 496745412: --alswrv 0 65534 keyring: _uid.0 > 215779962: --alswrv 0 0 user: ipa_session_cookie:admin at EXAMPLE.COM > > If so, then notice the key number (215779962) for the session cookie, > and do: > keyctl purge 215779962 > keyctl reap > > This should make a next 'ipa ...' command run to ask for new cookie. > > >> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >> >> I still cannot login to the web UI. >>> >>> Here is what I did: >>> >>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>> 2. kinit admin >>> Password for admin at OPERA: >>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>> /etc/krb5.keytab >>> 4. systemctl restart sssd.service >>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>> /etc/httpd/conf/ipa.keytab >>> 7. systemctl restart httpd.service >>> >>> >>> The log says now: >>> >>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 17 >>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>> >>> >>> >>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy >>> wrote: >>> >>> On Fri, 02 Oct 2015, Fujisan wrote: >>>> >>>> Well, I think I messed up when trying to configure cockpit to use >>>>> kerberos. >>>>> >>>>> What should I do to fix this? >>>>> >>>>> I have this on the ipa server: >>>>> $ klist -k >>>>> Keytab name: FILE:/etc/krb5.keytab >>>>> KVNO Principal >>>>> ---- >>>>> >>>>> >>>>> -------------------------------------------------------------------------- >>>>> 2 host/zaira2.opera at OPERA >>>>> 2 host/zaira2.opera at OPERA >>>>> 2 host/zaira2.opera at OPERA >>>>> 2 host/zaira2.opera at OPERA >>>>> 1 nfs/zaira2.opera at OPERA >>>>> 1 nfs/zaira2.opera at OPERA >>>>> 1 nfs/zaira2.opera at OPERA >>>>> 1 nfs/zaira2.opera at OPERA >>>>> 3 HTTP/zaira2.opera at OPERA >>>>> 3 HTTP/zaira2.opera at OPERA >>>>> 3 HTTP/zaira2.opera at OPERA >>>>> 3 HTTP/zaira2.opera at OPERA >>>>> >>>>> You can start by: >>>>> >>>> 0. backup every file mentioned below >>>> 1. Move /etc/krb5.keytab somewhere >>>> 2. kinit as admin >>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >>>> 4. restart SSSD >>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>> /etc/httpd/conf/ipa.keytab >>>> 7. Restart httpd >>>> >>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>> specified by you is replaced on the server side so that keys in the >>>> keytabs become unusable. >>>> >>>> I guess cockpit instructions were for something that was not supposed to >>>> run on IPA master. On IPA master there are already all needed services >>>> (host/ and HTTP/) and their keytabs are in place. >>>> >>>> >>>> >>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >>>>> wrote: >>>>> >>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>> >>>>>> >>>>>> More info: >>>>>> >>>>>>> >>>>>>> I can initiate a ticket: >>>>>>> $ kdestroy >>>>>>> $ kinit admin >>>>>>> >>>>>>> but cannot view user admin: >>>>>>> $ ipa user-show admin >>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>> Unauthorized >>>>>>> >>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>> ipa: INFO: The ipactl command was successful >>>>>>> >>>>>>> /var/log/messages: >>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to initialize >>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>>>>>> check >>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>> >>>>>>> What did you do? >>>>>>> >>>>>> >>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that you >>>>>> have >>>>>> different keys in LDAP and in your keytab files for host/zaira2.opera >>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>> removed >>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>> whatever you have in the keytab files. >>>>>> >>>>>> >>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>>>>> >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>>> I cannot login to the web UI anymore. >>>>>>>> >>>>>>>> The password or username you entered is incorrect. >>>>>>>> >>>>>>>> Log says: >>>>>>>> >>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>> {18 17 >>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check failed >>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>> {18 17 >>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd 12 >>>>>>>> >>>>>>>> >>>>>>>> I have no idea what went wrong. >>>>>>>> >>>>>>>> What can I do? >>>>>>>> >>>>>>>> ?Regards, >>>>>>>> Fuji? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> >>>>>> >>>>>> -- >>>> / 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 >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexanders.mailinglists+nospam at gmail.com Fri Oct 2 14:28:57 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Fri, 2 Oct 2015 16:28:57 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 Message-ID: Hello How do I get password authentication to work with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? Long version follows :) We've got an IPA server with the Red Hat Identity Management server on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured users and groups there and would now like to login with SSH. When I store a SSH key for the user account, I can login just fine, using this SSH key. But I'd like/need to use passwords as well. And sudo also doesn't work, when it's asking for passwords - I supposed, it's the same root cause. Let's stick with SSH. Initially, I installed the FreeIPA client with this command line: ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ --enable-dns-updates --unattended \ --principal=admin --password=correctone \ --domain=customer.company.internal \ --server=auth01.customer.company.internal I then try to do a SSH login with: ssh -l ewt at customer.company.internal 192.168.229.143 or: ssh -l ewt 192.168.229.143 Password authentication doesn't work. In the /var/log/syslog on the system where I try to login, I find this: 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: Key table entry not found After having turned up the debug level of the sssd with "sssd -i -f -d 0x0770 --debug-timestamps=1", I find the following in the system log files: 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.71.117.1 user=ewt 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.71.117.1 user=ewt 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: pam_sss(sshd:auth): received for user ewt: 4 (System error) 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed password for ewt from 212.71.117.1 port 58136 ssh2 TBH, I don't quite understand it. Anyway, in /var/log/sssd/sssd_customer.company.internal.log I noticed: (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] [parse_krb5_child_response] (0x0020): message too short. (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] [krb5_auth_done] (0x0040): Could not parse child response [22]: Invalid argument (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. Well? What am I doing wrong or what might I have forgotten? Thanks a lot and best regards, Alexander -- => Google+ => http://plus.skwar.me <== => Chat (Jabber/Google Talk) => a.skwar at gmail.com <== From sbose at redhat.com Fri Oct 2 15:56:26 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 2 Oct 2015 17:56:26 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: Message-ID: <20151002155626.GK22851@p.redhat.com> On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > Hello > > How do I get password authentication to work with freeipa-client > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > Long version follows :) > > We've got an IPA server with the Red Hat Identity Management server > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > users and groups there and would now like to login with SSH. When I > store a SSH key for the user account, I can login just fine, using > this SSH key. But I'd like/need to use passwords as well. And sudo > also doesn't work, when it's asking for passwords - I supposed, > it's the same root cause. > > Let's stick with SSH. > > Initially, I installed the FreeIPA client with this command line: > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > --enable-dns-updates --unattended \ > --principal=admin --password=correctone \ > --domain=customer.company.internal \ > --server=auth01.customer.company.internal > > I then try to do a SSH login with: > > ssh -l ewt at customer.company.internal 192.168.229.143 > or: > ssh -l ewt 192.168.229.143 > > Password authentication doesn't work. > > In the /var/log/syslog on the system where I try to login, I find this: > > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: > Key table entry not found > > After having turned up the debug level of the sssd with "sssd -i -f -d > 0x0770 --debug-timestamps=1", I find the following in the system log > files: > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=212.71.117.1 user=ewt > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=212.71.117.1 user=ewt > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > pam_sss(sshd:auth): received for user ewt: 4 (System error) > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > password for ewt from 212.71.117.1 port 58136 ssh2 > > TBH, I don't quite understand it. Anyway, in > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [read_pipe_handler] (0x0400): EOF received, client finished > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [parse_krb5_child_response] (0x0020): message too short. > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [krb5_auth_done] (0x0040): Could not parse child response [22]: > Invalid argument > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. looks like krb5_child is not able to process the request. There should be a krb5_child log as well, maybe it has more details. bye, Sumit > > Well? What am I doing wrong or what might I have forgotten? > > Thanks a lot and best regards, > > Alexander > -- > => Google+ => http://plus.skwar.me <== > => Chat (Jabber/Google Talk) => a.skwar at gmail.com <== > > -- > 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 From jhrozek at redhat.com Fri Oct 2 15:59:51 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 2 Oct 2015 17:59:51 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: Message-ID: <20151002155951.GB3127@hendrix.redhat.com> On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > Hello > > How do I get password authentication to work with freeipa-client > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > Long version follows :) > > We've got an IPA server with the Red Hat Identity Management server > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > users and groups there and would now like to login with SSH. When I > store a SSH key for the user account, I can login just fine, using > this SSH key. But I'd like/need to use passwords as well. And sudo > also doesn't work, when it's asking for passwords - I supposed, > it's the same root cause. > > Let's stick with SSH. > > Initially, I installed the FreeIPA client with this command line: > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > --enable-dns-updates --unattended \ > --principal=admin --password=correctone \ > --domain=customer.company.internal \ > --server=auth01.customer.company.internal > > I then try to do a SSH login with: > > ssh -l ewt at customer.company.internal 192.168.229.143 > or: > ssh -l ewt 192.168.229.143 > > Password authentication doesn't work. > > In the /var/log/syslog on the system where I try to login, I find this: > > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: > Key table entry not found > > After having turned up the debug level of the sssd with "sssd -i -f -d > 0x0770 --debug-timestamps=1", I find the following in the system log > files: > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=212.71.117.1 user=ewt > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=212.71.117.1 user=ewt > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > pam_sss(sshd:auth): received for user ewt: 4 (System error) > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > password for ewt from 212.71.117.1 port 58136 ssh2 > > TBH, I don't quite understand it. Anyway, in > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [read_pipe_handler] (0x0400): EOF received, client finished > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [parse_krb5_child_response] (0x0020): message too short. > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [krb5_auth_done] (0x0040): Could not parse child response [22]: > Invalid argument > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > Well? What am I doing wrong or what might I have forgotten? We need to also see the krb5_child.log but please check if the keytab is correct (ie kinit -k works). From aebruno2 at buffalo.edu Fri Oct 2 16:00:59 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Fri, 2 Oct 2015 12:00:59 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151002135647.GA18409@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> Message-ID: <20151002160059.GB18409@dead.ccr.buffalo.edu> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: > What's the best way to re-initialize a replica? > > Suppose one of your replicas goes south.. is there a command to tell > that replicate to re-initialize from the first master (instead of > removing/re-adding the replica from the topology)? Found the command I was looking for: ipa-replica-manage re-initialize --from xxx However, one of our replicates is down and can't seem to re-initialize it. Starting ipa fails (via systemctl restart ipa): ipactl status Directory Service: RUNNING krb5kdc Service: STOPPED kadmin Service: STOPPED named Service: STOPPED ipa_memcached Service: STOPPED httpd Service: STOPPED pki-tomcatd Service: STOPPED ipa-otpd Service: STOPPED ipa: INFO: The ipactl command was successful Errors from the dirsrv show: : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) Attempting to re-initialize fails: ipa-replica-manage re-initialize --from master Connection timed out. I verified time is in sync and DNS forward/reverse resolution is working. Any pointers on what else to try? Thanks! --Andrew From nathan at nathanpeters.com Fri Oct 2 20:57:06 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 2 Oct 2015 13:57:06 -0700 Subject: [Freeipa-users] Can not post to list - email floats off into cyberspace Message-ID: <865a08ab5754d6162b3a363c7d73860a.squirrel@webmail.nathanpeters.com> We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. We have no per zone forwarding enabled, only a single global forwarder. This seems to work fine, but then after a while (several weeks I think) will randomly stop working. We had this issue several weeks ago on a different IPA domain (identical setup) in our production network but it was ignored because a server restart fixed it. This issue then re-surfaced in our development domain today (different network, different physical hardware, same OS and IPA versions). I received a report today from a developer that he could not ping a machine in another domain so I verified network connectivity and everything was fine. When I tried to resolve the name from the IPA dc using ping it would fail, but nslookup directly to the forward server worked fine. ipactl showed no issues, and only after I restarted the server did the lookups start working again. Console log below : Using username "myipausername". Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 [myipausername at dc1 ~]$ sudo su - Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 ATTEMPT FIRST PING TO UNRESOLVABLE HOST ======================================= [root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net CHECK IPA STATUS ================ [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful ATTEMPT PING OF GLOBAL FORWARDER ================================ [root at dc1 ~]# ping 10.21.0.14 PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms ^C --- 10.21.0.14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC ========================================================= [root at dc1 ~]# nslookup > server 10.21.0.14 Default server: 10.21.0.14 Address: 10.21.0.14#53 > artifactory.externaldomain.net Server: 10.21.0.14 Address: 10.21.0.14#53 Non-authoritative answer: artifactory.externaldomain.net canonical name = van-artifactory1.externaldomain.net. Name: van-artifactory1.externaldomain.net Address: 10.20.10.14 RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup IS WORKING FROM THIS MACHINE ====================================================================================================== > ^C[root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net [root at dc1 ~]# ping van-artifactory1.externaldomain.net ping: unknown host van-artifactory1.externaldomain.net RESTART IPA SERVICES ==================== [root at dc1 ~]# ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting ipa_memcached Service Restarting httpd Service Restarting pki-tomcatd Service Restarting smb Service Restarting winbind Service Restarting ipa-otpd Service Restarting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful [root at dc1 ~]# ipa dnsconfig-show ipa: ERROR: did not receive Kerberos credentials [root at dc1 ~]# kinit myipausername Password for myipausername at ipadomain.NET: OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING ================================================== [root at dc1 ~]# ipa dnsconfig-show Global forwarders: 10.21.0.14 Allow PTR sync: TRUE PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED ================================================== [root at dc1 ~]# ping artifactory.externaldomain.net PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of data. 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms ^C --- van-artifactory1.externaldomain.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms [root at dc1 ~]# Here are some strange enties from my /var/log/messages relating to errors from today : Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS rrset from cache: not found Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 Looking at the log entries, it appears that there may have been a network connectivity 'blip' (maybe a switch or router was restarted) at some point and even after connectivity was restored, the global forwarding was failing because the "we can't contact our forwarder" status seemed to get stuck in memory. From nathan at nathanpeters.com Thu Oct 1 21:07:00 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 1 Oct 2015 14:07:00 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working Message-ID: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. We have no per zone forwarding enabled, only a single global forwarder. This seems to work fine, but then after a while (several weeks I think) will randomly stop working. We had this issue several weeks ago on a different IPA domain (identical setup) in our production network but it was ignored because a server restart fixed it. This issue then re-surfaced in our development domain today (different network, different physical hardware, same OS and IPA versions). I received a report today from a developer that he could not ping a machine in another domain so I verified network connectivity and everything was fine. When I tried to resolve the name from the IPA dc using ping it would fail, but nslookup directly to the forward server worked fine. ipactl showed no issues, and only after I restarted the server did the lookups start working again. Console log below : Using username "myipausername". Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 [myipausername at dc1 ~]$ sudo su - Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 ATTEMPT FIRST PING TO UNRESOLVABLE HOST ======================================= [root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net CHECK IPA STATUS ================ [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful ATTEMPT PING OF GLOBAL FORWARDER ================================ [root at dc1 ~]# ping 10.21.0.14 PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms ^C --- 10.21.0.14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC ========================================================= [root at dc1 ~]# nslookup > server 10.21.0.14 Default server: 10.21.0.14 Address: 10.21.0.14#53 > artifactory.externaldomain.net Server: 10.21.0.14 Address: 10.21.0.14#53 Non-authoritative answer: artifactory.externaldomain.net canonical name = van-artifactory1.externaldomain.net. Name: van-artifactory1.externaldomain.net Address: 10.20.10.14 RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup IS WORKING FROM THIS MACHINE ====================================================================================================== > ^C[root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net [root at dc1 ~]# ping van-artifactory1.externaldomain.net ping: unknown host van-artifactory1.externaldomain.net RESTART IPA SERVICES ==================== [root at dc1 ~]# ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting ipa_memcached Service Restarting httpd Service Restarting pki-tomcatd Service Restarting smb Service Restarting winbind Service Restarting ipa-otpd Service Restarting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful [root at dc1 ~]# ipa dnsconfig-show ipa: ERROR: did not receive Kerberos credentials [root at dc1 ~]# kinit myipausername Password for myipausername at ipadomain.NET: OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING ================================================== [root at dc1 ~]# ipa dnsconfig-show Global forwarders: 10.21.0.14 Allow PTR sync: TRUE PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED ================================================== [root at dc1 ~]# ping artifactory.externaldomain.net PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of data. 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms ^C --- van-artifactory1.externaldomain.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms [root at dc1 ~]# Here are some strange enties from my /var/log/messages relating to errors from today : Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS rrset from cache: not found Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 Looking at the log entries, it appears that there may have been a network connectivity 'blip' (maybe a switch or router was restarted) at some point and even after connectivity was restored, the global forwarding was failing because the "we can't contact our forwarder" status seemed to get stuck in memory. From nathan at nathanpeters.com Fri Oct 2 23:47:28 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 2 Oct 2015 16:47:28 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> Message-ID: <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> This issue has occured again and I am once again trying to troubleshoot it. show forwarder -------------- -bash-4.2$ ipa dnsconfig-show Global forwarders: 10.21.0.14 Allow PTR sync: TRUE attempt ping ------------ -bash-4.2$ ping stash.externaldomain.net ping: unknown host stash.externaldomain.net -attempt nslookup ----------------- -bash-4.2$ nslookup > stash.externaldomain.net Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find stash.externaldomain.net: NXDOMAIN *comment* : strange it doesn't work against localhost. Lets make sure that localhost lookups work at all : -bash-4.2$ nslookup > google.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: google.com Address: 216.58.216.142 *comment* : yup, I can resolve google.com when talking to localhost... now lets try to talk to the forwarder configured in the global settings ----------------------------------------------------------------------- > server 10.21.0.14 Default server: 10.21.0.14 Address: 10.21.0.14#53 > stash.externaldomain.net Server: 10.21.0.14 Address: 10.21.0.14#53 Non-authoritative answer: stash.externaldomain.net canonical name = git1.externaldomain.net. Name: git1.externaldomain.net Address: 10.20.10.30 more troubleshooting -------------------- I ran wireshark to see what the freeipa server was sending back to the client : 3 0.000393 10.178.0.99 10.178.21.2 DNS 163 Standard query response 0x12ca No such name CNAME git1.externaldomain.net I've never seen a 'no such CNAME' response before. Lets look at the contents of the packet: Frame 4: 163 bytes on wire (1304 bits), 163 bytes captured (1304 bits) Ethernet II, Src: Vmware_b7:09:c6 (00:50:56:b7:09:c6), Dst: HewlettP_3c:f9:48 (2c:59:e5:3c:f9:48) Internet Protocol Version 4, Src: 10.178.0.99 (10.178.0.99), Dst: 10.178.21.2 (10.178.21.2) User Datagram Protocol, Src Port: 53 (53), Dst Port: 57374 (57374) Domain Name System (response) [Request In: 1] [Time: 0.000414000 seconds] Transaction ID: 0x12ca Flags: 0x8183 Standard query response, No such name 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0011 = Reply code: No such name (3) Questions: 1 Answer RRs: 1 Authority RRs: 1 Additional RRs: 0 Queries stash.externaldomain.net: type A, class IN Name: stash.externaldomain.net [Name Length: 21] [Label Count: 3] Type: A (Host Address) (1) Class: IN (0x0001) Answers stash.externaldomain.net: type CNAME, class IN, cname git1.externaldomain.net Name: stash.externaldomain.net Type: CNAME (Canonical NAME for an alias) (5) Class: IN (0x0001) Time to live: 22483 Data length: 20 CNAME: git1.externaldomain.net Authoritative nameservers externaldomain.net: type SOA, class IN, mname van-dns1.externaldomain.net Name: externaldomain.net Type: SOA (Start Of a zone of Authority) (6) Class: IN (0x0001) Time to live: 518 Data length: 38 Primary name server: van-dns1.externaldomain.net Responsible authority's mailbox: tech.externaldomain.net Serial Number: 2015092101 Refresh Interval: 10800 (3 hours) Retry Interval: 900 (15 minutes) Expire limit: 604800 (7 days) Minimum TTL: 86400 (1 day) > We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. > > We have no per zone forwarding enabled, only a single global forwarder. > This seems to work fine, but then after a while (several weeks I think) > will randomly stop working. > > We had this issue several weeks ago on a different IPA domain (identical > setup) in our production network but it was ignored because a server > restart fixed it. > > This issue then re-surfaced in our development domain today (different > network, different physical hardware, same OS and IPA versions). > > I received a report today from a developer that he could not ping a > machine in another domain so I verified network connectivity and > everything was fine. When I tried to resolve the name from the IPA dc > using ping it would fail, but nslookup directly to the forward server > worked fine. > > ipactl showed no issues, and only after I restarted the server did the > lookups start working again. > > Console log below : > > Using username "myipausername". > Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 > [myipausername at dc1 ~]$ sudo su - > Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 > > ATTEMPT FIRST PING TO UNRESOLVABLE HOST > ======================================= > [root at dc1 ~]# ping artifactory.externaldomain.net > ping: unknown host artifactory.externaldomain.net > > CHECK IPA STATUS > ================ > [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > ATTEMPT PING OF GLOBAL FORWARDER > ================================ > [root at dc1 ~]# ping 10.21.0.14 > PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. > 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms > 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms > ^C > --- 10.21.0.14 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms > rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms > > MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC > ========================================================= > [root at dc1 ~]# nslookup >> server 10.21.0.14 > Default server: 10.21.0.14 > Address: 10.21.0.14#53 >> artifactory.externaldomain.net > Server: 10.21.0.14 > Address: 10.21.0.14#53 > > Non-authoritative answer: > artifactory.externaldomain.net canonical name = > van-artifactory1.externaldomain.net. > Name: van-artifactory1.externaldomain.net > Address: 10.20.10.14 > > RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup > IS WORKING FROM THIS MACHINE > ====================================================================================================== >> ^C[root at dc1 ~]# ping artifactory.externaldomain.net > ping: unknown host artifactory.externaldomain.net > [root at dc1 ~]# ping van-artifactory1.externaldomain.net > ping: unknown host van-artifactory1.externaldomain.net > > RESTART IPA SERVICES > ==================== > [root at dc1 ~]# ipactl restart > Restarting Directory Service > Restarting krb5kdc Service > Restarting kadmin Service > Restarting named Service > Restarting ipa_memcached Service > Restarting httpd Service > Restarting pki-tomcatd Service > Restarting smb Service > Restarting winbind Service > Restarting ipa-otpd Service > Restarting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > [root at dc1 ~]# ipa dnsconfig-show > ipa: ERROR: did not receive Kerberos credentials > [root at dc1 ~]# kinit myipausername > Password for myipausername at ipadomain.NET: > > OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING > ================================================== > [root at dc1 ~]# ipa dnsconfig-show > Global forwarders: 10.21.0.14 > Allow PTR sync: TRUE > > PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED > ================================================== > [root at dc1 ~]# ping artifactory.externaldomain.net > PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of > data. > 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms > 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms > 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms > ^C > --- van-artifactory1.externaldomain.net ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2004ms > rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms > [root at dc1 ~]# > > Here are some strange enties from my /var/log/messages relating to errors > from today : > > Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS > rrset from cache: not found > Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) > resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 > Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) > resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 > > Looking at the log entries, it appears that there may have been a network > connectivity 'blip' (maybe a switch or router was restarted) at some point > and even after connectivity was restored, the global forwarding was > failing because the "we can't contact our forwarder" status seemed to get > stuck in memory. > > > -- > 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 > From nathan at nathanpeters.com Sat Oct 3 00:35:51 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 2 Oct 2015 17:35:51 -0700 Subject: [Freeipa-users] Can not post to list - email floats off into cyberspace In-Reply-To: <865a08ab5754d6162b3a363c7d73860a.squirrel@webmail.nathanpeters.com> References: <865a08ab5754d6162b3a363c7d73860a.squirrel@webmail.nathanpeters.com> Message-ID: <96bd919ba55633c42e56096501d78aae.squirrel@webmail.nathanpeters.com> Sorry about this post. I sent this email to the list 3 times over the last 48 hours and it was finally accepted after the 3rd send when I changed the subject to something totally not descriptive of my problem. Original email with original subject also finally posted today :( > We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. > > We have no per zone forwarding enabled, only a single global forwarder. > This seems to work fine, but then after a while (several weeks I think) > will randomly stop working. > > We had this issue several weeks ago on a different IPA domain (identical > setup) in our production network but it was ignored because a server > restart fixed it. > > This issue then re-surfaced in our development domain today (different > network, different physical hardware, same OS and IPA versions). > > I received a report today from a developer that he could not ping a > machine in another domain so I verified network connectivity and > everything was fine. When I tried to resolve the name from the IPA dc > using ping it would fail, but nslookup directly to the forward server > worked fine. > > ipactl showed no issues, and only after I restarted the server did the > lookups start working again. > > Console log below : > > Using username "myipausername". > Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 > [myipausername at dc1 ~]$ sudo su - > Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 > > ATTEMPT FIRST PING TO UNRESOLVABLE HOST > ======================================= > [root at dc1 ~]# ping artifactory.externaldomain.net > ping: unknown host artifactory.externaldomain.net > > CHECK IPA STATUS > ================ > [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > ATTEMPT PING OF GLOBAL FORWARDER > ================================ > [root at dc1 ~]# ping 10.21.0.14 > PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. > 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms > 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms > ^C > --- 10.21.0.14 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1000ms > rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms > > MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC > ========================================================= > [root at dc1 ~]# nslookup >> server 10.21.0.14 > Default server: 10.21.0.14 > Address: 10.21.0.14#53 >> artifactory.externaldomain.net > Server: 10.21.0.14 > Address: 10.21.0.14#53 > > Non-authoritative answer: > artifactory.externaldomain.net canonical name = > van-artifactory1.externaldomain.net. > Name: van-artifactory1.externaldomain.net > Address: 10.20.10.14 > > RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup > IS WORKING FROM THIS MACHINE > ====================================================================================================== >> ^C[root at dc1 ~]# ping artifactory.externaldomain.net > ping: unknown host artifactory.externaldomain.net > [root at dc1 ~]# ping van-artifactory1.externaldomain.net > ping: unknown host van-artifactory1.externaldomain.net > > RESTART IPA SERVICES > ==================== > [root at dc1 ~]# ipactl restart > Restarting Directory Service > Restarting krb5kdc Service > Restarting kadmin Service > Restarting named Service > Restarting ipa_memcached Service > Restarting httpd Service > Restarting pki-tomcatd Service > Restarting smb Service > Restarting winbind Service > Restarting ipa-otpd Service > Restarting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > [root at dc1 ~]# ipa dnsconfig-show > ipa: ERROR: did not receive Kerberos credentials > [root at dc1 ~]# kinit myipausername > Password for myipausername at ipadomain.NET: > > OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING > ================================================== > [root at dc1 ~]# ipa dnsconfig-show > Global forwarders: 10.21.0.14 > Allow PTR sync: TRUE > > PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED > ================================================== > [root at dc1 ~]# ping artifactory.externaldomain.net > PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of > data. > 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms > 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms > 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms > ^C > --- van-artifactory1.externaldomain.net ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2004ms > rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms > [root at dc1 ~]# > > Here are some strange enties from my /var/log/messages relating to errors > from today : > > Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS > rrset from cache: not found > Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) > resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 > Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) > resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 > > Looking at the log entries, it appears that there may have been a network > connectivity 'blip' (maybe a switch or router was restarted) at some point > and even after connectivity was restored, the global forwarding was > failing because the "we can't contact our forwarder" status seemed to get > stuck in memory. > > > -- > 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 > From nathan at nathanpeters.com Fri Oct 2 17:21:57 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 2 Oct 2015 10:21:57 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaking Message-ID: We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. We have no per zone forwarding enabled, only a single global forwarder. This seems to work fine, but then after a while (several weeks I think) will randomly stop working. We had this issue several weeks ago on a different IPA domain (identical setup) in our production network but it was ignored because a server restart fixed it. This issue then re-surfaced in our development domain today (different network, different physical hardware, same OS and IPA versions). I received a report today from a developer that he could not ping a machine in another domain so I verified network connectivity and everything was fine. When I tried to resolve the name from the IPA dc using ping it would fail, but nslookup directly to the forward server worked fine. ipactl showed no issues, and only after I restarted the server did the lookups start working again. Console log below : Using username "myipausername". Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 [myipausername at dc1 ~]$ sudo su - Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 ATTEMPT FIRST PING TO UNRESOLVABLE HOST ======================================= [root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net CHECK IPA STATUS ================ [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful ATTEMPT PING OF GLOBAL FORWARDER ================================ [root at dc1 ~]# ping 10.21.0.14 PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms ^C --- 10.21.0.14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC ========================================================= [root at dc1 ~]# nslookup > server 10.21.0.14 Default server: 10.21.0.14 Address: 10.21.0.14#53 > artifactory.externaldomain.net Server: 10.21.0.14 Address: 10.21.0.14#53 Non-authoritative answer: artifactory.externaldomain.net canonical name = van-artifactory1.externaldomain.net. Name: van-artifactory1.externaldomain.net Address: 10.20.10.14 RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup IS WORKING FROM THIS MACHINE ====================================================================================================== > ^C[root at dc1 ~]# ping artifactory.externaldomain.net ping: unknown host artifactory.externaldomain.net [root at dc1 ~]# ping van-artifactory1.externaldomain.net ping: unknown host van-artifactory1.externaldomain.net RESTART IPA SERVICES ==================== [root at dc1 ~]# ipactl restart Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting ipa_memcached Service Restarting httpd Service Restarting pki-tomcatd Service Restarting smb Service Restarting winbind Service Restarting ipa-otpd Service Restarting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful [root at dc1 ~]# ipa dnsconfig-show ipa: ERROR: did not receive Kerberos credentials [root at dc1 ~]# kinit myipausername Password for myipausername at ipadomain.NET: OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING ================================================== [root at dc1 ~]# ipa dnsconfig-show Global forwarders: 10.21.0.14 Allow PTR sync: TRUE PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED ================================================== [root at dc1 ~]# ping artifactory.externaldomain.net PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of data. 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms ^C --- van-artifactory1.externaldomain.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms [root at dc1 ~]# Here are some strange enties from my /var/log/messages relating to errors from today : Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS rrset from cache: not found Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 Looking at the log entries, it appears that there may have been a network connectivity 'blip' (maybe a switch or router was restarted) at some point and even after connectivity was restored, the global forwarding was failing because the "we can't contact our forwarder" status seemed to get stuck in memory. From janellenicole80 at gmail.com Sun Oct 4 17:25:24 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 4 Oct 2015 10:25:24 -0700 Subject: [Freeipa-users] admin loses access? Message-ID: <56116104.3020404@gmail.com> Hello everyone, Just wondering if anyone knows why this happens from time to time on servers: $ kinit admin kinit: Clients credentials have been revoked while getting initial credentials there are no failed logins to the admin account - not even any login attempts, so it is not like someone is getting the account locked out. Just curious if anyone else has seen in. With 16 masters, it occurs randomly on some hosts, but eventually clears either on its own or with a restart of IPA. However, I just restarted IPA on this server and after about 2-3 minutes it works again. Thank you ~Janelle From harenberg at physik.uni-wuppertal.de Sun Oct 4 19:29:27 2015 From: harenberg at physik.uni-wuppertal.de (Torsten Harenberg) Date: Sun, 4 Oct 2015 21:29:27 +0200 Subject: [Freeipa-users] admin loses access? In-Reply-To: <56116104.3020404@gmail.com> References: <56116104.3020404@gmail.com> Message-ID: <56117E17.2050302@physik.uni-wuppertal.de> Hi Janelle, Am 04.10.2015 um 19:25 schrieb Janelle: > Just wondering if anyone knows why this happens from time to time on > servers: > > $ kinit admin > kinit: Clients credentials have been revoked while getting initial > credentials > > there are no failed logins to the admin account - not even any login > attempts, so it is not like someone is getting the account locked out. > Just curious if anyone else has seen in. With 16 masters, it occurs > randomly on some hosts, but eventually clears either on its own or with > a restart of IPA. However, I just restarted IPA on this server and after > about 2-3 minutes it works again. > I am seeing the same, see my mail "kinit admin not working anymore (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. Actually, wasn't it you who wanted to open a ticket? Have a nice evening, Torsten -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> <> <> Dr. Torsten Harenberg harenberg at physik.uni-wuppertal.de <> <> Bergische Universitaet <> <> FB C - Physik Tel.: +49 (0)202 439-3521 <> <> Gaussstr. 20 Fax : +49 (0)202 439-2811 <> <> 42097 Wuppertal <> <> <> <><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><> From fujisan43 at gmail.com Mon Oct 5 07:17:41 2015 From: fujisan43 at gmail.com (Fujisan) Date: Mon, 5 Oct 2015 09:17:41 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: Good morning, ? Any suggestion what I should do?? ?I still have ?$ ipa user-show admin ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized Regards. On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: > I only have this: > > $ keyctl list @s > 1 key in keyring: > 641467419: --alswrv 0 65534 keyring: _uid.0 > $ > > > > On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy > wrote: > >> On Fri, 02 Oct 2015, Fujisan wrote: >> >>> I forgot to mention that >>> >>> $ ipa user-show admin >>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>> Unauthorized >>> >> This is most likely because of the cached session to your server. >> >> You can check if keyctl list @s >> returns you something like >> [root at m1 ~]# keyctl list @s >> 2 keys in keyring: >> 496745412: --alswrv 0 65534 keyring: _uid.0 >> 215779962: --alswrv 0 0 user: >> ipa_session_cookie:admin at EXAMPLE.COM >> >> If so, then notice the key number (215779962) for the session cookie, >> and do: >> keyctl purge 215779962 >> keyctl reap >> >> This should make a next 'ipa ...' command run to ask for new cookie. >> >> >>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>> >>> I still cannot login to the web UI. >>>> >>>> Here is what I did: >>>> >>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>> 2. kinit admin >>>> Password for admin at OPERA: >>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>> /etc/krb5.keytab >>>> 4. systemctl restart sssd.service >>>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>> /etc/httpd/conf/ipa.keytab >>>> 7. systemctl restart httpd.service >>>> >>>> >>>> The log says now: >>>> >>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 >>>> 17 >>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: HTTP/zaira2.opera at OPERA >>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>> >>>> >>>> >>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy >>>> wrote: >>>> >>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>> >>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>> kerberos. >>>>>> >>>>>> What should I do to fix this? >>>>>> >>>>>> I have this on the ipa server: >>>>>> $ klist -k >>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>> KVNO Principal >>>>>> ---- >>>>>> >>>>>> >>>>>> -------------------------------------------------------------------------- >>>>>> 2 host/zaira2.opera at OPERA >>>>>> 2 host/zaira2.opera at OPERA >>>>>> 2 host/zaira2.opera at OPERA >>>>>> 2 host/zaira2.opera at OPERA >>>>>> 1 nfs/zaira2.opera at OPERA >>>>>> 1 nfs/zaira2.opera at OPERA >>>>>> 1 nfs/zaira2.opera at OPERA >>>>>> 1 nfs/zaira2.opera at OPERA >>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>> >>>>>> You can start by: >>>>>> >>>>> 0. backup every file mentioned below >>>>> 1. Move /etc/krb5.keytab somewhere >>>>> 2. kinit as admin >>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >>>>> 4. restart SSSD >>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>> /etc/httpd/conf/ipa.keytab >>>>> 7. Restart httpd >>>>> >>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>> specified by you is replaced on the server side so that keys in the >>>>> keytabs become unusable. >>>>> >>>>> I guess cockpit instructions were for something that was not supposed >>>>> to >>>>> run on IPA master. On IPA master there are already all needed services >>>>> (host/ and HTTP/) and their keytabs are in place. >>>>> >>>>> >>>>> >>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy >>>>> > >>>>>> wrote: >>>>>> >>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>> >>>>>>> >>>>>>> More info: >>>>>>> >>>>>>>> >>>>>>>> I can initiate a ticket: >>>>>>>> $ kdestroy >>>>>>>> $ kinit admin >>>>>>>> >>>>>>>> but cannot view user admin: >>>>>>>> $ ipa user-show admin >>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>> Unauthorized >>>>>>>> >>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>> >>>>>>>> /var/log/messages: >>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>> initialize >>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>> integrity >>>>>>>> check >>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>> >>>>>>>> What did you do? >>>>>>>> >>>>>>> >>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that you >>>>>>> have >>>>>>> different keys in LDAP and in your keytab files for host/zaira2.opera >>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>> removed >>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>> whatever you have in the keytab files. >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan wrote: >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>> >>>>>>>>> The password or username you entered is incorrect. >>>>>>>>> >>>>>>>>> Log says: >>>>>>>>> >>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>>> {18 17 >>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd >>>>>>>>> 12 >>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>> failed >>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>>> {18 17 >>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd >>>>>>>>> 12 >>>>>>>>> >>>>>>>>> >>>>>>>>> I have no idea what went wrong. >>>>>>>>> >>>>>>>>> What can I do? >>>>>>>>> >>>>>>>>> ?Regards, >>>>>>>>> Fuji? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>> >>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>> >>>>>>> -- >>>>> / 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 >>> >> >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Oct 5 08:03:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 5 Oct 2015 10:03:09 +0200 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> Message-ID: <56122EBD.1030405@redhat.com> On 3.10.2015 01:47, nathan at nathanpeters.com wrote: > This issue has occured again and I am once again trying to troubleshoot it. > > show forwarder > -------------- > -bash-4.2$ ipa dnsconfig-show > Global forwarders: 10.21.0.14 > Allow PTR sync: TRUE > > attempt ping > ------------ > -bash-4.2$ ping stash.externaldomain.net > ping: unknown host stash.externaldomain.net > > -attempt nslookup > ----------------- > -bash-4.2$ nslookup >> stash.externaldomain.net > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > ** server can't find stash.externaldomain.net: NXDOMAIN > > *comment* : strange it doesn't work against localhost. Lets make sure > that localhost lookups work at all : > > -bash-4.2$ nslookup >> google.com > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Non-authoritative answer: > Name: google.com > Address: 216.58.216.142 > > *comment* : yup, I can resolve google.com when talking to localhost... > > now lets try to talk to the forwarder configured in the global settings > ----------------------------------------------------------------------- >> server 10.21.0.14 > Default server: 10.21.0.14 > Address: 10.21.0.14#53 >> stash.externaldomain.net > Server: 10.21.0.14 > Address: 10.21.0.14#53 > > Non-authoritative answer: > stash.externaldomain.net canonical name = git1.externaldomain.net. > Name: git1.externaldomain.net > Address: 10.20.10.30 > > more troubleshooting > -------------------- > I ran wireshark to see what the freeipa server was sending back to the > client : > > 3 0.000393 10.178.0.99 10.178.21.2 DNS 163 Standard query response 0x12ca > No such name CNAME git1.externaldomain.net > > I've never seen a 'no such CNAME' response before. Lets look at the > contents of the packet: > > > Frame 4: 163 bytes on wire (1304 bits), 163 bytes captured (1304 bits) > Ethernet II, Src: Vmware_b7:09:c6 (00:50:56:b7:09:c6), Dst: > HewlettP_3c:f9:48 (2c:59:e5:3c:f9:48) > Internet Protocol Version 4, Src: 10.178.0.99 (10.178.0.99), Dst: > 10.178.21.2 (10.178.21.2) > User Datagram Protocol, Src Port: 53 (53), Dst Port: 57374 (57374) > Domain Name System (response) > [Request In: 1] > [Time: 0.000414000 seconds] > Transaction ID: 0x12ca > Flags: 0x8183 Standard query response, No such name > 1... .... .... .... = Response: Message is a response > .000 0... .... .... = Opcode: Standard query (0) > .... .0.. .... .... = Authoritative: Server is not an authority > for domain > .... ..0. .... .... = Truncated: Message is not truncated > .... ...1 .... .... = Recursion desired: Do query recursively > .... .... 1... .... = Recursion available: Server can do recursive > queries > .... .... .0.. .... = Z: reserved (0) > .... .... ..0. .... = Answer authenticated: Answer/authority > portion was not authenticated by the server > .... .... ...0 .... = Non-authenticated data: Unacceptable > .... .... .... 0011 = Reply code: No such name (3) > Questions: 1 > Answer RRs: 1 > Authority RRs: 1 > Additional RRs: 0 > Queries > stash.externaldomain.net: type A, class IN > Name: stash.externaldomain.net > [Name Length: 21] > [Label Count: 3] > Type: A (Host Address) (1) > Class: IN (0x0001) > Answers > stash.externaldomain.net: type CNAME, class IN, cname > git1.externaldomain.net > Name: stash.externaldomain.net > Type: CNAME (Canonical NAME for an alias) (5) > Class: IN (0x0001) > Time to live: 22483 > Data length: 20 > CNAME: git1.externaldomain.net > Authoritative nameservers > externaldomain.net: type SOA, class IN, mname > van-dns1.externaldomain.net > Name: externaldomain.net > Type: SOA (Start Of a zone of Authority) (6) > Class: IN (0x0001) > Time to live: 518 > Data length: 38 > Primary name server: van-dns1.externaldomain.net > Responsible authority's mailbox: tech.externaldomain.net > Serial Number: 2015092101 > Refresh Interval: 10800 (3 hours) > Retry Interval: 900 (15 minutes) > Expire limit: 604800 (7 days) > Minimum TTL: 86400 (1 day) > > >> We have a FreeIPA domain running IPA server 4.1.4 on CentOS 7. >> >> We have no per zone forwarding enabled, only a single global forwarder. >> This seems to work fine, but then after a while (several weeks I think) >> will randomly stop working. >> >> We had this issue several weeks ago on a different IPA domain (identical >> setup) in our production network but it was ignored because a server >> restart fixed it. >> >> This issue then re-surfaced in our development domain today (different >> network, different physical hardware, same OS and IPA versions). >> >> I received a report today from a developer that he could not ping a >> machine in another domain so I verified network connectivity and >> everything was fine. When I tried to resolve the name from the IPA dc >> using ping it would fail, but nslookup directly to the forward server >> worked fine. >> >> ipactl showed no issues, and only after I restarted the server did the >> lookups start working again. >> >> Console log below : >> >> Using username "myipausername". >> Last login: Thu Oct 1 16:36:51 2015 from 10.5.5.57 >> [myipausername at dc1 ~]$ sudo su - >> Last login: Tue Sep 29 19:03:39 UTC 2015 on pts/3 >> >> ATTEMPT FIRST PING TO UNRESOLVABLE HOST >> ======================================= >> [root at dc1 ~]# ping artifactory.externaldomain.net >> ping: unknown host artifactory.externaldomain.net >> >> CHECK IPA STATUS >> ================ >> [root at dc1 ~]# 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-dnskeysyncd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> ATTEMPT PING OF GLOBAL FORWARDER >> ================================ >> [root at dc1 ~]# ping 10.21.0.14 >> PING 10.21.0.14 (10.21.0.14) 56(84) bytes of data. >> 64 bytes from 10.21.0.14: icmp_seq=1 ttl=64 time=0.275 ms >> 64 bytes from 10.21.0.14: icmp_seq=2 ttl=64 time=0.327 ms >> ^C >> --- 10.21.0.14 ping statistics --- >> 2 packets transmitted, 2 received, 0% packet loss, time 1000ms >> rtt min/avg/max/mdev = 0.275/0.301/0.327/0.026 ms >> >> MANUAL NSLOOKUP OF DOMAIN ON GLOBAL FORWARDER FROM IPA DC >> ========================================================= >> [root at dc1 ~]# nslookup >>> server 10.21.0.14 >> Default server: 10.21.0.14 >> Address: 10.21.0.14#53 >>> artifactory.externaldomain.net >> Server: 10.21.0.14 >> Address: 10.21.0.14#53 >> >> Non-authoritative answer: >> artifactory.externaldomain.net canonical name = >> van-artifactory1.externaldomain.net. >> Name: van-artifactory1.externaldomain.net >> Address: 10.20.10.14 >> >> RE-ATTEMPT PING SINCE WE KNOW THAT NAME RESOLUTION (at least via nslookup >> IS WORKING FROM THIS MACHINE >> ====================================================================================================== >>> ^C[root at dc1 ~]# ping artifactory.externaldomain.net >> ping: unknown host artifactory.externaldomain.net >> [root at dc1 ~]# ping van-artifactory1.externaldomain.net >> ping: unknown host van-artifactory1.externaldomain.net >> >> RESTART IPA SERVICES >> ==================== >> [root at dc1 ~]# ipactl restart >> Restarting Directory Service >> Restarting krb5kdc Service >> Restarting kadmin Service >> Restarting named Service >> Restarting ipa_memcached Service >> Restarting httpd Service >> Restarting pki-tomcatd Service >> Restarting smb Service >> Restarting winbind Service >> Restarting ipa-otpd Service >> Restarting ipa-dnskeysyncd Service >> ipa: INFO: The ipactl command was successful >> [root at dc1 ~]# ipa dnsconfig-show >> ipa: ERROR: did not receive Kerberos credentials >> [root at dc1 ~]# kinit myipausername >> Password for myipausername at ipadomain.NET: >> >> OUTPUT GLOBAL FORWARDER CONFIG FOR TROUBLESHOOTING >> ================================================== >> [root at dc1 ~]# ipa dnsconfig-show >> Global forwarders: 10.21.0.14 >> Allow PTR sync: TRUE >> >> PING NOW WORKS BECAUSE IPA SERVICES WERE RESTARTED >> ================================================== >> [root at dc1 ~]# ping artifactory.externaldomain.net >> PING van-artifactory1.externaldomain.net (10.20.10.14) 56(84) bytes of >> data. >> 64 bytes from 10.20.10.14: icmp_seq=1 ttl=60 time=3.00 ms >> 64 bytes from 10.20.10.14: icmp_seq=2 ttl=60 time=1.42 ms >> 64 bytes from 10.20.10.14: icmp_seq=3 ttl=60 time=2.39 ms >> ^C >> --- van-artifactory1.externaldomain.net ping statistics --- >> 3 packets transmitted, 3 received, 0% packet loss, time 2004ms >> rtt min/avg/max/mdev = 1.420/2.274/3.004/0.653 ms >> [root at dc1 ~]# >> >> Here are some strange enties from my /var/log/messages relating to errors >> from today : >> >> Oct 1 20:39:31 dc1 named-pkcs11[15066]: checkhints: unable to get root NS >> rrset from cache: not found >> Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) >> resolving 'pmdb1.ipadomain.net/A/IN': 2001:500:2f::f#53 >> Oct 1 20:39:17 dc1 named-pkcs11[15066]: error (network unreachable) >> resolving 'pmdb1.ipadomain.net/AAAA/IN': 2001:500:2f::f#53 >> >> Looking at the log entries, it appears that there may have been a network >> connectivity 'blip' (maybe a switch or router was restarted) at some point >> and even after connectivity was restored, the global forwarding was >> failing because the "we can't contact our forwarder" status seemed to get >> stuck in memory. Most likely. >> [root at dc1 ~]# ipa dnsconfig-show >> Global forwarders: 10.21.0.14 >> Allow PTR sync: TRUE This means that you are using the default forward policy which is 'first'. I.e. BIND daemon on the IPA server is trying to use the forwarder first and when it fails it fallbacks to asking server on the public Internet. I speculate that public servers know nothing about the name you were asking for and this negative answer got cached. This is default behavior in BIND and IPA did not change it. Workaround for network problems could be $ ipa dnsconfig-mod --forward-policy=only which will prevent BIND from falling back to public servers. Anyway, you should solve network connectivity problems, too :-) I hope this helps. -- Petr^2 Spacek From andreas.calminder at nordnet.se Mon Oct 5 08:58:40 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Mon, 5 Oct 2015 10:58:40 +0200 Subject: [Freeipa-users] Sudo default options Message-ID: <56123BC0.3010208@nordnet.se> Hi, guessing this is a quite frequent question, but I can't find any solid information about the topic. I want to specify a set of default sudo options so I don't have to specify these options for every other sudo rule I create. There's supposed to be a magic "defaults" rule. This old document (https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) suggests it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in my ipa 4.1 installation others suggest it's under ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no way to be sure. Also, might it be as simple as create a defaults rule in the webui or cli with the default options set or is this a ldapmodify action? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexanders.mailinglists+nospam at gmail.com Mon Oct 5 07:00:13 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Mon, 5 Oct 2015 09:00:13 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: <20151002155951.GB3127@hendrix.redhat.com> References: <20151002155951.GB3127@hendrix.redhat.com> Message-ID: Hi Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try to login with SSH and enter a password. kinit doesn't work. $ kinit -k kinit: Permission denied while getting initial credentials For this test, I was root and then did a "su - user" and then "kinit -k". Also after the "kinit -k", nothing is in the krb5_child.log. Regards, Alexander 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > > Hello > > > > How do I get password authentication to work with freeipa-client > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > > > Long version follows :) > > > > We've got an IPA server with the Red Hat Identity Management server > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > > users and groups there and would now like to login with SSH. When I > > store a SSH key for the user account, I can login just fine, using > > this SSH key. But I'd like/need to use passwords as well. And sudo > > also doesn't work, when it's asking for passwords - I supposed, > > it's the same root cause. > > > > Let's stick with SSH. > > > > Initially, I installed the FreeIPA client with this command line: > > > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > > --enable-dns-updates --unattended \ > > --principal=admin --password=correctone \ > > --domain=customer.company.internal \ > > --server=auth01.customer.company.internal > > > > I then try to do a SSH login with: > > > > ssh -l ewt at customer.company.internal 192.168.229.143 > > or: > > ssh -l ewt 192.168.229.143 > > > > Password authentication doesn't work. > > > > In the /var/log/syslog on the system where I try to login, I find this: > > > > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: > > Key table entry not found > > > > After having turned up the debug level of the sssd with "sssd -i -f -d > > 0x0770 --debug-timestamps=1", I find the following in the system log > > files: > > > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > > pam_sss(sshd:auth): received for user ewt: 4 (System error) > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > > password for ewt from 212.71.117.1 port 58136 ssh2 > > > > TBH, I don't quite understand it. Anyway, in > > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > [read_pipe_handler] (0x0400): EOF received, client finished > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > [parse_krb5_child_response] (0x0020): message too short. > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > [krb5_auth_done] (0x0040): Could not parse child response [22]: > > Invalid argument > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > > > Well? What am I doing wrong or what might I have forgotten? > > We need to also see the krb5_child.log but please check if the keytab is > correct (ie kinit -k works). > > -- > 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 > -- Alexander -- => *Google+* => http://plus.skwar.me <== => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrezina at redhat.com Mon Oct 5 09:29:06 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Mon, 05 Oct 2015 11:29:06 +0200 Subject: [Freeipa-users] Sudo default options In-Reply-To: <56123BC0.3010208@nordnet.se> References: <56123BC0.3010208@nordnet.se> Message-ID: <561242E2.2070000@redhat.com> On 10/05/2015 10:58 AM, Andreas Calminder wrote: > Hi, > guessing this is a quite frequent question, but I can't find any solid > information about the topic. > I want to specify a set of default sudo options so I don't have to > specify these options for every other sudo rule I create. > There's supposed to be a magic "defaults" rule. > This old document > (https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) suggests > it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in > my ipa 4.1 installation others suggest it's under > ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it > could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no > way to be sure. Also, might it be as simple as create a defaults rule in > the webui or cli with the default options set or is this a ldapmodify > action? Hi, just create a sudo rule named "defaults" through ipa cli or wui. From fujisan43 at gmail.com Mon Oct 5 10:13:21 2015 From: fujisan43 at gmail.com (Fujisan) Date: Mon, 5 Oct 2015 12:13:21 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: I uninstalled the ipa server and reinstalled it. Then restored the backup. And then the following: $ keyctl list @s 3 keys in keyring: 437165764: --alswrv 0 65534 keyring: _uid.0 556579409: --alswrv 0 0 user: ipa_session_cookie:host/zaira2.opera at OPERA 286806445: ---lswrv 0 65534 keyring: _persistent.0 $ keyctl purge 556579409 purged 0 keys $ keyctl reap 0 keys reaped $ ipa user-show admin ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized $ keyctl list @s 3 keys in keyring: 437165764: --alswrv 0 65534 keyring: _uid.0 556579409: --alswrv 0 0 user: ipa_session_cookie:host/zaira2.opera at OPERA 286806445: ---lswrv 0 65534 keyring: _persistent.0 ?It doesn't seem to purge or to reap.? On Mon, Oct 5, 2015 at 9:17 AM, Fujisan wrote: > Good morning, > ? > Any suggestion what I should do?? > > ?I still have > > ?$ ipa user-show admin > ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': > Unauthorized > > > Regards. > > > On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: > >> I only have this: >> >> $ keyctl list @s >> 1 key in keyring: >> 641467419: --alswrv 0 65534 keyring: _uid.0 >> $ >> >> >> >> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy >> wrote: >> >>> On Fri, 02 Oct 2015, Fujisan wrote: >>> >>>> I forgot to mention that >>>> >>>> $ ipa user-show admin >>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>> Unauthorized >>>> >>> This is most likely because of the cached session to your server. >>> >>> You can check if keyctl list @s >>> returns you something like >>> [root at m1 ~]# keyctl list @s >>> 2 keys in keyring: >>> 496745412: --alswrv 0 65534 keyring: _uid.0 >>> 215779962: --alswrv 0 0 user: >>> ipa_session_cookie:admin at EXAMPLE.COM >>> >>> If so, then notice the key number (215779962) for the session cookie, >>> and do: >>> keyctl purge 215779962 >>> keyctl reap >>> >>> This should make a next 'ipa ...' command run to ask for new cookie. >>> >>> >>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>>> >>>> I still cannot login to the web UI. >>>>> >>>>> Here is what I did: >>>>> >>>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>>> 2. kinit admin >>>>> Password for admin at OPERA: >>>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>>> /etc/krb5.keytab >>>>> 4. systemctl restart sssd.service >>>>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>>> /etc/httpd/conf/ipa.keytab >>>>> 7. systemctl restart httpd.service >>>>> >>>>> >>>>> The log says now: >>>>> >>>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes {18 >>>>> 17 >>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>> HTTP/zaira2.opera at OPERA >>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>> >>>>> >>>>> >>>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy >>>> > >>>>> wrote: >>>>> >>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>> >>>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>>> kerberos. >>>>>>> >>>>>>> What should I do to fix this? >>>>>>> >>>>>>> I have this on the ipa server: >>>>>>> $ klist -k >>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>> KVNO Principal >>>>>>> ---- >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------------- >>>>>>> 2 host/zaira2.opera at OPERA >>>>>>> 2 host/zaira2.opera at OPERA >>>>>>> 2 host/zaira2.opera at OPERA >>>>>>> 2 host/zaira2.opera at OPERA >>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>> >>>>>>> You can start by: >>>>>>> >>>>>> 0. backup every file mentioned below >>>>>> 1. Move /etc/krb5.keytab somewhere >>>>>> 2. kinit as admin >>>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >>>>>> 4. restart SSSD >>>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>>> /etc/httpd/conf/ipa.keytab >>>>>> 7. Restart httpd >>>>>> >>>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>>> specified by you is replaced on the server side so that keys in the >>>>>> keytabs become unusable. >>>>>> >>>>>> I guess cockpit instructions were for something that was not supposed >>>>>> to >>>>>> run on IPA master. On IPA master there are already all needed services >>>>>> (host/ and HTTP/) and their keytabs are in place. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy < >>>>>>> abokovoy at redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>> >>>>>>>> >>>>>>>> More info: >>>>>>>> >>>>>>>>> >>>>>>>>> I can initiate a ticket: >>>>>>>>> $ kdestroy >>>>>>>>> $ kinit admin >>>>>>>>> >>>>>>>>> but cannot view user admin: >>>>>>>>> $ ipa user-show admin >>>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>>> Unauthorized >>>>>>>>> >>>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>>> >>>>>>>>> /var/log/messages: >>>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>>> initialize >>>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>>> integrity >>>>>>>>> check >>>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>>> >>>>>>>>> What did you do? >>>>>>>>> >>>>>>>> >>>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that you >>>>>>>> have >>>>>>>> different keys in LDAP and in your keytab files for >>>>>>>> host/zaira2.opera >>>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>>> removed >>>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>>> whatever you have in the keytab files. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>>> >>>>>>>>>> The password or username you entered is incorrect. >>>>>>>>>> >>>>>>>>>> Log says: >>>>>>>>>> >>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>>>> {18 17 >>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd >>>>>>>>>> 12 >>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>>> failed >>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 etypes >>>>>>>>>> {18 17 >>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down fd >>>>>>>>>> 12 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I have no idea what went wrong. >>>>>>>>>> >>>>>>>>>> What can I do? >>>>>>>>>> >>>>>>>>>> ?Regards, >>>>>>>>>> Fuji? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> >>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> / Alexander Bokovoy >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>> / 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 >>>> >>> >>> >>> -- >>> / Alexander Bokovoy >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Mon Oct 5 10:27:04 2015 From: fujisan43 at gmail.com (Fujisan) Date: Mon, 5 Oct 2015 12:27:04 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: I just noticed I can log in to the web UI with user admin and his password. But when I try to configure firefox to use kerberos, I click on "Install Kerberos Configuration Firefox Extension" button, a message appears saying "Firefox prevented this site from asking you to install software on your computer", so I click on the "Allow" button and then another message appears "The add-on downloaded from this site could not be installed because it appears to be corrupt.". And the ipa commands are still not working. $ ipa user-show admin ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': Unauthorized On Mon, Oct 5, 2015 at 12:13 PM, Fujisan wrote: > I uninstalled the ipa server and reinstalled it. Then restored the backup. > And then the following: > > $ keyctl list @s > 3 keys in keyring: > 437165764: --alswrv 0 65534 keyring: _uid.0 > 556579409: --alswrv 0 0 user: > ipa_session_cookie:host/zaira2.opera at OPERA > 286806445: ---lswrv 0 65534 keyring: _persistent.0 > $ keyctl purge 556579409 > purged 0 keys > $ keyctl reap > 0 keys reaped > $ ipa user-show admin > ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': > Unauthorized > $ keyctl list @s > 3 keys in keyring: > 437165764: --alswrv 0 65534 keyring: _uid.0 > 556579409: --alswrv 0 0 user: > ipa_session_cookie:host/zaira2.opera at OPERA > 286806445: ---lswrv 0 65534 keyring: _persistent.0 > > ?It doesn't seem to purge or to reap.? > > > > On Mon, Oct 5, 2015 at 9:17 AM, Fujisan wrote: > >> Good morning, >> ? >> Any suggestion what I should do?? >> >> ?I still have >> >> ?$ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> >> >> Regards. >> >> >> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: >> >>> I only have this: >>> >>> $ keyctl list @s >>> 1 key in keyring: >>> 641467419: --alswrv 0 65534 keyring: _uid.0 >>> $ >>> >>> >>> >>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy >>> wrote: >>> >>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>> >>>>> I forgot to mention that >>>>> >>>>> $ ipa user-show admin >>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>> Unauthorized >>>>> >>>> This is most likely because of the cached session to your server. >>>> >>>> You can check if keyctl list @s >>>> returns you something like >>>> [root at m1 ~]# keyctl list @s >>>> 2 keys in keyring: >>>> 496745412: --alswrv 0 65534 keyring: _uid.0 >>>> 215779962: --alswrv 0 0 user: >>>> ipa_session_cookie:admin at EXAMPLE.COM >>>> >>>> If so, then notice the key number (215779962) for the session cookie, >>>> and do: >>>> keyctl purge 215779962 >>>> keyctl reap >>>> >>>> This should make a next 'ipa ...' command run to ask for new cookie. >>>> >>>> >>>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>>>> >>>>> I still cannot login to the web UI. >>>>>> >>>>>> Here is what I did: >>>>>> >>>>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>>>> 2. kinit admin >>>>>> Password for admin at OPERA: >>>>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>>>> /etc/krb5.keytab >>>>>> 4. systemctl restart sssd.service >>>>>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>>>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>>>> /etc/httpd/conf/ipa.keytab >>>>>> 7. systemctl restart httpd.service >>>>>> >>>>>> >>>>>> The log says now: >>>>>> >>>>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes >>>>>> {18 17 >>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>> HTTP/zaira2.opera at OPERA >>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy < >>>>>> abokovoy at redhat.com> >>>>>> wrote: >>>>>> >>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>> >>>>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>>>> kerberos. >>>>>>>> >>>>>>>> What should I do to fix this? >>>>>>>> >>>>>>>> I have this on the ipa server: >>>>>>>> $ klist -k >>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>> KVNO Principal >>>>>>>> ---- >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------------------------------- >>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>> >>>>>>>> You can start by: >>>>>>>> >>>>>>> 0. backup every file mentioned below >>>>>>> 1. Move /etc/krb5.keytab somewhere >>>>>>> 2. kinit as admin >>>>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k /etc/krb5.keytab >>>>>>> 4. restart SSSD >>>>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>> 7. Restart httpd >>>>>>> >>>>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>>>> specified by you is replaced on the server side so that keys in the >>>>>>> keytabs become unusable. >>>>>>> >>>>>>> I guess cockpit instructions were for something that was not >>>>>>> supposed to >>>>>>> run on IPA master. On IPA master there are already all needed >>>>>>> services >>>>>>> (host/ and HTTP/) and their keytabs are in place. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy < >>>>>>>> abokovoy at redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> More info: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can initiate a ticket: >>>>>>>>>> $ kdestroy >>>>>>>>>> $ kinit admin >>>>>>>>>> >>>>>>>>>> but cannot view user admin: >>>>>>>>>> $ ipa user-show admin >>>>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>>>> Unauthorized >>>>>>>>>> >>>>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>>>> >>>>>>>>>> /var/log/messages: >>>>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>>>> initialize >>>>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>>>> integrity >>>>>>>>>> check >>>>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>>>> >>>>>>>>>> What did you do? >>>>>>>>>> >>>>>>>>> >>>>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that >>>>>>>>> you have >>>>>>>>> different keys in LDAP and in your keytab files for >>>>>>>>> host/zaira2.opera >>>>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>>>> removed >>>>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>>>> whatever you have in the keytab files. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>>>> >>>>>>>>>>> The password or username you entered is incorrect. >>>>>>>>>>> >>>>>>>>>>> Log says: >>>>>>>>>>> >>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>> etypes >>>>>>>>>>> {18 17 >>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>> fd 12 >>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>>>> failed >>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>> etypes >>>>>>>>>>> {18 17 >>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>> fd 12 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have no idea what went wrong. >>>>>>>>>>> >>>>>>>>>>> What can I do? >>>>>>>>>>> >>>>>>>>>>> ?Regards, >>>>>>>>>>> Fuji? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> / Alexander Bokovoy >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>> / 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 >>>>> >>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.calminder at nordnet.se Mon Oct 5 10:27:30 2015 From: andreas.calminder at nordnet.se (Andreas Calminder) Date: Mon, 5 Oct 2015 12:27:30 +0200 Subject: [Freeipa-users] Sudo default options In-Reply-To: <561242E2.2070000@redhat.com> References: <56123BC0.3010208@nordnet.se> <561242E2.2070000@redhat.com> Message-ID: <56125092.3060109@nordnet.se> All right, Thanks a million! /andreas On 10/05/2015 11:29 AM, Pavel B?ezina wrote: > On 10/05/2015 10:58 AM, Andreas Calminder wrote: >> Hi, >> guessing this is a quite frequent question, but I can't find any solid >> information about the topic. >> I want to specify a set of default sudo options so I don't have to >> specify these options for every other sudo rule I create. >> There's supposed to be a magic "defaults" rule. >> This old document >> (https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf) >> suggests >> it's cn=defaults,ou=sudorules,dc=example,dc=com which doesn't exist in >> my ipa 4.1 installation others suggest it's under >> ou=sudoers,dc=example,dc=com when poking around in ldap it looks like it >> could also be cn=sudorules,cn=sudo,dc=example,dc=com, but there is no >> way to be sure. Also, might it be as simple as create a defaults rule in >> the webui or cli with the default options set or is this a ldapmodify >> action? > > Hi, > just create a sudo rule named "defaults" through ipa cli or wui. From mkosek at redhat.com Mon Oct 5 10:40:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 5 Oct 2015 12:40:42 +0200 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151002160059.GB18409@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> Message-ID: <561253AA.4050509@redhat.com> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: > On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: >> What's the best way to re-initialize a replica? >> >> Suppose one of your replicas goes south.. is there a command to tell >> that replicate to re-initialize from the first master (instead of >> removing/re-adding the replica from the topology)? > > Found the command I was looking for: > ipa-replica-manage re-initialize --from xxx > > However, one of our replicates is down and can't seem to re-initialize > it. Starting ipa fails (via systemctl restart ipa): > > ipactl status > Directory Service: RUNNING > krb5kdc Service: STOPPED > kadmin Service: STOPPED > named Service: STOPPED > ipa_memcached Service: STOPPED > httpd Service: STOPPED > pki-tomcatd Service: STOPPED > ipa-otpd Service: STOPPED > ipa: INFO: The ipactl command was successful > > > Errors from the dirsrv show: > > : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) > [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > > > Attempting to re-initialize fails: > > ipa-replica-manage re-initialize --from master > Connection timed out. > > > I verified time is in sync and DNS forward/reverse resolution is working. > > Any pointers on what else to try? > > Thanks! > > --Andrew Given that your Kerberos server instance is down, I would start investigating Kerberos logs to see why. From fujisan43 at gmail.com Mon Oct 5 10:55:50 2015 From: fujisan43 at gmail.com (Fujisan) Date: Mon, 5 Oct 2015 12:55:50 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: It is actually on the ipa server that ipa commands are not working. On ipa clients, I do not have errors. On Mon, Oct 5, 2015 at 12:27 PM, Fujisan wrote: > I just noticed I can log in to the web UI with user admin and his password. > > But when I try to configure firefox to use kerberos, I click on "Install > Kerberos Configuration Firefox Extension" button, a message appears saying > "Firefox prevented this site from asking you to install software on your > computer", so I click on the "Allow" button and then another message > appears "The add-on downloaded from this site could not be installed > because it appears to be corrupt.". > > And the ipa commands are still not working. > $ ipa user-show admin > ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': > Unauthorized > > > On Mon, Oct 5, 2015 at 12:13 PM, Fujisan wrote: > >> I uninstalled the ipa server and reinstalled it. Then restored the backup. >> And then the following: >> >> $ keyctl list @s >> 3 keys in keyring: >> 437165764: --alswrv 0 65534 keyring: _uid.0 >> 556579409: --alswrv 0 0 user: >> ipa_session_cookie:host/zaira2.opera at OPERA >> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >> $ keyctl purge 556579409 >> purged 0 keys >> $ keyctl reap >> 0 keys reaped >> $ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> $ keyctl list @s >> 3 keys in keyring: >> 437165764: --alswrv 0 65534 keyring: _uid.0 >> 556579409: --alswrv 0 0 user: >> ipa_session_cookie:host/zaira2.opera at OPERA >> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >> >> ?It doesn't seem to purge or to reap.? >> >> >> >> On Mon, Oct 5, 2015 at 9:17 AM, Fujisan wrote: >> >>> Good morning, >>> ? >>> Any suggestion what I should do?? >>> >>> ?I still have >>> >>> ?$ ipa user-show admin >>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>> Unauthorized >>> >>> >>> Regards. >>> >>> >>> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: >>> >>>> I only have this: >>>> >>>> $ keyctl list @s >>>> 1 key in keyring: >>>> 641467419: --alswrv 0 65534 keyring: _uid.0 >>>> $ >>>> >>>> >>>> >>>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy >>>> wrote: >>>> >>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>> >>>>>> I forgot to mention that >>>>>> >>>>>> $ ipa user-show admin >>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>> Unauthorized >>>>>> >>>>> This is most likely because of the cached session to your server. >>>>> >>>>> You can check if keyctl list @s >>>>> returns you something like >>>>> [root at m1 ~]# keyctl list @s >>>>> 2 keys in keyring: >>>>> 496745412: --alswrv 0 65534 keyring: _uid.0 >>>>> 215779962: --alswrv 0 0 user: >>>>> ipa_session_cookie:admin at EXAMPLE.COM >>>>> >>>>> If so, then notice the key number (215779962) for the session cookie, >>>>> and do: >>>>> keyctl purge 215779962 >>>>> keyctl reap >>>>> >>>>> This should make a next 'ipa ...' command run to ask for new cookie. >>>>> >>>>> >>>>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>>>>> >>>>>> I still cannot login to the web UI. >>>>>>> >>>>>>> Here is what I did: >>>>>>> >>>>>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>>>>> 2. kinit admin >>>>>>> Password for admin at OPERA: >>>>>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>>>>> /etc/krb5.keytab >>>>>>> 4. systemctl restart sssd.service >>>>>>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>>>>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>> 7. systemctl restart httpd.service >>>>>>> >>>>>>> >>>>>>> The log says now: >>>>>>> >>>>>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes >>>>>>> {18 17 >>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>> HTTP/zaira2.opera at OPERA >>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy < >>>>>>> abokovoy at redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>> >>>>>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>>>>> kerberos. >>>>>>>>> >>>>>>>>> What should I do to fix this? >>>>>>>>> >>>>>>>>> I have this on the ipa server: >>>>>>>>> $ klist -k >>>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>>> KVNO Principal >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>> >>>>>>>>> You can start by: >>>>>>>>> >>>>>>>> 0. backup every file mentioned below >>>>>>>> 1. Move /etc/krb5.keytab somewhere >>>>>>>> 2. kinit as admin >>>>>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k >>>>>>>> /etc/krb5.keytab >>>>>>>> 4. restart SSSD >>>>>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>>> 7. Restart httpd >>>>>>>> >>>>>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>>>>> specified by you is replaced on the server side so that keys in the >>>>>>>> keytabs become unusable. >>>>>>>> >>>>>>>> I guess cockpit instructions were for something that was not >>>>>>>> supposed to >>>>>>>> run on IPA master. On IPA master there are already all needed >>>>>>>> services >>>>>>>> (host/ and HTTP/) and their keytabs are in place. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy < >>>>>>>>> abokovoy at redhat.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> More info: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can initiate a ticket: >>>>>>>>>>> $ kdestroy >>>>>>>>>>> $ kinit admin >>>>>>>>>>> >>>>>>>>>>> but cannot view user admin: >>>>>>>>>>> $ ipa user-show admin >>>>>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>>>>> Unauthorized >>>>>>>>>>> >>>>>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>>>>> >>>>>>>>>>> /var/log/messages: >>>>>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>>>>> initialize >>>>>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>>>>> integrity >>>>>>>>>>> check >>>>>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>>>>> >>>>>>>>>>> What did you do? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that >>>>>>>>>> you have >>>>>>>>>> different keys in LDAP and in your keytab files for >>>>>>>>>> host/zaira2.opera >>>>>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>>>>> removed >>>>>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>>>>> whatever you have in the keytab files. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>>>>> >>>>>>>>>>>> The password or username you entered is incorrect. >>>>>>>>>>>> >>>>>>>>>>>> Log says: >>>>>>>>>>>> >>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>> etypes >>>>>>>>>>>> {18 17 >>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>> fd 12 >>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>>>>> failed >>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>> etypes >>>>>>>>>>>> {18 17 >>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>> fd 12 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I have no idea what went wrong. >>>>>>>>>>>> >>>>>>>>>>>> What can I do? >>>>>>>>>>>> >>>>>>>>>>>> ?Regards, >>>>>>>>>>>> Fuji? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> / Alexander Bokovoy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>> / 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Mon Oct 5 11:16:41 2015 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 5 Oct 2015 13:16:41 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <560D4BFA.2040303@mittwald.de> References: <560D4BFA.2040303@mittwald.de> Message-ID: <56125C19.5010307@redhat.com> On 10/01/2015 05:06 PM, Dominik Korittki wrote: > Hello folks, > > I am running two FreeIPA Servers with around 100 users and around 15.000 > hosts, which are used by users to login via ssh. The FreeIPA servers > (which are Centos 7.0) ran good for a while, but as more and more hosts > got migrated to serve as FreeIPA hosts, it started to get slow and > unstable. > > For example, its hard to maintain hostgroups, which have more than 1.000 > hosts. The ipa host-* commands are getting slower as the hostgroup > grows. Is this normal? > We also experience random dirsrv segfaults. Here's a dmesg line from the > latest: > > [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 > sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] > > Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the > problem. > I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that > solve my problems? > > FreeIPA server version is 3.3.3-28.el7.centos > 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 > > > > Kind regards, > Dominik Korittki > Hi Dominik, performance issues are a known problem, there has been some work to improve the performance with respect to large groups: 11bd9d96f191066f7ba760549f00179c128a9787 efcd48ad01a39a67f131a2cea9d54771642222fb These improvements are in FreeIPA 4.2 only, however, which has not been released for CentOS7 as of now. You may try to play with FreeIPA 4.2 on Fedora, see https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/. HTH, Tomas From alexanders.mailinglists+nospam at gmail.com Mon Oct 5 11:39:48 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Mon, 5 Oct 2015 13:39:48 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: <20151002155951.GB3127@hendrix.redhat.com> Message-ID: Hi Hm, when I'm root, "kinit -k" works: # kinit -k # Just not as a user. As a user, I get the "kinit: Permission denied while getting initial credentials" error message. Regards, Alexander 2015-10-05 9:00 GMT+02:00 Alexander Skwar < alexanders.mailinglists+nospam at gmail.com>: > Hi > > Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try > to login with SSH and enter a password. > > kinit doesn't work. > > $ kinit -k > kinit: Permission denied while getting initial credentials > > For this test, I was root and then did a "su - user" and then "kinit -k". > Also after the "kinit -k", nothing is in the krb5_child.log. > > Regards, > Alexander > > > 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > >> On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: >> > Hello >> > >> > How do I get password authentication to work with freeipa-client >> > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? >> > >> > Long version follows :) >> > >> > We've got an IPA server with the Red Hat Identity Management server >> > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured >> > users and groups there and would now like to login with SSH. When I >> > store a SSH key for the user account, I can login just fine, using >> > this SSH key. But I'd like/need to use passwords as well. And sudo >> > also doesn't work, when it's asking for passwords - I supposed, >> > it's the same root cause. >> > >> > Let's stick with SSH. >> > >> > Initially, I installed the FreeIPA client with this command line: >> > >> > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ >> > --enable-dns-updates --unattended \ >> > --principal=admin --password=correctone \ >> > --domain=customer.company.internal \ >> > --server=auth01.customer.company.internal >> > >> > I then try to do a SSH login with: >> > >> > ssh -l ewt at customer.company.internal 192.168.229.143 >> > or: >> > ssh -l ewt 192.168.229.143 >> > >> > Password authentication doesn't work. >> > >> > In the /var/log/syslog on the system where I try to login, I find this: >> > >> > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: >> > Key table entry not found >> > >> > After having turned up the debug level of the sssd with "sssd -i -f -d >> > 0x0770 --debug-timestamps=1", I find the following in the system log >> > files: >> > >> > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: >> > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 >> > tty=ssh ruser= rhost=212.71.117.1 user=ewt >> > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: >> > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 >> > tty=ssh ruser= rhost=212.71.117.1 user=ewt >> > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: >> > pam_sss(sshd:auth): received for user ewt: 4 (System error) >> > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed >> > password for ewt from 212.71.117.1 port 58136 ssh2 >> > >> > TBH, I don't quite understand it. Anyway, in >> > /var/log/sssd/sssd_customer.company.internal.log I noticed: >> > >> > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] >> > [read_pipe_handler] (0x0400): EOF received, client finished >> > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] >> > [parse_krb5_child_response] (0x0020): message too short. >> > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] >> > [krb5_auth_done] (0x0040): Could not parse child response [22]: >> > Invalid argument >> > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] >> > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. >> > >> > Well? What am I doing wrong or what might I have forgotten? >> >> We need to also see the krb5_child.log but please check if the keytab is >> correct (ie kinit -k works). >> >> -- >> 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 >> > > > > -- > > > Alexander > -- > => *Google+* => http://plus.skwar.me <== > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > > > -- Alexander -- => *Google+* => http://plus.skwar.me <== => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Oct 5 12:07:44 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 5 Oct 2015 14:07:44 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: <20151002155951.GB3127@hendrix.redhat.com> Message-ID: <20151005120744.GB19585@p.redhat.com> On Mon, Oct 05, 2015 at 09:00:13AM +0200, Alexander Skwar wrote: > Hi > > Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try > to login with SSH and enter a password. Can you try to increase the debug_level to 0xFFF0? > > kinit doesn't work. > > $ kinit -k > kinit: Permission denied while getting initial credentials > > For this test, I was root and then did a "su - user" and then "kinit -k". > Also after the "kinit -k", nothing is in the krb5_child.log. The 'kinit -k' has to be done as root. It will only check if the client can connect to the KDC at all and tries to get a TGT for the host. It's expected that during this operation nothing is added to the SSSD logs because the kinit utility work independent of SSSD. bye, Sumit > > Regards, > Alexander > > > 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > > > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > > > Hello > > > > > > How do I get password authentication to work with freeipa-client > > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > > > > > Long version follows :) > > > > > > We've got an IPA server with the Red Hat Identity Management server > > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > > > users and groups there and would now like to login with SSH. When I > > > store a SSH key for the user account, I can login just fine, using > > > this SSH key. But I'd like/need to use passwords as well. And sudo > > > also doesn't work, when it's asking for passwords - I supposed, > > > it's the same root cause. > > > > > > Let's stick with SSH. > > > > > > Initially, I installed the FreeIPA client with this command line: > > > > > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > > > --enable-dns-updates --unattended \ > > > --principal=admin --password=correctone \ > > > --domain=customer.company.internal \ > > > --server=auth01.customer.company.internal > > > > > > I then try to do a SSH login with: > > > > > > ssh -l ewt at customer.company.internal 192.168.229.143 > > > or: > > > ssh -l ewt 192.168.229.143 > > > > > > Password authentication doesn't work. > > > > > > In the /var/log/syslog on the system where I try to login, I find this: > > > > > > 2015-10-02T15:33:38.771291+02:00 mgmt02 [sssd[krb5_child[14154]]]: > > > Key table entry not found > > > > > > After having turned up the debug level of the sssd with "sssd -i -f -d > > > 0x0770 --debug-timestamps=1", I find the following in the system log > > > files: > > > > > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > > > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > > > pam_sss(sshd:auth): received for user ewt: 4 (System error) > > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > > > password for ewt from 212.71.117.1 port 58136 ssh2 > > > > > > TBH, I don't quite understand it. Anyway, in > > > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > [read_pipe_handler] (0x0400): EOF received, client finished > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > [parse_krb5_child_response] (0x0020): message too short. > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > [krb5_auth_done] (0x0040): Could not parse child response [22]: > > > Invalid argument > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > > > > > Well? What am I doing wrong or what might I have forgotten? > > > > We need to also see the krb5_child.log but please check if the keytab is > > correct (ie kinit -k works). > > > > -- > > 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 > > > > > > -- > > > Alexander > -- > => *Google+* => http://plus.skwar.me <== > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > -- > 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 From d.korittki at mittwald.de Mon Oct 5 12:13:31 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Mon, 5 Oct 2015 14:13:31 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <560D8EE7.8080004@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> Message-ID: <5612696B.7050601@mittwald.de> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: > Dominik Korittki wrote: >> Hello folks, >> >> I am running two FreeIPA Servers with around 100 users and around 15.000 >> hosts, which are used by users to login via ssh. The FreeIPA servers >> (which are Centos 7.0) ran good for a while, but as more and more hosts >> got migrated to serve as FreeIPA hosts, it started to get slow and >> unstable. >> >> For example, its hard to maintain hostgroups, which have more than 1.000 >> hosts. The ipa host-* commands are getting slower as the hostgroup >> grows. Is this normal? > > You mean the ipa hostgroup-* commands? Whenever the entry is displayed > (show and add) it needs to dereference all members so yes, it is > understandable that it gets somewhat slower with more members. How slow > are we talking about? > >> We also experience random dirsrv segfaults. Here's a dmesg line from the >> latest: >> >> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 >> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] > > You probably want to start here: > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes A stacktrace from the latest crash is attached to this email. After restarting the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors (hostname is ipa01.internal): [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for LDAPS requests [05/Oct/2015:13:51:30 +0200] - Listening on /var/run/slapd-INTERNAL.socket for LDAPI requests [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN 54bea480000000600000 not found, we aren't as up to date, or we purged [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data required to update replica has been purged. The replica must be reinitialized. [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Incremental update failed and requires administrator action [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth resumed These lines are present since a replayed a ldif dump from ipa02 to ipa01, but i didn't think that it related to the segfault problem (therefore i said there are no related problems in the logfile). But I am starting to believe that these errors could be in relation to each other. Kind regards, Dominik Korittki > > >> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >> problem. Not sure about that anymore. >> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that >> solve my problems? >> >> FreeIPA server version is 3.3.3-28.el7.centos >> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >> >> >> >> Kind regards, >> Dominik Korittki >> > > > > -------------- next part -------------- GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/ns-slapd...Reading symbols from /usr/lib/debug/usr/sbin/ns-slapd.debug...done. done. [New LWP 28096] [New LWP 28100] [New LWP 28074] [New LWP 28109] [New LWP 28098] [New LWP 27931] [New LWP 28079] [New LWP 28073] [New LWP 28103] [New LWP 28077] [New LWP 28076] [New LWP 28101] [New LWP 27930] [New LWP 28071] [New LWP 28084] [New LWP 28075] [New LWP 28102] [New LWP 27928] [New LWP 28121] [New LWP 28086] [New LWP 28099] [New LWP 28092] [New LWP 28094] [New LWP 28104] [New LWP 28091] [New LWP 27929] [New LWP 28106] [New LWP 28088] [New LWP 28081] [New LWP 28082] [New LWP 28090] [New LWP 28095] [New LWP 28083] [New LWP 28085] [New LWP 28108] [New LWP 28089] [New LWP 28093] [New LWP 28078] [New LWP 28097] [New LWP 28087] [New LWP 28107] [New LWP 28808] [New LWP 28080] [New LWP 28072] [New LWP 28105] [New LWP 27927] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-INTERNAL -i /var/run/dirsrv/slapd-INTER'. Program terminated with signal 11, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 31 movdqu (%rdi), %xmm1 Thread 46 (Thread 0x7ff9ee409840 (LWP 27927)): #0 0x00007ff9ebc44e0d in poll () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9ec57cb97 in poll (__timeout=250, __nfds=90, __fds=0x7ff9efb5db00) at /usr/include/bits/poll2.h:46 No locals. #2 _pr_poll_with_poll (pds=0x7ff9f14bee80, npds=npds at entry=90, timeout=timeout at entry=250) at ../../../nspr/pr/src/pthreads/ptio.c:3922 stack_syspoll = {{fd = 50282600, events = 32767, revents = 0}, {fd = -1, events = 0, revents = 0}, {fd = 50282592, events = 32767, revents = 0}, {fd = -302831930, events = 32761, revents = 0}, {fd = -262928752, events = 32761, revents = 0}, {fd = -302556435, events = 32761, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 50282600, events = 32767, revents = 0}, {fd = -302328358, events = 32761, revents = 0}, {fd = -259132376, events = 32761, revents = 0}, {fd = -259132376, events = 32761, revents = 0}, {fd = -259132376, events = 32761, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = -252312688, events = 32761, revents = 0}, {fd = -273276224, events = 32761, revents = 0}, {fd = 50282616, events = 32767, revents = 0}, {fd = 50282596, events = 32767, revents = 0}, {fd = -253383952, events = 1, revents = 0}, {fd = 50282392, events = 32767, revents = 0}, {fd = -254462112, events = 32761, revents = 0}, {fd = -255798320, events = 32761, revents = 0}, {fd = -253383952, events = 32761, revents = 0}, {fd = 0, events = 0, revents = 0}, {fd = 5, events = 0, revents = 0}, {fd = -266137912, events = 32761, revents = 0}, {fd = -256981432, events = 32761, revents = 0}, {fd = -267500112, events = 32761, revents = 0}, {fd = -256981432, events = 32761, revents = 0}, {fd = -256981432, events = 32761, revents = 0}, {fd = -256981432, events = 32761, revents = 0}, {fd = 50282720, events = 32767, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = -245466232, events = 32761, revents = 0}, {fd = -299955300, events = 32761, revents = 0}, {fd = -302831930, events = 32761, revents = 0}, {fd = 16, events = 0, revents = 0}, {fd = -302341650, events = 32761, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = -256981448, events = 32761, revents = 0}, {fd = 50282544, events = 32767, revents = 0}, {fd = 50282592, events = 32767, revents = 0}, {fd = 50282624, events = 32767, revents = 0}, {fd = 50282720, events = 32767, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = -245466232, events = 32761, revents = 0}, {fd = -299955300, events = 32761, revents = 0}, {fd = 50282648, events = 32767, revents = 0}, {fd = 144, events = 0, revents = 0}, {fd = 50282720, events = 32767, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = 50282680, events = 32767, revents = 0}, {fd = 144, events = 0, revents = 0}, {fd = 50282720, events = 32767, revents = 0}, {fd = -254438416, events = 32761, revents = 0}, {fd = -245466232, events = 32761, revents = 0}, {fd = -299955300, events = 32761, revents = 0}, {fd = -302831930, events = 32761, revents = 0}, {fd = -256062448, events = 32761, revents = 0}, {fd = -254438400, events = 32761, revents = 0}, {fd = 1, events = 0, revents = 0}, {fd = -302463804, events = 32761, revents = 0}, {fd = -245497432, events = 32761, revents = 0}, {fd = -299955300, events = 32761, revents = 0}} syspoll = index = msecs = 250 ready = start = 415435113 elapsed = remaining = #3 0x00007ff9ec57f6d5 in PR_Poll (pds=, npds=npds at entry=90, timeout=timeout at entry=250) at ../../../nspr/pr/src/pthreads/ptio.c:4324 No locals. #4 0x00007ff9ee440bf9 in slapd_daemon (ports=ports at entry=0x7fff02ff43f0) at ldap/servers/slapd/daemon.c:1168 select_return = 0 prerr = n_tcps = 0x7ff9ef986390 s_tcps = 0x7ff9ef986480 i_unix = 0x7ff9ef9863e0 fdesp = 0x0 num_poll = 90 pr_timeout = 250 time_thread_p = 0x7ff9f0c0aaa0 threads = in_referral_mode = 0 n_listeners = 3 listener_idxs = 0x7ff9f06cf980 #5 0x00007ff9ee4346d5 in main (argc=7, argv=0x7fff02ff4a08) at ldap/servers/slapd/main.c:1273 return_value = 0 slapdFrontendConfig = ports_info = {n_port = 389, s_port = 636, n_listenaddr = 0x7ff9ef9864a0, s_listenaddr = 0x7ff9ef9879e0, n_socket = 0x7ff9ef986390, i_listenaddr = 0x7ff9ef9879c0, i_port = 1, i_socket = 0x7ff9ef9863e0, s_socket = 0x7ff9ef986480} m = Thread 45 (Thread 0x7ff9b67ec700 (LWP 28105)): #0 0x00007ff9e53c5340 in __rawmemchr at plt () from /usr/lib64/dirsrv/plugins/libacl-plugin.so No symbol table info available. #1 0x00007ff9e53c7e83 in acl_match_substring (f=, str=str at entry=0x7ff9451a91c0 "uid=user1,cn=users,cn=compat,dc=internal", exact_match=exact_match at entry=0) at ldap/servers/plugins/acl/acl.c:3250 i = rc = len = p = 0x7ff9b67e0bc0 "^" end = 0x7ff9b67e2bbe "" realval = tmp = 0x0 pat = "^\000*idnsname=.*,cn=dns,dc=internal$\000ternal$\000E\371\177", '\000' , "`|\032E\371\177\000\000\000\031Z\000p\tv\331\024\016~\266\371\177\000\000\260y\032E\371\177\000\000\000\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000\024\016~\266\371\177\000\000\260y\032E\371\177\000\000\000\000\000\000\000\000\000\000\021\022\367\355\371\177", '\000' , "\002\000\000\000\360?\357\371\177\000\000\300\f~\266\371\177\000\000\260\f~\266\371\177\000\000\000\031Z\000p\tv\331\000\000\000\000\000\000\000\000o"... buf = "uid=user1,cn=users,cn=compat,dc=internal\000al\000\000l\000l", '\000' , "\250\034\321\336\371\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000?\365\345\371\177\000\000o\004\000\000\000\000\000\000\070\341\312\336\371\177\000\000?\315\336\371\177\000\000>\365\342\345\371\177\000\000~\n\000\000\000\000\000\000\070\341\312\336\371\177\000\000w\004\000\000\000\000\000\000\240,~\266\371\177\000\000\220,~\266\371\177\000\000\210,~\266\371\177\000\000\260B\354\336\371\177\000\000\000\000\000\000\000\000\000\000"... type = 0x7ff9f06708e0 "target" initial = 0x7ff9efda8d50 "cn=" final = 0x7ff9f01b6fd0 ",ou=sudoers,dc=internal" any = 0x0 re = 0x0 re_result = 0x0 #2 0x00007ff9e53c83c6 in acl__resource_match_aci (aclpb=aclpb at entry=0x7ff9f127b480, aci=aci at entry=0x7ff9f10a5ce0, skip_attrEval=skip_attrEval at entry=1, a_matched=a_matched at entry=0x0) at ldap/servers/plugins/acl/acl.c:2104 f = rv = matches = attr_matched = 1 attr_matched_in_targetattrfilters = 0 dn_matched = 1 res_attr = aci_right = 7 res_right = 2 star_matched = 0 num_attrs = 0 c_attrEval = 0x0 res_ndn = 0x7ff9451a91c0 "uid=user1,cn=users,cn=compat,dc=internal" aci_ndn = 0x7ff9f02d30e0 "dc=internal" matched_val = 0x0 add_matched_val_to_ht = 0 res_right_str = "\004\000\000\000\000\000\000\000?\353\371\177\000\000-\000\000\000\000\000\000\000\236y\032E\371\177\000\000\037\000\000\000\000\000\000\000\272\370\275\353\371\177\000\000\060\256\357\360\371\177\000\000\000M~\266\371\177\000\000\000M~\266\371\177\000\000\001\000\000\000\000\000\000\000 \347\243D\371\177\000\000\071\246\363\355\371\177\000\000`\250\266\360\371\177\000\000\374v=\345\371\177\000\000\200\264'\361\371\177\000\000X\200=\345\371\177\000" #3 0x00007ff9e53ca016 in acl__scan_match_handles (type=2, aclpb=0x7ff9f127b480) at ldap/servers/plugins/acl/acl.c:3609 aci = 0x7ff9f10a5ce0 cookie = 0 c_evalContext = 0x7ff9f127bed8 matched = 3 index = 54 #4 acl__match_handlesFromCache (access=-249053480, attr=0x7ff9451a8fe0 "uid", aclpb=0x7ff9f127b480) at ldap/servers/plugins/acl/acl.c:3826 c_evalContext = 0x7ff9f127bed8 context_type = 2 ret_val = -1 #5 acl_access_allowed (pb=, e=e at entry=0x7ff9efe3b740, attr=attr at entry=0x7ff9451a8fe0 "uid", val=, access=access at entry=2) at ldap/servers/plugins/acl/acl.c:552 n_edn = 0x7ff9f104ba10 "uid=user1,cn=users,cn=compat,dc=internal" rv = err = ret_val = right = 0x7ff9e53e1c7f "search" aclpb = 0x7ff9f127b480 c_attrEval = 0x0 got_reader_locked = 1 deallocate_attrEval = 0 clientDn = 0x7ff9440075e0 "uid=user2,cn=sysaccounts,cn=etc,dc=internal" e_sdn = op = 0x7ff9f04c7f10 decision_reason = {deciding_aci = 0x0, reason = ACL_REASON_NONE} loglevel = #6 0x00007ff9e53dbf47 in acl_access_allowed_main (pb=, e=0x7ff9efe3b740, attrs=, val=, access=2, flags=, errbuf=0x0) at ldap/servers/plugins/acl/aclplugin.c:383 rc = 0 attr = 0x7ff9451a8fe0 "uid" #7 0x00007ff9edf7ecec in plugin_call_acl_plugin (pb=pb at entry=0x7ff9f0dc7ef0, e=e at entry=0x7ff9efe3b740, attrs=attrs at entry=0x7ff9b67e4f10, val=val at entry=0x7ff9451a2068, access=access at entry=2, flags=flags at entry=0, errbuf=errbuf at entry=0x0) at ldap/servers/slapd/plugin_acl.c:90 p = 0x7ff9ef952430 rc = 50 aclplugin_initialized = 1 operation = 0x7ff9f04c7f10 #8 0x00007ff9edf4d216 in test_ava_filter (pb=0x7ff9f0dc7ef0, e=e at entry=0x7ff9efe3b740, a=0x7ff9eff73a20, ava=0x7ff9451a2060, ftype=163, verify_access=1, only_check_access=0, access_check_done=0x7ff9b67e4fd4) at ldap/servers/slapd/filterentry.c:330 attrs = {0x7ff9451a8fe0 "uid", 0x0} rc = #9 0x00007ff9edf4e29f in slapi_filter_test_ext_internal (pb=, e=0x7ff9efe3b740, f=0x7ff9451a2040, verify_access=1, only_check_access=0, access_check_done=access_check_done at entry=0x7ff9b67e4fd4) at ldap/servers/slapd/filterentry.c:160 rc = #10 0x00007ff9edf4e78a in slapi_filter_test_ext (pb=0x7ff9f0dc7ef0, e=0x7ff9efe3b740, f=0x7ff9451a2040, verify_access=1, only_check_access=only_check_access at entry=0) at ldap/servers/slapd/filterentry.c:274 rc = 0 access_check_done = 0 #11 0x00007ff9edf4e7b8 in slapi_filter_test (pb=, e=, f=, verify_access=) at ldap/servers/slapd/filterentry.c:96 No locals. #12 0x00007ff9e0cf1414 in backend_search_entry_cb (domain=, map=, secure=, key=, key_len=, value=, value_len=44, id=0x7ff9f06f6a60 "uid=user1,cn=users,cn=accounts,dc=internal", key_index=0, backend_data=0x7ff9f0025620, cb_data=0x7ff9b67e51e0) at back-sch.c:1011 sdn = 0x7ff9efe3b740 cbdata = 0x7ff9b67e51e0 entry_data = 0x7ff9f0025620 result = #13 0x00007ff9e0d04043 in map_data_foreach_entry (state=, cbdata=0x7ff9b67e51e0, fn=0x7ff9e0cf1390 , id=, map_name=, domain_name=) at map.c:271 i = 0 k = 0 domain = 0x7ff9f09d6990 j = 3 map = 0x7ff9efd47fc8 entry = 0x7ff9f0763800 #14 map_data_foreach_entry_id (state=, domain=domain at entry=0x7ff9efce6b40 "cn=compat,dc=internal", map=map at entry=0x7ff9f03748d0 "cn=users", id=id at entry=0x0, fn=fn at entry=0x7ff9e0cf1390 , cbdata=cbdata at entry=0x7ff9b67e51e0) at map.c:305 No locals. #15 0x00007ff9e0cf353b in backend_search_set_cb (group=0x7ff9efce6b40 "cn=compat,dc=internal", set=0x7ff9f03748d0 "cn=users", flag=, backend_data=0x7ff9f05089a0, cb_data=0x7ff9b67e51e0) at back-sch.c:1103 cbdata = 0x7ff9b67e51e0 set_data = 0x7ff9f05089a0 set_entry = result = n_entries = n_entries_without_nsswitch = 0 ndn = #16 0x00007ff9e0d0417f in map_data_foreach_map (state=, domain_name=domain_name at entry=0x7ff9efce6b40 "cn=compat,dc=internal", fn=fn at entry=0x7ff9e0cf33b0 , cbdata=cbdata at entry=0x7ff9b67e51e0) at map.c:347 i = 0 j = 3 domain = 0x7ff9f09d6990 map = #17 0x00007ff9e0cf3286 in backend_search_group_cb (group=0x7ff9efce6b40 "cn=compat,dc=internal", cb_data=0x7ff9b67e51e0) at back-sch.c:1214 cbdata = 0x7ff9b67e51e0 group_dn = 0x7ff9451a9200 group_entry = result = n_maps = #18 0x00007ff9e0d040c0 in map_data_foreach_domain (state=, fn=fn at entry=0x7ff9e0cf31a0 , cbdata=cbdata at entry=0x7ff9b67e51e0) at map.c:317 i = 0 #19 0x00007ff9e0cf2df4 in backend_search_cb (pb=0x7ff9f0dc7ef0) at back-sch.c:1311 cbdata = {pb = 0x7ff9f0dc7ef0, state = 0x7ff9efa24780, target = 0x7ff9451a8d90 "cn=users,cn=compat,dc=internal", strfilter = 0x7ff944672fd0 "(uid=user3)", attrs = 0x0, scope = 1, sizelimit = 1, timelimit = 5, attrsonly = 0, check_access = 1, check_nsswitch = SCH_NSSWITCH_NONE, target_dn = 0x7ff9451a8660, filter = 0x7ff9451a2040, nsswitch_min_id = 1000, nsswitch_buffer = 0x0, nsswitch_buffer_len = 0, answer = 0, result = 0, matched = 1, closest_match = 0x0, text = 0x0, n_entries = 1, staged = 0x0, cur_staged = 0x0} staged = next = i = pb = 0x7ff9f0dc7ef0 #20 0x00007ff9edf7be85 in plugin_call_func (list=0x7ff9efa2c360, operation=operation at entry=403, pb=pb at entry=0x7ff9f0dc7ef0, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7ff9e0cf29e0 rc = return_value = 0 count = 16 #21 0x00007ff9edf7c038 in plugin_call_list (pb=0x7ff9f0dc7ef0, operation=403, list=) at ldap/servers/slapd/plugin.c:1415 No locals. #22 plugin_call_plugins (pb=pb at entry=0x7ff9f0dc7ef0, whichfunction=whichfunction at entry=403) at ldap/servers/slapd/plugin.c:398 p = 0x7ff9ef9ef4c0 plugin_list_number = 1 rc = 0 do_op = #23 0x00007ff9edf726c6 in op_shared_search (pb=pb at entry=0x7ff9f0dc7ef0, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:565 base = 0x7ff9451a7cb0 "cn=users,cn=compat,dc=internal" normbase = fstr = 0x7ff944672fd0 "(uid=user3)" scope = 1 be = 0x7ff9efb5c380 be_single = 0x0 be_list = {0x7ff9efb5c380, 0x0, 0x22cd010004, 0x396565663d010025, 0x3762622d37383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22cc010004, 0x396565663d010025, 0x3762622d36383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22cb010004, 0x396565663d010025, 0x0, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22ca010004, 0x396565663d010025, 0x3762622d34383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22c9010004, 0x396565663d010025, 0x3762622d33383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22c8010004, 0x396565663d010025, 0x3762622d32383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x22c7010004, 0x396565663d010025, 0x3762622d31383164, 0x34382d3465313164, 0x342d633163646363, 0x38373530363138, 0x1fe7010004, 0x643766663d010025, 0x6261612d31383364, 0x34382d3465313162, 0x342d633163646363, 0x38373530363138, 0x1c1d010004, 0x346466663d010025, 0x3462392d32303032, 0x33612d3465313138, 0x342d633163643134, 0x38373530363138, 0x1c1c010004, 0x346466663d010025, 0x3462392d31303032, 0x33612d3465313138, 0x342d633163643134, 0x38373530363138, 0x1a59010004, 0x613465663d010025, 0x3262392d32306532, 0x33612d3465313166, 0x342d633163643134, 0x38373530363138, 0x1a58010004, 0x613465663d010025, 0x3262392d31306532, 0x33612d3465313166, 0x342d633163643134, 0x38373530363138, 0x18b2010004, 0x366465663d010025, 0x3761392d31306362, 0x33612d3465313165, 0x342d633163643134, 0x38373530363138, 0x16dc010004, 0x633865663d010025, 0x3035382d31393465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16db010004, 0x633865663d010025, 0x3035382d30393465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16da010004, 0x633865663d010025, 0x3035382d66383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d9010004, 0x633865663d010025, 0x3035382d65383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d8010004, 0x633865663d010025, 0x3035382d64383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d7010004, 0x633865663d010025, 0x3035382d63383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d6010004, 0x633865663d010025, 0x3035382d62383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d5010004, 0x633865663d010025, 0x3035382d61383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d4010004, 0x633865663d010025, 0x3035382d39383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d3010004, 0x633865663d010025, 0x3035382d38383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d2010004, 0x633865663d010025, 0x3035382d37383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d1010004, 0x633865663d010025, 0x3035382d35383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16d0010004, 0x633865663d010025, 0x3035382d34383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16cf010004, 0x633865663d010025, 0x3035382d33383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16ce010004, 0x633865663d010025, 0x3035382d32383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x16cd010004, 0x633865663d010025, 0x3035382d31383465, 0x33382d3465313133, 0x342d633163643663, 0x38373530363138, 0x1649010004, 0x323166663d010025, 0x6434382d31383438, 0x33382d3465313164, 0x342d633163643663, 0x38373530363138, 0x1458010004, 0x366465663d010025, 0x3634382d66383261, 0x33382d3465313135, 0x342d633163643663, 0x38373530363138, 0x1457010004, 0x366465663d010025, 0x3634382d65383261, 0x33382d3465313135, 0x342d633163643663, 0x38373530363138, 0x1456010004, 0x366465663d010025, 0x3634382d63383261, 0x33382d3465313135, 0x342d633163643663, 0x38373530363138...} referral_list = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7ff944652978, 0xd9760970005a1900, 0x7ff9f0fea910, 0xd9760970005a1900, 0x7ff9f0f5f9a0, 0x7ff9edf3b229 , 0x7ff9f0ded010, 0x7ff9edf3b2a0 , 0x7ff9efa04ab0, 0x7ff9f0dc10b0, 0x7ff945361720, 0x7ff9ec57b180 , 0x7ff9f0dc10b0, 0x7ff9edf7012e , 0x800000000, 0x7ff9f1091350, 0x7ff9f1091350, 0x7ff9b67e7528, 0x0, 0x7ff9b67e7528, 0x7ff9b67e7540, 0x0, 0x7ff9efa04ab0, 0x7ff9edf326c6 , 0x7ff945361720, 0x7ff9b67e7540, 0x0, 0x0, 0x7ff945238270, 0x7ff9b67e7540, 0x7ff945361720, 0x7ff9edf326c6 , 0x0, 0x7ff9452385e8, 0x7ff945238538, 0x7ff9452385c0, 0x7ff945238538, 0x7ff945238538, 0x7ff945238538, 0x0, 0x7ff9ee1fc400 , 0x7ff944652f30, 0x7ff945361720, 0x7ff9edf326c6 , 0x10, 0x7ff9edfaa1ee , 0x7ff9ee1fc400 , 0x7ff945238528, 0x7ff9b67e75d0, 0x7ff9b67e7600, 0x7ff9b67e7620, 0x0, 0x7ff9ee1fc400 , 0x7ff944652f30, 0x7ff945361720, 0x7ff9b67e7638, 0x18, 0x7ff944652398, 0x1, 0x0, 0x7ff9ee1fc400 , 0x7ff944652f30, 0x7ff945361720, 0x7ff9b67e7730, 0x18, 0x0, 0x7ff9ee1fc400 , 0x7ff944652f30, 0x7ff945361720, 0x7ff9edf326c6 , 0x2, 0x7ff9edf6bb13 , 0x7ff9b67e7788, 0x0, 0x7ff9b67e77c0, 0x20ecef6817, 0x7ff945361720, 0x1, 0x7ff9b67e7730, 0x7ff9b67e7758, 0x0, 0x80008000000007, 0x0, 0x7ff9ecef6783, 0x0, 0x7ff9b67e7738, 0x6, 0x7ff9edf7be20 , 0x7ff9f0bf8570, 0x7ff944222b60, 0x3a00000118, 0x0, 0x1, 0x7ff9efb5c380, 0x0, 0x7ff9442231d0, 0x0, 0x7ff944652f10, 0x7ff944650cb0, 0x0, 0x7ff944c96d90, 0x0, 0x0, 0xd9760970005a1900, 0x0, 0x7ff9f0437280, 0x7ff9451a9ae0, 0x7ff94464bdf0, 0x7ff944222b60, 0x2f, 0x0, 0x0, 0x0, 0xe, 0x7ff9451a9ae0, 0x7ff9f0437280, 0x2b, 0x1, 0x0, 0x7ff9edf8e0a9 , 0x7ff9edfbca2a, 0x7ff9edf9012d , 0x7ff9f0437280, 0x7ff9f0437280, 0x7ff9f15e5968, 0x0, 0x0, 0x61, 0xa9, 0xffffff6701000000, 0x7ff9f0bc6270, 0x0, 0x0, 0xd9760970005a1900, 0x7ff9f0437280, 0x7ff9f0437280, 0x7ff9ee1f0b9c , 0x0, 0x7ff9b67e7900, 0x7ff9b67e7948, 0x1, 0xd9760970005a1900, 0x7ff9f0437280, 0x7ff9ee1f0b9c , 0x0, 0x7ff9ee44c35e , 0x0, 0x0, 0x7ff9f0de3580, 0x7ff9b67e7920, 0x0, 0x20, 0x7ff944631340, 0x7ff9f017d6e0, 0x7ff9f0de3580, 0x7ff9e6c0664f, 0x7ff944015480, 0x7ff9446316f8, 0x0, 0x7ff9781ec4e0, 0x7ff9b67e9b40, 0x0, 0x0, 0x0, 0x20, 0x7ff9781ec4e0, 0x7ff9f0de3580, 0x7ff9edf326c6 , 0x10, 0x7ff9edfaa1ee , 0x7ff9ee1fc400 , 0x7ff944631638, 0x7ff9b67e79b0, 0x7ff9b67e79e0, 0x7ff9b67e7a00, 0x0, 0x7ff9ee1fc400 , 0x7ff944006aa0, 0x7ff9f0de3580, 0x7ff9b67e7a18, 0x18, 0x7ff944002bd8, 0x1, 0x0, 0x7ff9ee1fc400 , 0x7ff944006aa0, 0x7ff9f0de3580, 0x7ff9b67e7b10, 0x18, 0x0, 0x7ff9ee1fc400 , 0x7ff944006aa0, 0x7ff9f0de3580, 0x7ff9edf326c6 ...} attrlistbuf = "p#eD\371\177\000\000?\275\353\371\177\000\000P\234\232D\371\177\000\000 \000\000D\371\177\000\000@#eD\371\177\000\000\060#eD\371\177\000\000\037\000\000\000\000\000\000\000P\000\000\000\000\000\000\000@\000\000\000\000\000\000\000b\232\275\353\371\177\000\000\020e\234\357\371\177\000\000\060\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\001", '\000' , "\365:\374\355\371\177\000\000\260\226~\266\371\177\000\000\001\000\000\000\000\000\000\000\037\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\000\227~\266\371\177\000\000\211\220V\354\371\177\000\000\344:\374\355\371\177\000\000\260\226~\266\371\177\000\000\000\000\000\000\000\000\000\000\371"... attrliststr = attrs = 0x0 rc = 0 internal_op = basesdn = 0x7ff9451a8c80 sdn = 0x7ff9451a8fb0 operation = 0x7ff9f04c7f10 referral = 0x0 proxydn = 0x0 proxystr = 0x0 proxy_err = errtext = 0x0 errorbuf = "\000\062eD\371\177\000\000\200\227~\266\371\177\000\000\005\000\000\000\000\000\000\000\306&\363\355\371\177\000\000\000\000\000\000\000\000\000\000\310\071eD\371\177\000\000\370AeD\371\177\000\000P\254dD\371\177\000\000\370AeD\371\177\000\000\370AeD\371\177\000\000\370AeD\371\177\000\000\370\227~\266\371\177\000\000(\000\000\000\000\000\000\000\220m\311D\371\177\000\000\000\000\000\000\000\000\000\000 8\201\357\371\177\000\000Hn\311D\371\177\000\000\240\neD\371\177", '\000' , "\031Z\000p\tv\331H\neD\371\177\000\000H\neD\371\177\000\000P\neD\371\177\000\000\000\000\000\000\000\000\000\000\234\v\037\356\371\177\000\000"... nentries = pnentries = 0 flag_search_base_found = 0 flag_no_such_object = 0 flag_referral = 0 flag_psearch = err_code = 0 ctrlp = 0x0 ctl_value = 0x0 iscritical = 0 be_name = index = 0 sent_result = 0 pr_stat = 0 pagesize = -1 estimate = 0 curr_search_count = 0 pr_be = pr_search_result = pr_idx = -1 orig_sdn = 0x0 free_sdn = 1 #24 0x00007ff9ee44d3a9 in do_search (pb=) at ldap/servers/slapd/search.c:366 operation = 0x7ff9f04c7f10 ber = i = err = attrsonly = 0 scope = 1 deref = 0 sizelimit = 1 timelimit = 5 rawbase = 0x7ff9451a7cb0 "cn=users,cn=compat,dc=internal" fstr = 0x7ff944672fd0 "(uid=user3)" filter = 0x7ff9451a2040 attrs = 0x0 gerattrs = 0x0 psearch = 0 psbvp = 0x0 changetypes = 32761 send_entchg_controls = -536206104 changesonly = 0 rc = -1 strict = minssf_exclude_rootdse = filter_normalized = 0 #25 0x00007ff9ee43d224 in connection_threadmain () at ldap/servers/slapd/connection.c:621 pb = 0x7ff9f0dc7ef0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #26 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f072c5a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f072c5a0 detached = 1 id = 140710485346048 tid = 28105 #27 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b67ec700) at pthread_create.c:308 __res = pd = 0x7ff9b67ec700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710485346048, -4824962676551115758, 0, 140710485346752, 140710485346048, 1, 4825931352730180626, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #28 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 44 (Thread 0x7ff9ee387700 (LWP 28072)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9f0c58858, ml=0x7ff9f019a8d0, timeout=timeout at entry=300000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037364, tv_usec = 709177} tmo = {tv_sec = 1444037664, tv_nsec = 709177000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9f0c58850, timeout=timeout at entry=300000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0561840 #3 0x00007ff9e27caa08 in _cl5TrimMain (param=) at ldap/servers/plugins/replication/cl5_api.c:3444 interval = 300000 timePrev = 1444037364 timeNow = #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0561840) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0561840 detached = 1 id = 140711420262144 tid = 28072 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9ee387700) at pthread_create.c:308 __res = pd = 0x7ff9ee387700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711420262144, -4824962676551115758, 0, 140711420262848, 140711420262144, 1, 4826053895126457362, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 43 (Thread 0x7ff9c77fe700 (LWP 28080)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 505354} tmo = {tv_sec = 1444037587, tv_nsec = 505354000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0c543e0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0c543e0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0c543e0 detached = 1 id = 140710770632448 tid = 28080 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c77fe700) at pthread_create.c:308 __res = pd = 0x7ff9c77fe700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710770632448, -4824962676551115758, 0, 140710770633152, 140710770632448, 1, 4826105070198660114, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 42 (Thread 0x7ff9b2fe6700 (LWP 28808)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 238657} #2 0x00007ff9e27df357 in repl5_inc_result_threadmain (param=0x7ff9c802a170) at ldap/servers/plugins/replication/repl5_inc_protocol.c:311 operation_code = 0 ldap_error_string = 0x0 time_now = op = 0x0 csn_str = 0x0 replica_id = 0 connection_error = 0 uniqueid = 0x0 start_time = 1444037578 backoff_time = 512 rd = 0x7ff9c802a170 conres = conn = 0x7ff9f0c57b40 finished = 0 message_id = 0 #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9c8029c00) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9c8029c00 detached = 0 id = 140710426601216 tid = 28808 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b2fe6700) at pthread_create.c:308 __res = pd = 0x7ff9b2fe6700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710426601216, -4824962676551115758, 0, 140710426601920, 140710426601216, 20, 4825941247261088786, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 41 (Thread 0x7ff9b57ea700 (LWP 28107)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 566510} tmo = {tv_sec = 1444037587, tv_nsec = 566510000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0bd2790 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0bd2790) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0bd2790 detached = 1 id = 140710468560640 tid = 28107 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b57ea700) at pthread_create.c:308 __res = pd = 0x7ff9b57ea700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710468560640, -4824962676551115758, 0, 140710468561344, 140710468560640, 1, 4825924756734155794, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 40 (Thread 0x7ff9bf7fe700 (LWP 28087)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 916950} tmo = {tv_sec = 1444037588, tv_nsec = 916950000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f07fb3b0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f07fb3b0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f07fb3b0 detached = 1 id = 140710636414720 tid = 28087 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bf7fe700) at pthread_create.c:308 __res = pd = 0x7ff9bf7fe700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710636414720, -4824962676551115758, 0, 140710636415424, 140710636414720, 1, 4825946740524260370, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 39 (Thread 0x7ff9ba7f4700 (LWP 28097)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 255171} tmo = {tv_sec = 1444037588, tv_nsec = 255171000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0caaf60 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0caaf60) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0caaf60 detached = 1 id = 140710552487680 tid = 28097 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9ba7f4700) at pthread_create.c:308 __res = pd = 0x7ff9ba7f4700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710552487680, -4824962676551115758, 0, 140710552488384, 140710552487680, 1, 4825957728124345362, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 38 (Thread 0x7ff9d4ddd700 (LWP 28078)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efb5ae18, ml=0x7ff9efb31bf0, timeout=timeout at entry=2000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 137849} tmo = {tv_sec = 1444037580, tv_nsec = 137849000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efb5ae10, timeout=2000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0501f20 #3 0x00007ff9edf488a8 in eq_loop (arg=) at ldap/servers/slapd/eventq.c:355 timeout = until = #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0501f20) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0501f20 detached = 0 id = 140710994892544 tid = 28078 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d4ddd700) at pthread_create.c:308 __res = pd = 0x7ff9d4ddd700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710994892544, -4824962676551115758, 0, 140710994893248, 140710994892544, 1, 4826138863538215954, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 37 (Thread 0x7ff9bc7f8700 (LWP 28093)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 256742} tmo = {tv_sec = 1444037588, tv_nsec = 256742000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9efd915c0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efd915c0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efd915c0 detached = 1 id = 140710586058496 tid = 28093 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bc7f8700) at pthread_create.c:308 __res = pd = 0x7ff9bc7f8700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710586058496, -4824962676551115758, 0, 140710586059200, 140710586058496, 1, 4825944536132295698, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 36 (Thread 0x7ff9be7fc700 (LWP 28089)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 504921} tmo = {tv_sec = 1444037588, tv_nsec = 504921000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0fa6220 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0fa6220) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0fa6220 detached = 1 id = 140710619629312 tid = 28089 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9be7fc700) at pthread_create.c:308 __res = pd = 0x7ff9be7fc700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710619629312, -4824962676551115758, 0, 140710619630016, 140710619629312, 1, 4825948936326290450, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 35 (Thread 0x7ff9b4fe9700 (LWP 28108)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 559579} tmo = {tv_sec = 1444037587, tv_nsec = 559579000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0ce89b0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0ce89b0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0ce89b0 detached = 1 id = 140710460167936 tid = 28108 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b4fe9700) at pthread_create.c:308 __res = pd = 0x7ff9b4fe9700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710460167936, -4824962676551115758, 0, 140710460168640, 140710460167936, 1, 4825928055805910034, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 34 (Thread 0x7ff9c4ff9700 (LWP 28085)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 81588} tmo = {tv_sec = 1444037588, tv_nsec = 81588000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f10129f0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f10129f0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f10129f0 detached = 1 id = 140710728668928 tid = 28085 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c4ff9700) at pthread_create.c:308 __res = pd = 0x7ff9c4ff9700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710728668928, -4824962676551115758, 0, 140710728669632, 140710728668928, 1, 4826103969076419602, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 33 (Thread 0x7ff9c5ffb700 (LWP 28083)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 914745} tmo = {tv_sec = 1444037588, tv_nsec = 914745000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f062fdf0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f062fdf0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f062fdf0 detached = 1 id = 140710745454336 tid = 28083 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c5ffb700) at pthread_create.c:308 __res = pd = 0x7ff9c5ffb700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710745454336, -4824962676551115758, 0, 140710745455040, 140710745454336, 1, 4826101768979422226, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 32 (Thread 0x7ff9bb7f6700 (LWP 28095)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 240493} tmo = {tv_sec = 1444037588, tv_nsec = 240493000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0b2ccc0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0b2ccc0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0b2ccc0 detached = 1 id = 140710569273088 tid = 28095 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bb7f6700) at pthread_create.c:308 __res = pd = 0x7ff9bb7f6700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710569273088, -4824962676551115758, 0, 140710569273792, 140710569273088, 1, 4825955532322315282, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 31 (Thread 0x7ff9bdffb700 (LWP 28090)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 221440} tmo = {tv_sec = 1444037588, tv_nsec = 221440000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0e58510 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0e58510) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0e58510 detached = 1 id = 140710611236608 tid = 28090 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bdffb700) at pthread_create.c:308 __res = pd = 0x7ff9bdffb700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710611236608, -4824962676551115758, 0, 140710611237312, 140710611236608, 1, 4825943439305022482, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 30 (Thread 0x7ff9c67fc700 (LWP 28082)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 192149} tmo = {tv_sec = 1444037588, tv_nsec = 192149000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0c61490 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0c61490) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0c61490 detached = 1 id = 140710753847040 tid = 28082 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c67fc700) at pthread_create.c:308 __res = pd = 0x7ff9c67fc700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710753847040, -4824962676551115758, 0, 140710753847744, 140710753847040, 1, 4826107266000690194, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 29 (Thread 0x7ff9c6ffd700 (LWP 28081)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 88491} tmo = {tv_sec = 1444037588, tv_nsec = 88491000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f01d25c0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f01d25c0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f01d25c0 detached = 1 id = 140710762239744 tid = 28081 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c6ffd700) at pthread_create.c:308 __res = pd = 0x7ff9c6ffd700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710762239744, -4824962676551115758, 0, 140710762240448, 140710762239744, 1, 4826108369270414354, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 28 (Thread 0x7ff9beffd700 (LWP 28088)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 233698} tmo = {tv_sec = 1444037588, tv_nsec = 233698000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f076d150 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f076d150) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f076d150 detached = 1 id = 140710628022016 tid = 28088 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9beffd700) at pthread_create.c:308 __res = pd = 0x7ff9beffd700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710628022016, -4824962676551115758, 0, 140710628022720, 140710628022016, 1, 4825950039596014610, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 27 (Thread 0x7ff9b5feb700 (LWP 28106)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 909741} tmo = {tv_sec = 1444037588, tv_nsec = 909741000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0a902f0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0a902f0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0a902f0 detached = 1 id = 140710476953344 tid = 28106 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b5feb700) at pthread_create.c:308 __res = pd = 0x7ff9b5feb700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710476953344, -4824962676551115758, 0, 140710476954048, 140710476953344, 1, 4825925855708912658, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 26 (Thread 0x7ff9ddb22700 (LWP 27929)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=ticks at entry=250) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 237927} #2 0x00007ff9e2a62105 in checkpoint_threadmain (param=0x7ff9ef9ef160) at ldap/servers/slapd/back-ldbm/dblayer.c:4476 time_of_last_checkpoint_completion = 1444037519 interval = rval = priv = 0x7ff9ef9eef20 li = 0x7ff9ef9ef160 debug_checkpointing = 0 checkpoint_interval = home_dir = list = 0x0 listp = penv = 0x7ff9efa44a40 #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efb5c250) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efb5c250 detached = 1 id = 140711143024384 tid = 27929 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9ddb22700) at pthread_create.c:308 __res = pd = 0x7ff9ddb22700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711143024384, -4824962676551115758, 0, 140711143025088, 140711143024384, 1, 4826153897534364690, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 25 (Thread 0x7ff9bd7fa700 (LWP 28091)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 901492} tmo = {tv_sec = 1444037588, tv_nsec = 901492000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f10dd410 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f10dd410) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f10dd410 detached = 1 id = 140710602843904 tid = 28091 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bd7fa700) at pthread_create.c:308 __res = pd = 0x7ff9bd7fa700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710602843904, -4824962676551115758, 0, 140710602844608, 140710602843904, 1, 4825942340330265618, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 24 (Thread 0x7ff9b6fed700 (LWP 28104)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 572849} tmo = {tv_sec = 1444037587, tv_nsec = 572849000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f01f2ef0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f01f2ef0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f01f2ef0 detached = 1 id = 140710493738752 tid = 28104 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b6fed700) at pthread_create.c:308 __res = pd = 0x7ff9b6fed700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710493738752, -4824962676551115758, 0, 140710493739456, 140710493738752, 1, 4825932455999904786, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 23 (Thread 0x7ff9bbff7700 (LWP 28094)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 549240} tmo = {tv_sec = 1444037587, tv_nsec = 549240000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0b54020 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0b54020) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0b54020 detached = 1 id = 140710577665792 tid = 28094 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bbff7700) at pthread_create.c:308 __res = pd = 0x7ff9bbff7700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710577665792, -4824962676551115758, 0, 140710577666496, 140710577665792, 1, 4825956631297072146, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 22 (Thread 0x7ff9bcff9700 (LWP 28092)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 244800} tmo = {tv_sec = 1444037588, tv_nsec = 244800000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0949d40 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0949d40) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0949d40 detached = 1 id = 140710594451200 tid = 28092 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bcff9700) at pthread_create.c:308 __res = pd = 0x7ff9bcff9700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710594451200, -4824962676551115758, 0, 140710594451904, 140710594451200, 1, 4825945639402019858, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 21 (Thread 0x7ff9b97f2700 (LWP 28099)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 105814} tmo = {tv_sec = 1444037588, tv_nsec = 105814000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9eff4c710 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 66 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9eff4c710) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9eff4c710 detached = 1 id = 140710535702272 tid = 28099 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b97f2700) at pthread_create.c:308 __res = pd = 0x7ff9b97f2700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710535702272, -4824962676551115758, 0, 140710535702976, 140710535702272, 1, 4825951132128320530, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 20 (Thread 0x7ff9bffff700 (LWP 28086)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 507493} tmo = {tv_sec = 1444037587, tv_nsec = 507493000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0df6030 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 99 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0df6030) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0df6030 detached = 1 id = 140710644807424 tid = 28086 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9bffff700) at pthread_create.c:308 __res = pd = 0x7ff9bffff700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710644807424, -4824962676551115758, 0, 140710644808128, 140710644807424, 1, 4825947839499017234, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 19 (Thread 0x7ff9b27e5700 (LWP 28121)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ff9ec57b270 in PR_WaitCondVar (cvar=0x7ff9efb5b320, timeout=timeout at entry=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385 rv = thred = 0x7ff980013360 #2 0x00007ff9ee4482f5 in ps_send_results (arg=) at ldap/servers/slapd/psearch.c:325 ps = 0x7ff980001630 peq = 0x0 peqnext = filter = 0x0 base = 0x0 sdn = 0x0 fstr = 0x0 pbattrs = 0x0 conn_acq_flag = 0 #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff980013360) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff980013360 detached = 1 id = 140710418208512 tid = 28121 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b27e5700) at pthread_create.c:308 __res = pd = 0x7ff9b27e5700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710418208512, -4824962676551115758, 0, 140710418209216, 140710418208512, 1, 4825940148286331922, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 18 (Thread 0x7ff9de323700 (LWP 27928)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=ticks at entry=100) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 12621} #2 0x00007ff9e2a61d97 in deadlock_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4329 rval = priv = 0x7ff9ef9eef20 li = interval = #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efa4c120) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efa4c120 detached = 1 id = 140711151417088 tid = 27928 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9de323700) at pthread_create.c:308 __res = pd = 0x7ff9de323700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711151417088, -4824962676551115758, 0, 140711151417792, 140711151417088, 1, 4826159394555632658, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 17 (Thread 0x7ff9b7fef700 (LWP 28102)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 69172} tmo = {tv_sec = 1444037588, tv_nsec = 69172000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0b0baa0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0b0baa0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0b0baa0 detached = 1 id = 140710510524160 tid = 28102 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b7fef700) at pthread_create.c:308 __res = pd = 0x7ff9b7fef700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710510524160, -4824962676551115758, 0, 140710510524864, 140710510524160, 1, 4825930255902907410, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 16 (Thread 0x7ff9d67fc700 (LWP 28075)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ff9ec57b270 in PR_WaitCondVar (cvar=cvar at entry=0x7ff9f07d2380, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385 rv = thred = 0x7ff9f0d12980 #2 0x00007ff9edf99eb8 in slapi_wait_condvar (cvar=0x7ff9f07d2380, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:179 prit = #3 0x00007ff9e1119c4d in roles_cache_wait_on_change (arg=0x7ff9f0b584d0) at ldap/servers/plugins/roles/roles_cache.c:432 roles_def = 0x7ff9f0b584d0 #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0d12980) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0d12980 detached = 1 id = 140711022282496 tid = 28075 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d67fc700) at pthread_create.c:308 __res = pd = 0x7ff9d67fc700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711022282496, -4824962676551115758, 0, 140711022283200, 140711022282496, 1, 4826142450372779026, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 15 (Thread 0x7ff9c57fa700 (LWP 28084)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 92226} tmo = {tv_sec = 1444037588, tv_nsec = 92226000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0e5fcf0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0e5fcf0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0e5fcf0 detached = 1 id = 140710737061632 tid = 28084 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c57fa700) at pthread_create.c:308 __res = pd = 0x7ff9c57fa700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710737061632, -4824962676551115758, 0, 140710737062336, 140710737061632, 1, 4826100670004665362, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 14 (Thread 0x7ff9d7fff700 (LWP 28071)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ff9ec57b270 in PR_WaitCondVar (cvar=cvar at entry=0x7ff9f014d7d0, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385 rv = thred = 0x7ff9f0612050 #2 0x00007ff9edf99eb8 in slapi_wait_condvar (cvar=0x7ff9f014d7d0, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:179 prit = #3 0x00007ff9e4b505ce in cos_cache_wait_on_change (arg=) at ldap/servers/plugins/cos/cos_cache.c:436 No locals. #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0612050) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0612050 detached = 1 id = 140711047460608 tid = 28071 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d7fff700) at pthread_create.c:308 __res = pd = 0x7ff9d7fff700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711047460608, -4824962676551115758, 0, 140711047461312, 140711047460608, 1, 4826141353545505810, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 13 (Thread 0x7ff9dd321700 (LWP 27930)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=ticks at entry=250) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 79522} #2 0x00007ff9e2a6257f in trickle_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4634 interval = 250 rval = priv = 0x7ff9ef9eef20 li = debug_checkpointing = 0 #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efa4bcc0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efa4bcc0 detached = 1 id = 140711134631680 tid = 27930 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9dd321700) at pthread_create.c:308 __res = pd = 0x7ff9dd321700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711134631680, -4824962676551115758, 0, 140711134632384, 140711134631680, 1, 4826152798559607826, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 12 (Thread 0x7ff9b87f0700 (LWP 28101)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 607993} tmo = {tv_sec = 1444037587, tv_nsec = 607993000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9efdeb4a0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efdeb4a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efdeb4a0 detached = 1 id = 140710518916864 tid = 28101 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b87f0700) at pthread_create.c:308 __res = pd = 0x7ff9b87f0700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710518916864, -4824962676551115758, 0, 140710518917568, 140710518916864, 1, 4825953345110219794, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 11 (Thread 0x7ff9d5ffb700 (LWP 28076)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ff9ec57b270 in PR_WaitCondVar (cvar=cvar at entry=0x7ff9f05ae480, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385 rv = thred = 0x7ff9f0a40e80 #2 0x00007ff9edf99eb8 in slapi_wait_condvar (cvar=0x7ff9f05ae480, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:179 prit = #3 0x00007ff9e1119c4d in roles_cache_wait_on_change (arg=0x7ff9efd4c9d0) at ldap/servers/plugins/roles/roles_cache.c:432 roles_def = 0x7ff9efd4c9d0 #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0a40e80) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0a40e80 detached = 1 id = 140711013889792 tid = 28076 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d5ffb700) at pthread_create.c:308 __res = pd = 0x7ff9d5ffb700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711013889792, -4824962676551115758, 0, 140711013890496, 140711013889792, 1, 4826136953351511058, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 10 (Thread 0x7ff9d55de700 (LWP 28077)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9f0182fd8, ml=0x7ff9f1057a00, timeout=timeout at entry=30000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037574, tv_usec = 724166} tmo = {tv_sec = 1444037604, tv_nsec = 724166000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9f0182fd0, timeout=timeout at entry=30000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f049a140 #3 0x00007ff9ee444213 in housecleaning (cur_time=) at ldap/servers/slapd/house.c:77 interval = 30000 #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f049a140) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f049a140 detached = 0 id = 140711003285248 tid = 28077 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d55de700) at pthread_create.c:308 __res = pd = 0x7ff9d55de700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711003285248, -4824962676551115758, 0, 140711003285952, 140711003285248, 1, 4826135564466461714, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 9 (Thread 0x7ff9b77ee700 (LWP 28103)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 900968} tmo = {tv_sec = 1444037588, tv_nsec = 900968000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f0e0b150 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 119 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0e0b150) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0e0b150 detached = 1 id = 140710502131456 tid = 28103 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b77ee700) at pthread_create.c:308 __res = pd = 0x7ff9b77ee700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710502131456, -4824962676551115758, 0, 140710502132160, 140710502131456, 1, 4825929156928150546, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 8 (Thread 0x7ff9d77fe700 (LWP 28073)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 218675} #2 0x00007ff9e27e17ca in repl5_inc_waitfor_async_results (rd=0x7ff9c802a170) at ldap/servers/plugins/replication/repl5_inc_protocol.c:488 done = 1 loops = #3 send_updates (num_changes_sent=0x7ff9d77fdc60, remote_update_vector=, prp=0x7ff9f0fea910) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1898 finished = 1 replay_crc = csn_str = "561243cc000000040000" return_value = 201 rd = 0x7ff9c802a170 entry = {op = 0x7ff9d77fdcd0, time = 1444037577} op = {operation_type = 0, target_address = {udn = 0x0, uniqueid = 0x0, sdn = 0x0}, csn = 0x0, request_controls = 0x0, p = {p_add = {target_entry = 0x0, parentuniqueid = 0x0}, p_bind = {bind_method = 0, bind_creds = 0x0, bind_saslmechanism = 0x0, bind_ret_saslcreds = 0x0}, p_compare = {compare_ava = {ava_type = 0x0, ava_value = {bv_len = 0, bv_val = 0x0}, ava_private = 0x0}}, p_modify = {modify_mods = 0x0}, p_modrdn = {modrdn_newrdn = 0x0, modrdn_deloldrdn = 0, modrdn_newsuperior_address = {udn = 0x0, uniqueid = 0x0, sdn = 0x0}, modrdn_mods = 0x0}, p_search = {search_scope = 0, search_deref = 0, search_sizelimit = 0, search_timelimit = 0, search_filter = 0x0, search_strfilter = 0x0, search_attrs = 0x0, search_attrsonly = 0, search_is_and = 0, search_gerattrs = 0x0}, p_abandon = {abandon_targetmsgid = 0}, p_extended = {exop_oid = 0x0, exop_value = 0x0}}} rc = changelog_iterator = 0x7ff9c800c4e0 message_id = 0 #4 repl5_inc_run (prp=) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1056 rc = prp_priv = replica = 0x0 cons_schema_csn = 0x7ff9c8009740 ruv = 0x7ff9c800c020 num_changes_sent = 0 use_busy_backoff_timer = next_fire_time = now = 140711039065312 busywaittime = 0 pausetime = 0 loops = wait_change_timer_set = current_state = next_state = optype = 0 ldaprc = 679486241 done = 0 e1 = #5 0x00007ff9e27e5a5c in prot_thread_main (arg=0x7ff9f06bb9d0) at ldap/servers/plugins/replication/repl5_protocol.c:296 rp = 0x7ff9f06bb9d0 done = 0 agmt = 0x7ff9f017ab50 #6 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f10e5ca0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f10e5ca0 detached = 0 id = 140711039067904 tid = 28073 #7 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d77fe700) at pthread_create.c:308 __res = pd = 0x7ff9d77fe700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711039067904, -4824962676551115758, 0, 140711039068608, 140711039067904, 1, 4826140254570748946, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #8 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 7 (Thread 0x7ff9c7fff700 (LWP 28079)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 252372} tmo = {tv_sec = 1444037588, tv_nsec = 252372000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f04440f0 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 66 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f04440f0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f04440f0 detached = 1 id = 140710779025152 tid = 28079 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9c7fff700) at pthread_create.c:308 __res = pd = 0x7ff9c7fff700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710779025152, -4824962676551115758, 0, 140710779025856, 140710779025152, 1, 4826106169173416978, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 6 (Thread 0x7ff9dcb20700 (LWP 27931)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 793933} #2 0x00007ff9e2ab0714 in perfctrs_wait (milliseconds=milliseconds at entry=1000, priv=, db_env=) at ldap/servers/slapd/back-ldbm/perfctrs.c:277 interval = #3 0x00007ff9e2a5d087 in perf_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:3829 priv = 0x7ff9ef9eef20 li = #4 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efc0b710) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efc0b710 detached = 1 id = 140711126238976 tid = 27931 #5 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9dcb20700) at pthread_create.c:308 __res = pd = 0x7ff9dcb20700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711126238976, -4824962676551115758, 0, 140711126239680, 140711126238976, 1, 4826156076156525586, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 5 (Thread 0x7ff9b9ff3700 (LWP 28098)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037578, tv_usec = 94422} tmo = {tv_sec = 1444037588, tv_nsec = 94422000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9f077e610 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f077e610) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f077e610 detached = 1 id = 140710544094976 tid = 28098 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b9ff3700) at pthread_create.c:308 __res = pd = 0x7ff9b9ff3700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710544094976, -4824962676551115758, 0, 140710544095680, 140710544094976, 1, 4825952231103077394, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 4 (Thread 0x7ff9b47e8700 (LWP 28109)): #0 0x00007ff9ebc46b63 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007ff9edfa7929 in DS_Sleep (ticks=ticks at entry=1000) at ldap/servers/slapd/util.c:1108 mSecs = tm = {tv_sec = 0, tv_usec = 5110} #2 0x00007ff9ee43df85 in time_thread (nothing=) at ldap/servers/slapd/daemon.c:474 interval = 1000 #3 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f0c0aaa0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f0c0aaa0 detached = 0 id = 140710451775232 tid = 28109 #4 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b47e8700) at pthread_create.c:308 __res = pd = 0x7ff9b47e8700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710451775232, -4824962676551115758, 0, 140710451775936, 140710451775232, 1, 4825926952536185874, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 3 (Thread 0x7ff9d6ffd700 (LWP 28074)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ff9ec57b270 in PR_WaitCondVar (cvar=0x7ff9f10bfb20, timeout=timeout at entry=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:385 rv = thred = 0x7ff9f1033ee0 #2 0x00007ff9e27deef4 in protocol_sleep (prp=prp at entry=0x7ff9f0b93640, duration=duration at entry=4294967295) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1219 No locals. #3 0x00007ff9e27e0216 in repl5_inc_run (prp=) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1181 rc = prp_priv = replica = 0x0 cons_schema_csn = 0x7ff9cc04ab10 ruv = 0x0 num_changes_sent = 0 use_busy_backoff_timer = next_fire_time = now = 140711030672608 busywaittime = 0 pausetime = 0 loops = wait_change_timer_set = current_state = next_state = 8 optype = 0 ldaprc = 687878945 done = 0 e1 = #4 0x00007ff9e27e5a5c in prot_thread_main (arg=0x7ff9effb6180) at ldap/servers/plugins/replication/repl5_protocol.c:296 rp = 0x7ff9effb6180 done = 0 agmt = 0x7ff9f0dc10b0 #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f1033ee0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f1033ee0 detached = 0 id = 140711030675200 tid = 28074 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9d6ffd700) at pthread_create.c:308 __res = pd = 0x7ff9d6ffd700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140711030675200, -4824962676551115758, 0, 140711030675904, 140711030675200, 1, 4826143553642503186, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 2 (Thread 0x7ff9b8ff1700 (LWP 28100)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 No locals. #1 0x00007ff9ec57ad37 in pt_TimedWait (cv=cv at entry=0x7ff9efd63e18, ml=0x7ff9f0ab7100, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:264 rv = now = {tv_sec = 1444037577, tv_usec = 577428} tmo = {tv_sec = 1444037587, tv_nsec = 577428000} ticks = #2 0x00007ff9ec57b1ee in PR_WaitCondVar (cvar=0x7ff9efd63e10, timeout=timeout at entry=10000) at ../../../nspr/pr/src/pthreads/ptsynch.c:387 rv = thred = 0x7ff9efe26c10 #3 0x00007ff9ee43b6c6 in connection_wait_for_new_pb (ppb=, interval=) at ldap/servers/slapd/connection.c:1717 ret = #4 0x00007ff9ee43cdce in connection_threadmain () at ldap/servers/slapd/connection.c:2227 pb = 0x0 interval = conn = op = tag = 66 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9efe26c10) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9efe26c10 detached = 1 id = 140710527309568 tid = 28100 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9b8ff1700) at pthread_create.c:308 __res = pd = 0x7ff9b8ff1700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710527309568, -4824962676551115758, 0, 140710527310272, 140710527309568, 1, 4825954431200074770, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 1 (Thread 0x7ff9baff5700 (LWP 28096)): #0 __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 No locals. #1 0x00007ff9ebbdf8ae in __GI___strdup (s=0x756f6363613d6e63
) at strdup.c:41 len = new = #2 0x00007ff9edf32503 in slapi_ch_strdup (s1=0x756f6363613d6e63
) at ldap/servers/slapd/ch_malloc.c:277 newmem = #3 0x00007ff9ee43767f in do_bind (pb=0x7ff9f0862250) at ldap/servers/slapd/bind.c:765 t = 0 authtype = ber = err = isroot = 0 method = 128 version = 3 auth_response_requested = 0 pw_response_requested = 0 rawdn = 0x7ff934029bc0 "" dn = saslmech = 0x0 cred = {bv_len = 8, bv_val = 0x7ff9340e8130 "cJr7-g5e"} be = 0x7ff9efb5c380 ber_rc = rc = 0 sdn = 0x7ff9341035a0 referral = 0x0 errorbuf = '\000' ... supported = pmech = authtypebuf = "\000\000\000\000\000\000\000\000\b1\003\064\371\177\000\000\000\061\003\064\371\177\000\000\340\060\003\064\371\177\000\000\001\000\000\000\000\000\000\000x,\377\272\371\177\000\000P\241\230\360\371\177\000\000 \320\000\064\371\177\000\000\237\030\373\355\371\177\000\000\200,\377\272\371\177\000\000\000\000\000\000\000\000\000\000\306&\363\355\371\177\000\000\000\000\000\000\000\000\000\000L\321\366\355\371\177\000\000\200,\377\272\371\177\000\000\000\000\000\000\000\000\000\000X,\377\272\371\177\000\000x,\377\272\371\177", '\000' , "\002\000\000\000`3<\360\371\177\000\000\377\377\377\377\377\377\377\377\340\060\003\064\371\177\000\000\000\000\000\000\000\000\000\000\"\\\001\064\371\177", '\000' bind_target_entry = 0x7ff9354e92d0 auto_bind = minssf = minssf_exclude_rootdse = #4 0x00007ff9ee43d303 in connection_threadmain () at ldap/servers/slapd/connection.c:572 pb = 0x7ff9f0862250 interval = conn = op = tag = 96 need_wakeup = need_conn_release = thread_turbo_flag = ret = more_data = 0 replication_connection = doshutdown = #5 0x00007ff9ec5809eb in _pt_root (arg=0x7ff9f00f9320) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7ff9f00f9320 detached = 1 id = 140710560880384 tid = 28096 #6 0x00007ff9ebf21df3 in start_thread (arg=0x7ff9baff5700) at pthread_create.c:308 __res = pd = 0x7ff9baff5700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140710560880384, -4824962676551115758, 0, 140710560881088, 140710560880384, 1, 4825958831394069522, 4826062088262458386}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #7 0x00007ff9ebc4f3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. From f.zoske at euroimmun.de Mon Oct 5 13:25:09 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Mon, 5 Oct 2015 13:25:09 +0000 Subject: [Freeipa-users] SUDO does not always works on first try Message-ID: Dear Jakub, I found only the following entries in the /var/log/auth.log: Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify password for [f.zoske at de.eu.local] Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user f.zoske at de.eu.local: 7 (Authentication failure) Oct 5 11:57:38 hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/cat /etc/sssd/sssd.conf Oct 5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 11:57:43 hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 11:57:47 hl-srv10 sudo: f.zoske at de.eu.local : TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash Oct 5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for user root by f.zoske at de.eu.local(uid=0) In /var/log/sssd/ no entries were logged. My sssd.conf: [domain/ipa-lx.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa-lx.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = hl-srv10.ipa-lx.com chpass_provider = ipa ipa_server = _srv_, dc01.ipa-lx.com ldap_tls_cacert = /etc/ipa/ca.crt ldap_sudo_use_host_filter = false [sssd] services = nss, pam, ssh, sudo config_file_version = 2 default_domain_suffix = de.eu.local domains = ei-ag.it [nss] override_shell = /bin/bash [pam] [sudo] [autofs] [ssh] [pac] Best regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Oct 5 14:07:53 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 5 Oct 2015 16:07:53 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> Message-ID: <56128439.9090005@redhat.com> On 10/05/2015 12:55 PM, Fujisan wrote: > It is actually on the ipa server that ipa commands are not working. On ipa > clients, I do not have errors. > > > > On Mon, Oct 5, 2015 at 12:27 PM, Fujisan wrote: > >> I just noticed I can log in to the web UI with user admin and his password. >> >> But when I try to configure firefox to use kerberos, I click on "Install >> Kerberos Configuration Firefox Extension" button, a message appears saying >> "Firefox prevented this site from asking you to install software on your >> computer", so I click on the "Allow" button and then another message >> appears "The add-on downloaded from this site could not be installed >> because it appears to be corrupt.". Here you hit https://fedorahosted.org/freeipa/ticket/4906 Fix(will be in 4.2.2 release) for this ticket changes the procedure for new versions of Firefox to a manual configuration. Basically the steps for Firefox which are described on page http://your-ipa.example.test/ipa/config/ssbrowser.html >> >> And the ipa commands are still not working. >> $ ipa user-show admin >> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >> Unauthorized >> >> >> On Mon, Oct 5, 2015 at 12:13 PM, Fujisan wrote: >> >>> I uninstalled the ipa server and reinstalled it. Then restored the backup. >>> And then the following: >>> >>> $ keyctl list @s >>> 3 keys in keyring: >>> 437165764: --alswrv 0 65534 keyring: _uid.0 >>> 556579409: --alswrv 0 0 user: >>> ipa_session_cookie:host/zaira2.opera at OPERA >>> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >>> $ keyctl purge 556579409 >>> purged 0 keys >>> $ keyctl reap >>> 0 keys reaped >>> $ ipa user-show admin >>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>> Unauthorized >>> $ keyctl list @s >>> 3 keys in keyring: >>> 437165764: --alswrv 0 65534 keyring: _uid.0 >>> 556579409: --alswrv 0 0 user: >>> ipa_session_cookie:host/zaira2.opera at OPERA >>> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >>> >>> ?It doesn't seem to purge or to reap.? >>> >>> >>> >>> On Mon, Oct 5, 2015 at 9:17 AM, Fujisan wrote: >>> >>>> Good morning, >>>> ? >>>> Any suggestion what I should do?? >>>> >>>> ?I still have >>>> >>>> ?$ ipa user-show admin >>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>> Unauthorized >>>> >>>> >>>> Regards. >>>> >>>> >>>> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: >>>> >>>>> I only have this: >>>>> >>>>> $ keyctl list @s >>>>> 1 key in keyring: >>>>> 641467419: --alswrv 0 65534 keyring: _uid.0 >>>>> $ >>>>> >>>>> >>>>> >>>>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy >>>>> wrote: >>>>> >>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>> >>>>>>> I forgot to mention that >>>>>>> >>>>>>> $ ipa user-show admin >>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>> Unauthorized >>>>>>> >>>>>> This is most likely because of the cached session to your server. >>>>>> >>>>>> You can check if keyctl list @s >>>>>> returns you something like >>>>>> [root at m1 ~]# keyctl list @s >>>>>> 2 keys in keyring: >>>>>> 496745412: --alswrv 0 65534 keyring: _uid.0 >>>>>> 215779962: --alswrv 0 0 user: >>>>>> ipa_session_cookie:admin at EXAMPLE.COM >>>>>> >>>>>> If so, then notice the key number (215779962) for the session cookie, >>>>>> and do: >>>>>> keyctl purge 215779962 >>>>>> keyctl reap >>>>>> >>>>>> This should make a next 'ipa ...' command run to ask for new cookie. >>>>>> >>>>>> >>>>>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>>>>>> >>>>>>> I still cannot login to the web UI. >>>>>>>> >>>>>>>> Here is what I did: >>>>>>>> >>>>>>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>>>>>> 2. kinit admin >>>>>>>> Password for admin at OPERA: >>>>>>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>>>>>> /etc/krb5.keytab >>>>>>>> 4. systemctl restart sssd.service >>>>>>>> 5. mv /etc/httpd/conf/ipa.keytab /etc/httpd/conf/ipa.keytab.save >>>>>>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>>> 7. systemctl restart httpd.service >>>>>>>> >>>>>>>> >>>>>>>> The log says now: >>>>>>>> >>>>>>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes >>>>>>>> {18 17 >>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy < >>>>>>>> abokovoy at redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>>> >>>>>>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>>>>>> kerberos. >>>>>>>>>> >>>>>>>>>> What should I do to fix this? >>>>>>>>>> >>>>>>>>>> I have this on the ipa server: >>>>>>>>>> $ klist -k >>>>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>>>> KVNO Principal >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>> >>>>>>>>>> You can start by: >>>>>>>>>> >>>>>>>>> 0. backup every file mentioned below >>>>>>>>> 1. Move /etc/krb5.keytab somewhere >>>>>>>>> 2. kinit as admin >>>>>>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k >>>>>>>>> /etc/krb5.keytab >>>>>>>>> 4. restart SSSD >>>>>>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>>>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>>>> 7. Restart httpd >>>>>>>>> >>>>>>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>>>>>> specified by you is replaced on the server side so that keys in the >>>>>>>>> keytabs become unusable. >>>>>>>>> >>>>>>>>> I guess cockpit instructions were for something that was not >>>>>>>>> supposed to >>>>>>>>> run on IPA master. On IPA master there are already all needed >>>>>>>>> services >>>>>>>>> (host/ and HTTP/) and their keytabs are in place. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy < >>>>>>>>>> abokovoy at redhat.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> More info: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can initiate a ticket: >>>>>>>>>>>> $ kdestroy >>>>>>>>>>>> $ kinit admin >>>>>>>>>>>> >>>>>>>>>>>> but cannot view user admin: >>>>>>>>>>>> $ ipa user-show admin >>>>>>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>>>>>> Unauthorized >>>>>>>>>>>> >>>>>>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>>>>>> >>>>>>>>>>>> /var/log/messages: >>>>>>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>>>>>> initialize >>>>>>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>>>>>> integrity >>>>>>>>>>>> check >>>>>>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>>>>>> >>>>>>>>>>>> What did you do? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that >>>>>>>>>>> you have >>>>>>>>>>> different keys in LDAP and in your keytab files for >>>>>>>>>>> host/zaira2.opera >>>>>>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>>>>>> removed >>>>>>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or ipa >>>>>>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>>>>>> whatever you have in the keytab files. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>>>>>> >>>>>>>>>>>>> The password or username you entered is incorrect. >>>>>>>>>>>>> >>>>>>>>>>>>> Log says: >>>>>>>>>>>>> >>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>>> etypes >>>>>>>>>>>>> {18 17 >>>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>>> fd 12 >>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>>>>>> failed >>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>>> etypes >>>>>>>>>>>>> {18 17 >>>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>>> fd 12 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I have no idea what went wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> What can I do? >>>>>>>>>>>>> >>>>>>>>>>>>> ?Regards, >>>>>>>>>>>>> Fuji? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>> / 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 >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> / Alexander Bokovoy >>>>>> -- Petr Vobornik From rcritten at redhat.com Mon Oct 5 14:39:34 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2015 10:39:34 -0400 Subject: [Freeipa-users] admin loses access? In-Reply-To: <56117E17.2050302@physik.uni-wuppertal.de> References: <56116104.3020404@gmail.com> <56117E17.2050302@physik.uni-wuppertal.de> Message-ID: <56128BA6.4040805@redhat.com> Torsten Harenberg wrote: > Hi Janelle, > > Am 04.10.2015 um 19:25 schrieb Janelle: >> Just wondering if anyone knows why this happens from time to time on >> servers: >> >> $ kinit admin >> kinit: Clients credentials have been revoked while getting initial >> credentials >> >> there are no failed logins to the admin account - not even any login >> attempts, so it is not like someone is getting the account locked out. >> Just curious if anyone else has seen in. With 16 masters, it occurs >> randomly on some hosts, but eventually clears either on its own or with >> a restart of IPA. However, I just restarted IPA on this server and after >> about 2-3 minutes it works again. >> > > I am seeing the same, see my mail "kinit admin not working anymore > (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. > Actually, wasn't it you who wanted to open a ticket? > > Have a nice evening, > > Torsten > When you see this run `ipa user-status admin` and `ipa pwpolicy-show --user=admin` and provide that so we can potentially see what is going on. rob From janellenicole80 at gmail.com Mon Oct 5 14:58:03 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 5 Oct 2015 07:58:03 -0700 Subject: [Freeipa-users] admin loses access? In-Reply-To: <56128BA6.4040805@redhat.com> References: <56116104.3020404@gmail.com> <56117E17.2050302@physik.uni-wuppertal.de> <56128BA6.4040805@redhat.com> Message-ID: <56128FFB.3020606@gmail.com> On 10/5/15 7:39 AM, Rob Crittenden wrote: > Torsten Harenberg wrote: >> Hi Janelle, >> >> Am 04.10.2015 um 19:25 schrieb Janelle: >>> Just wondering if anyone knows why this happens from time to time on >>> servers: >>> >>> $ kinit admin >>> kinit: Clients credentials have been revoked while getting initial >>> credentials >>> >>> there are no failed logins to the admin account - not even any login >>> attempts, so it is not like someone is getting the account locked out. >>> Just curious if anyone else has seen in. With 16 masters, it occurs >>> randomly on some hosts, but eventually clears either on its own or with >>> a restart of IPA. However, I just restarted IPA on this server and after >>> about 2-3 minutes it works again. >>> >> I am seeing the same, see my mail "kinit admin not working anymore >> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. >> Actually, wasn't it you who wanted to open a ticket? >> >> Have a nice evening, >> >> Torsten >> > When you see this run `ipa user-status admin` and `ipa pwpolicy-show > --user=admin` and provide that so we can potentially see what is going on. > > rob > I am curious -- if you have 16 masters, but this only happens once in awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to understand the thinking of where you are going?? I will for sure do this the next time it happens, but I want to understand logic? thank you ~Janelle From fujisan43 at gmail.com Mon Oct 5 15:07:04 2015 From: fujisan43 at gmail.com (Fujisan) Date: Mon, 5 Oct 2015 17:07:04 +0200 Subject: [Freeipa-users] Cannot connect to FreeIPA web UI anymore In-Reply-To: <56128439.9090005@redhat.com> References: <20151002134558.GB5035@redhat.com> <20151002142525.GD5035@redhat.com> <20151002150145.GG5035@redhat.com> <56128439.9090005@redhat.com> Message-ID: I was going to ask about the ipa command error on the ipa server and how to fix it. But then I just tried again and it works. $ ipa user-show admin User login: admin Last name: Administrator Home directory: /home/zaira/admin Login shell: /bin/bash UID: 1000 GID: 1000 Account disabled: False Password: True Member of groups: stagiaires, opera, ipausers, trust admins, admins, oldstaff Kerberos keys available: True SSH public key fingerprint: FA:76:85:EF:2A:D1:12:B9:A8:A4:F4:AE:45:B2:63:05 admin at ipasrv (ssh-dss) Before trying again, I just ran a 'dnf update' and rebooted the server on the new kernel (4.1.8-200.fc22.x86_64). On Mon, Oct 5, 2015 at 4:07 PM, Petr Vobornik wrote: > On 10/05/2015 12:55 PM, Fujisan wrote: > >> It is actually on the ipa server that ipa commands are not working. On ipa >> clients, I do not have errors. >> >> >> >> On Mon, Oct 5, 2015 at 12:27 PM, Fujisan wrote: >> >> I just noticed I can log in to the web UI with user admin and his >>> password. >>> >>> But when I try to configure firefox to use kerberos, I click on "Install >>> Kerberos Configuration Firefox Extension" button, a message appears >>> saying >>> "Firefox prevented this site from asking you to install software on your >>> computer", so I click on the "Allow" button and then another message >>> appears "The add-on downloaded from this site could not be installed >>> because it appears to be corrupt.". >>> >> > Here you hit https://fedorahosted.org/freeipa/ticket/4906 > > Fix(will be in 4.2.2 release) for this ticket changes the procedure for > new versions of Firefox to a manual configuration. Basically the steps for > Firefox which are described on page > http://your-ipa.example.test/ipa/config/ssbrowser.html > > > >>> And the ipa commands are still not working. >>> $ ipa user-show admin >>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>> Unauthorized >>> >>> >>> On Mon, Oct 5, 2015 at 12:13 PM, Fujisan wrote: >>> >>> I uninstalled the ipa server and reinstalled it. Then restored the >>>> backup. >>>> And then the following: >>>> >>>> $ keyctl list @s >>>> 3 keys in keyring: >>>> 437165764: --alswrv 0 65534 keyring: _uid.0 >>>> 556579409: --alswrv 0 0 user: >>>> ipa_session_cookie:host/zaira2.opera at OPERA >>>> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >>>> $ keyctl purge 556579409 >>>> purged 0 keys >>>> $ keyctl reap >>>> 0 keys reaped >>>> $ ipa user-show admin >>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>> Unauthorized >>>> $ keyctl list @s >>>> 3 keys in keyring: >>>> 437165764: --alswrv 0 65534 keyring: _uid.0 >>>> 556579409: --alswrv 0 0 user: >>>> ipa_session_cookie:host/zaira2.opera at OPERA >>>> 286806445: ---lswrv 0 65534 keyring: _persistent.0 >>>> >>>> ?It doesn't seem to purge or to reap.? >>>> >>>> >>>> >>>> On Mon, Oct 5, 2015 at 9:17 AM, Fujisan wrote: >>>> >>>> Good morning, >>>>> ? >>>>> Any suggestion what I should do?? >>>>> >>>>> ?I still have >>>>> >>>>> ?$ ipa user-show admin >>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>> Unauthorized >>>>> >>>>> >>>>> Regards. >>>>> >>>>> >>>>> On Fri, Oct 2, 2015 at 5:04 PM, Fujisan wrote: >>>>> >>>>> I only have this: >>>>>> >>>>>> $ keyctl list @s >>>>>> 1 key in keyring: >>>>>> 641467419: --alswrv 0 65534 keyring: _uid.0 >>>>>> $ >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 2, 2015 at 5:01 PM, Alexander Bokovoy < >>>>>> abokovoy at redhat.com> >>>>>> wrote: >>>>>> >>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>> >>>>>>> I forgot to mention that >>>>>>>> >>>>>>>> $ ipa user-show admin >>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>> Unauthorized >>>>>>>> >>>>>>>> This is most likely because of the cached session to your server. >>>>>>> >>>>>>> You can check if keyctl list @s >>>>>>> returns you something like >>>>>>> [root at m1 ~]# keyctl list @s >>>>>>> 2 keys in keyring: >>>>>>> 496745412: --alswrv 0 65534 keyring: _uid.0 >>>>>>> 215779962: --alswrv 0 0 user: >>>>>>> ipa_session_cookie:admin at EXAMPLE.COM >>>>>>> >>>>>>> If so, then notice the key number (215779962) for the session cookie, >>>>>>> and do: >>>>>>> keyctl purge 215779962 >>>>>>> keyctl reap >>>>>>> >>>>>>> This should make a next 'ipa ...' command run to ask for new cookie. >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 2, 2015 at 4:44 PM, Fujisan wrote: >>>>>>>> >>>>>>>> I still cannot login to the web UI. >>>>>>>> >>>>>>>>> >>>>>>>>> Here is what I did: >>>>>>>>> >>>>>>>>> 1. mv /etc/krb5.keytab /etc/krb5.keytab.save >>>>>>>>> 2. kinit admin >>>>>>>>> Password for admin at OPERA: >>>>>>>>> 3. ipa-getkeytab -s zaira2.opera -p host/zaira2.opera at OPERA -k >>>>>>>>> /etc/krb5.keytab >>>>>>>>> 4. systemctl restart sssd.service >>>>>>>>> 5. mv /etc/httpd/conf/ipa.keytab >>>>>>>>> /etc/httpd/conf/ipa.keytab.save >>>>>>>>> 6. ipa-getkeytab -s zaira2.opera -p HTTP/zaira2.opera at OPERA -k >>>>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>>>> 7. systemctl restart httpd.service >>>>>>>>> >>>>>>>>> >>>>>>>>> The log says now: >>>>>>>>> >>>>>>>>> Oct 02 16:40:56 zaira2.opera krb5kdc[9065](info): AS_REQ (9 etypes >>>>>>>>> {18 17 >>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication required >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 2, 2015 at 4:25 PM, Alexander Bokovoy < >>>>>>>>> abokovoy at redhat.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Well, I think I messed up when trying to configure cockpit to use >>>>>>>>>> >>>>>>>>>>> kerberos. >>>>>>>>>>> >>>>>>>>>>> What should I do to fix this? >>>>>>>>>>> >>>>>>>>>>> I have this on the ipa server: >>>>>>>>>>> $ klist -k >>>>>>>>>>> Keytab name: FILE:/etc/krb5.keytab >>>>>>>>>>> KVNO Principal >>>>>>>>>>> ---- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------------- >>>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>>> 2 host/zaira2.opera at OPERA >>>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>>> 1 nfs/zaira2.opera at OPERA >>>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>>> 3 HTTP/zaira2.opera at OPERA >>>>>>>>>>> >>>>>>>>>>> You can start by: >>>>>>>>>>> >>>>>>>>>>> 0. backup every file mentioned below >>>>>>>>>> 1. Move /etc/krb5.keytab somewhere >>>>>>>>>> 2. kinit as admin >>>>>>>>>> 3. ipa-getkeytab -s `hostname` -p host/`hostname` -k >>>>>>>>>> /etc/krb5.keytab >>>>>>>>>> 4. restart SSSD >>>>>>>>>> 5. Move /etc/httpd/conf/ipa.keytab somewhere >>>>>>>>>> 6. ipa-getkeytab -s `hostname` -p HTTP/`hostname` -k >>>>>>>>>> /etc/httpd/conf/ipa.keytab >>>>>>>>>> 7. Restart httpd >>>>>>>>>> >>>>>>>>>> Every time you run 'ipa-getkeytab', Kerberos key for the service >>>>>>>>>> specified by you is replaced on the server side so that keys in >>>>>>>>>> the >>>>>>>>>> keytabs become unusable. >>>>>>>>>> >>>>>>>>>> I guess cockpit instructions were for something that was not >>>>>>>>>> supposed to >>>>>>>>>> run on IPA master. On IPA master there are already all needed >>>>>>>>>> services >>>>>>>>>> (host/ and HTTP/) and their keytabs are in place. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Oct 2, 2015 at 3:45 PM, Alexander Bokovoy < >>>>>>>>>> >>>>>>>>>>> abokovoy at redhat.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Fri, 02 Oct 2015, Fujisan wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> More info: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I can initiate a ticket: >>>>>>>>>>>>> $ kdestroy >>>>>>>>>>>>> $ kinit admin >>>>>>>>>>>>> >>>>>>>>>>>>> but cannot view user admin: >>>>>>>>>>>>> $ ipa user-show admin >>>>>>>>>>>>> ipa: ERROR: cannot connect to 'https://zaira2.opera/ipa/json': >>>>>>>>>>>>> Unauthorized >>>>>>>>>>>>> >>>>>>>>>>>>> $ 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-dnskeysyncd Service: RUNNING >>>>>>>>>>>>> ipa: INFO: The ipactl command was successful >>>>>>>>>>>>> >>>>>>>>>>>>> /var/log/messages: >>>>>>>>>>>>> Oct 2 14:48:55 zaira2 [sssd[ldap_child[4991]]]: Failed to >>>>>>>>>>>>> initialize >>>>>>>>>>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt >>>>>>>>>>>>> integrity >>>>>>>>>>>>> check >>>>>>>>>>>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>>>>>>>>>>> >>>>>>>>>>>>> What did you do? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> This and the log below about HTTP/zaira2.opera at OPERA show that >>>>>>>>>>>> you have >>>>>>>>>>>> different keys in LDAP and in your keytab files for >>>>>>>>>>>> host/zaira2.opera >>>>>>>>>>>> and HTTP/zaira2.opera principals. This might happen if somebody >>>>>>>>>>>> removed >>>>>>>>>>>> the principals from LDAP (ipa service-del/ipa service-add, or >>>>>>>>>>>> ipa >>>>>>>>>>>> host-del/ipa host-add) so that they become non-synchronized with >>>>>>>>>>>> whatever you have in the keytab files. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Oct 2, 2015 at 2:26 PM, Fujisan >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I cannot login to the web UI anymore. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The password or username you entered is incorrect. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Log says: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>>>> etypes >>>>>>>>>>>>>> {18 17 >>>>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: NEEDED_PREAUTH: >>>>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>>>> for krbtgt/OPERA at OPERA, Additional pre-authentication >>>>>>>>>>>>>> required >>>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>>>> fd 12 >>>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): preauth >>>>>>>>>>>>>> (encrypted_timestamp) verify failure: Decrypt integrity check >>>>>>>>>>>>>> failed >>>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): AS_REQ (9 >>>>>>>>>>>>>> etypes >>>>>>>>>>>>>> {18 17 >>>>>>>>>>>>>> 16 23 25 26 1 3 2}) 10.0.21.18: PREAUTH_FAILED: >>>>>>>>>>>>>> HTTP/zaira2.opera at OPERA >>>>>>>>>>>>>> for krbtgt/OPERA at OPERA, Decrypt integrity check failed >>>>>>>>>>>>>> Oct 02 14:22:57 zaira2.opera krb5kdc[3225](info): closing down >>>>>>>>>>>>>> fd 12 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have no idea what went wrong. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What can I do? >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?Regards, >>>>>>>>>>>>>> Fuji? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> / Alexander Bokovoy >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>> / 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> / Alexander Bokovoy >>>>>>> >>>>>>> > > > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Mon Oct 5 15:11:01 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 5 Oct 2015 08:11:01 -0700 Subject: [Freeipa-users] More replication fun Message-ID: <56129305.6060307@gmail.com> So here is a fun question -- how is this possible? from ipa-replica-manage list-ruv ipa002.example.com 389 6 ipa003.example.com 389 30 <----- ???? Huh??? ipa003.example.com 389 33 <----- ipa004.example.com 389 24 ~Janelle From rcritten at redhat.com Mon Oct 5 15:19:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2015 11:19:22 -0400 Subject: [Freeipa-users] admin loses access? In-Reply-To: <56128FFB.3020606@gmail.com> References: <56116104.3020404@gmail.com> <56117E17.2050302@physik.uni-wuppertal.de> <56128BA6.4040805@redhat.com> <56128FFB.3020606@gmail.com> Message-ID: <561294FA.4020803@redhat.com> Janelle wrote: > On 10/5/15 7:39 AM, Rob Crittenden wrote: >> Torsten Harenberg wrote: >>> Hi Janelle, >>> >>> Am 04.10.2015 um 19:25 schrieb Janelle: >>>> Just wondering if anyone knows why this happens from time to time on >>>> servers: >>>> >>>> $ kinit admin >>>> kinit: Clients credentials have been revoked while getting initial >>>> credentials >>>> >>>> there are no failed logins to the admin account - not even any login >>>> attempts, so it is not like someone is getting the account locked out. >>>> Just curious if anyone else has seen in. With 16 masters, it occurs >>>> randomly on some hosts, but eventually clears either on its own or with >>>> a restart of IPA. However, I just restarted IPA on this server and >>>> after >>>> about 2-3 minutes it works again. >>>> >>> I am seeing the same, see my mail "kinit admin not working anymore >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. >>> Actually, wasn't it you who wanted to open a ticket? >>> >>> Have a nice evening, >>> >>> Torsten >>> >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show >> --user=admin` and provide that so we can potentially see what is going >> on. >> >> rob >> > I am curious -- if you have 16 masters, but this only happens once in > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to > understand the thinking of where you are going?? I will for sure do this > the next time it happens, but I want to understand logic? Lockout is per-master because the failed auth count and successful login date is not replicated due to performance issues. The user-status command will collect the lockout attributes from each server, but it doesn't do the calculations, so the pwpolicy is needed as well in order to figure out whether on a given master the user is locked out. rob From simo at redhat.com Mon Oct 5 17:16:02 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 5 Oct 2015 13:16:02 -0400 Subject: [Freeipa-users] More replication fun In-Reply-To: <56129305.6060307@gmail.com> References: <56129305.6060307@gmail.com> Message-ID: <5612B052.8020104@redhat.com> On 05/10/15 11:11, Janelle wrote: > So here is a fun question -- how is this possible? > > from ipa-replica-manage list-ruv > > ipa002.example.com 389 6 > ipa003.example.com 389 30 <----- ???? Huh??? > ipa003.example.com 389 33 <----- > ipa004.example.com 389 24 ipa003 was reinstalled but the RUV was not properly cleaned Simo. -- Simo Sorce * Red Hat, Inc * New York From janellenicole80 at gmail.com Mon Oct 5 17:28:31 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 5 Oct 2015 10:28:31 -0700 Subject: [Freeipa-users] More replication fun In-Reply-To: <5612B052.8020104@redhat.com> References: <56129305.6060307@gmail.com> <5612B052.8020104@redhat.com> Message-ID: <5612B33F.50807@gmail.com> On 10/5/15 10:16 AM, Simo Sorce wrote: > On 05/10/15 11:11, Janelle wrote: >> So here is a fun question -- how is this possible? >> >> from ipa-replica-manage list-ruv >> >> ipa002.example.com 389 6 >> ipa003.example.com 389 30 <----- ???? Huh??? >> ipa003.example.com 389 33 <----- >> ipa004.example.com 389 24 > > ipa003 was reinstalled but the RUV was not properly cleaned > > Simo. > > So there is no conflict even with a duplicate like that? I mean the server only physically exists once, so I guess it should not cause a problem. I mean replication seems to be working, it just seems odd that I saw that. You would think that the normal ipa-replica-manage "del" options would do all the proper cleaning, but apparently not. Thanks for the clarification. ~J From rcritten at redhat.com Mon Oct 5 17:31:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2015 13:31:10 -0400 Subject: [Freeipa-users] More replication fun In-Reply-To: <5612B33F.50807@gmail.com> References: <56129305.6060307@gmail.com> <5612B052.8020104@redhat.com> <5612B33F.50807@gmail.com> Message-ID: <5612B3DE.9060106@redhat.com> Janelle wrote: > On 10/5/15 10:16 AM, Simo Sorce wrote: >> On 05/10/15 11:11, Janelle wrote: >>> So here is a fun question -- how is this possible? >>> >>> from ipa-replica-manage list-ruv >>> >>> ipa002.example.com 389 6 >>> ipa003.example.com 389 30 <----- ???? Huh??? >>> ipa003.example.com 389 33 <----- >>> ipa004.example.com 389 24 >> >> ipa003 was reinstalled but the RUV was not properly cleaned >> >> Simo. >> >> > So there is no conflict even with a duplicate like that? I mean the > server only physically exists once, so I guess it should not cause a > problem. I mean replication seems to be working, it just seems odd that > I saw that. You would think that the normal ipa-replica-manage "del" > options would do all the proper cleaning, but apparently not. I'd recommend cleaning the unused RUV as it causes the directory server to do work on it, even if it results in nothing. The server should clean up RUVs upon deletion but it is done as a task which can fail, but by that point the agreement is already gone. rob From aebruno2 at buffalo.edu Mon Oct 5 18:38:51 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Mon, 5 Oct 2015 14:38:51 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <561253AA.4050509@redhat.com> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> Message-ID: <20151005183851.GF11918@dead.ccr.buffalo.edu> On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote: > On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: > > On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: > >> What's the best way to re-initialize a replica? > >> > >> Suppose one of your replicas goes south.. is there a command to tell > >> that replicate to re-initialize from the first master (instead of > >> removing/re-adding the replica from the topology)? > > > > Found the command I was looking for: > > ipa-replica-manage re-initialize --from xxx > > > > However, one of our replicates is down and can't seem to re-initialize > > it. Starting ipa fails (via systemctl restart ipa): > > > > ipactl status > > Directory Service: RUNNING > > krb5kdc Service: STOPPED > > kadmin Service: STOPPED > > named Service: STOPPED > > ipa_memcached Service: STOPPED > > httpd Service: STOPPED > > pki-tomcatd Service: STOPPED > > ipa-otpd Service: STOPPED > > ipa: INFO: The ipactl command was successful > > > > > > Errors from the dirsrv show: > > > > : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > > [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > > [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) > > [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > > [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > > > > > > Attempting to re-initialize fails: > > > > ipa-replica-manage re-initialize --from master > > Connection timed out. > > > > > > I verified time is in sync and DNS forward/reverse resolution is working. > > > > Any pointers on what else to try? > > > > Thanks! > > > > --Andrew > > Given that your Kerberos server instance is down, I would start investigating > Kerberos logs to see why. So looks like the dirsrv service comes up but with GSS errors about kerb credentials. However, the rest of the services including the krb5kdc fail to come up. Errors from the kdc logs suggest DNS: LOOKING_UP_CLIENT: DNS/replica at REALM Server error FreeIPA is configured to serve DNS and this replica resolves it's own DNS in /etc/resolv.conf (127.0.0.1) I tried pointing /etc/resolv.conf to another (good) replica and even tried adjusting /etc/krb5.conf to point at another kdc to try and get a ticket however it still tries to connect to the local kdc (which fails to start). I'm inclined to re-install this replica and start fresh. I'm curious if we can re-kickstart this host from a fresh os/freeipa install and run the ipa-replica-manage re-initialize --from master command. The replica will have the same name.. is this possible? Would we need to backup the /var/lib/ipa/replica-info-XXX.gpg file? --Andrew From rcritten at redhat.com Mon Oct 5 18:48:48 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2015 14:48:48 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151005183851.GF11918@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> Message-ID: <5612C610.8060706@redhat.com> Andrew E. Bruno wrote: > On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote: >> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: >>> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: >>>> What's the best way to re-initialize a replica? >>>> >>>> Suppose one of your replicas goes south.. is there a command to tell >>>> that replicate to re-initialize from the first master (instead of >>>> removing/re-adding the replica from the topology)? >>> >>> Found the command I was looking for: >>> ipa-replica-manage re-initialize --from xxx >>> >>> However, one of our replicates is down and can't seem to re-initialize >>> it. Starting ipa fails (via systemctl restart ipa): >>> >>> ipactl status >>> Directory Service: RUNNING >>> krb5kdc Service: STOPPED >>> kadmin Service: STOPPED >>> named Service: STOPPED >>> ipa_memcached Service: STOPPED >>> httpd Service: STOPPED >>> pki-tomcatd Service: STOPPED >>> ipa-otpd Service: STOPPED >>> ipa: INFO: The ipactl command was successful >>> >>> >>> Errors from the dirsrv show: >>> >>> : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) >>> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) >>> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) >>> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) >>> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) >>> >>> >>> Attempting to re-initialize fails: >>> >>> ipa-replica-manage re-initialize --from master >>> Connection timed out. >>> >>> >>> I verified time is in sync and DNS forward/reverse resolution is working. >>> >>> Any pointers on what else to try? >>> >>> Thanks! >>> >>> --Andrew >> >> Given that your Kerberos server instance is down, I would start investigating >> Kerberos logs to see why. > > > So looks like the dirsrv service comes up but with GSS errors about kerb > credentials. However, the rest of the services including the krb5kdc > fail to come up. Errors from the kdc logs suggest DNS: DS complaining about GSS is somewhat normal during startup as it is a bit noisy. The other errors suggest there is no data in the backend. An ldapsearch would confirm that. > > LOOKING_UP_CLIENT: DNS/replica at REALM Server error > > FreeIPA is configured to serve DNS and this replica resolves it's own > DNS in /etc/resolv.conf (127.0.0.1) > > I tried pointing /etc/resolv.conf to another (good) replica and even > tried adjusting /etc/krb5.conf to point at another kdc to try and get a > ticket however it still tries to connect to the local kdc (which fails > to start). > > I'm inclined to re-install this replica and start fresh. I'm curious if > we can re-kickstart this host from a fresh os/freeipa install and run > the ipa-replica-manage re-initialize --from master command. The replica > will have the same name.. is this possible? Would we need to backup the > /var/lib/ipa/replica-info-XXX.gpg file? It needs to have its own principal in order to re-initialize. It sounds like it has nothing which is why replication is failing. I'd recommend generating a new replica file. There is no value in re-using the old one and it could be harmful if the certificates are expired. You'll need to delete all replication agreements this master had and you'll need to use the --force option since it won't be accessible. When you re-install the master it will get all the current data as part of the setup so no need to re-initialize after that. rob From DFischer at PetSmart.com Mon Oct 5 19:24:06 2015 From: DFischer at PetSmart.com (David Fischer) Date: Mon, 5 Oct 2015 12:24:06 -0700 Subject: [Freeipa-users] AD Cross Realm Trust + AIX In-Reply-To: References: Message-ID: <264C67C6145722439414DB6176F5A6E146B356C629@EXMBX02.ssg.petsmart.com> Crony, I also am trying to setup both AIX 6.1 and AIX 7 clients. Is there anyway I could get you to post you working configurations? Thanks, David -----Original Message-----From: crony > To: freeipa-users at redhat.com Subject: [Freeipa-users] AD Cross Realm Trust + AIX Date: Thu, 12 Feb 2015 19:06:59 +0100 Hi All, can I ask you for some advice? My setup is: - updated RHEL7 as IPA server (UX.EXAMPLE.COM) in trust with Active Directory 2008R2 domain (EXAMPLE.COM) - AIX 7 as IPA client I'm using compat tree for connecting AIX as client. A lot of things work correctly: # /usr/krb5/bin/kinit leszek Password for ad_user at EXAMPLE.COM: # /usr/krb5/bin/klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0 Default principal: ad_user at EXAMPLE.COM Valid starting Expires Service principal 02/12/15 15:46:23 02/13/15 01:46:31 krbtgt/EXAMPLE.COM at EXAMPLE.COM Renew until 02/13/15 01:46:23 # lsldap -a passwd ad_user at EXAMPLE.COM dn: uid=ad_user at example.com,cn=users,cn=compat,dc=ux,dc=example,dc=com objectClass: posixAccount objectClass: extensibleObject objectClass: top gecos: ad_user cn: ad_user uidNumber: 1036620735 gidNumber: 1036620735 homeDirectory: /home/example.com/ad_user ipaNTSecurityIdentifier: S-1-5-21-XXXXXXXX-XXXXX-XXXXXX uid: ad_user at example.com # id ad_user at EXAMPLE.COM uid=1036620735(ad_user at example.com) gid=1036620735(ad_user at example.com) groups=1036620733(another_group at example.com) Here I found the first problem: # su - ad_user at EXAMPLE.COM 3004-614 Unable to change directory to "". You are in "/home/guest" instead. $ id uid=1036620735(ad_user at example.com) gid=1036620735(ad_user at example.com) groups=1036620733(another_group at example.com) The "3004-614 Unable to change directory to ""." appears after I added to /etc/methods.cfg: KRB5A: program = /usr/lib/security/KRB5A program_64 = /usr/lib/security/KRB5A_64 options = authonly LDAP: program = /usr/lib/security/LDAP program_64 =/usr/lib/security/LDAP64 Without these lines there is no error "about change to home directory", su from root works smoothly and entered the user to the homedirectory. But now I can't ssh to the system, because I have no correct registry. ----- I made another test: if I can log in by just IPA user, ex. admin. There is no such problem: # id admin uid=30000(admin) gid=30000(admins) # su - admin -bash-3.2$ pwd /export/home/admin -bash-3.2$ id uid=30000(admin) gid=30000(admins) # ssh admin at localhost admin at localhost's password: ******************************************************************************* * * * * * Welcome to AIX Version 7.1! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * ******************************************************************************* -bash-3.2$ id uid=30000(admin) gid=30000(admins) Any idea what is wrong? I have already changed the AIX max_logname from 8 to 40 characters. Maybe the "@" character in login name is a problem? Thank you in advance. -- /lm ________________________________ ##################################################################################### The information contained in this electronic mail message, including attachments, if any, is PetSmart confidential information. It is intended only for the use of the person(s) named above. If the reader of this message is not the intended recipient, or has received this message in error, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify the sender via e-mail and promptly delete the original message. ##################################################################################### From nathan at nathanpeters.com Mon Oct 5 19:48:12 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Mon, 5 Oct 2015 12:48:12 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <56122EBD.1030405@redhat.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> <56122EBD.1030405@redhat.com> Message-ID: >>> Looking at the log entries, it appears that there may have been a >>> network >>> connectivity 'blip' (maybe a switch or router was restarted) at some >>> point >>> and even after connectivity was restored, the global forwarding was >>> failing because the "we can't contact our forwarder" status seemed to >>> get >>> stuck in memory. > > Most likely. > >>> [root at dc1 ~]# ipa dnsconfig-show >>> Global forwarders: 10.21.0.14 >>> Allow PTR sync: TRUE > > This means that you are using the default forward policy which is 'first'. > I.e. BIND daemon on the IPA server is trying to use the forwarder first > and > when it fails it fallbacks to asking server on the public Internet. > > I speculate that public servers know nothing about the name you were > asking > for and this negative answer got cached. This is default behavior in BIND > and > IPA did not change it. > > Workaround for network problems could be > $ ipa dnsconfig-mod --forward-policy=only > which will prevent BIND from falling back to public servers. > > Anyway, you should solve network connectivity problems, too :-) > > I hope this helps. > > -- > Petr^2 Spacek > > -- > 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 > Ok, we managed to figure out what was happening here, but I still think there is a bug somewhere in the FreeIPA DNS components that is exacerbating the issue. We have split DNS in our company. We have a public copy of our DNS records, which contain only A records. We also have an internal copy of our DNS records, which contains a bunch of CNAME records. When we use nslookup to query the IPA server for stash.externaldomain.net NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns the associated A address. When we query FreeIPA though a DNS client, FreeIPA returns that stash is a cname and does not return the associated A address. It seems like at that point, FreeIPA decides that instead of sticking in 'forward' mode and forwarding the request for the CNAME From nathan at nathanpeters.com Mon Oct 5 19:57:24 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Mon, 5 Oct 2015 12:57:24 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <56122EBD.1030405@redhat.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> <56122EBD.1030405@redhat.com> Message-ID: <0fb30c0bd39a77fec7edc25c39cdc144.squirrel@webmail.nathanpeters.com> >>> Looking at the log entries, it appears that there may have been a >>> network >>> connectivity 'blip' (maybe a switch or router was restarted) at some >>> point >>> and even after connectivity was restored, the global forwarding was >>> failing because the "we can't contact our forwarder" status seemed to >>> get >>> stuck in memory. > > Most likely. > >>> [root at dc1 ~]# ipa dnsconfig-show >>> Global forwarders: 10.21.0.14 >>> Allow PTR sync: TRUE > > This means that you are using the default forward policy which is 'first'. > I.e. BIND daemon on the IPA server is trying to use the forwarder first > and > when it fails it fallbacks to asking server on the public Internet. > > I speculate that public servers know nothing about the name you were > asking > for and this negative answer got cached. This is default behavior in BIND > and > IPA did not change it. > > Workaround for network problems could be > $ ipa dnsconfig-mod --forward-policy=only > which will prevent BIND from falling back to public servers. > > Anyway, you should solve network connectivity problems, too :-) > > I hope this helps. > > -- > Petr^2 Spacek > > -- > 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 > Ok, we managed to figure out what was happening here, but I still think there is a bug somewhere in the FreeIPA DNS components that is exacerbating the issue. We have split DNS in our company. We have a public copy of our DNS records, which contain only A records. We also have an internal copy of our DNS records, which contains a bunch of CNAME records. When we use nslookup to query the IPA server for stash.externaldomain.net NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns both the CNAME and the associated A address. When we query FreeIPA though a DNS client, FreeIPA returns that stash is a CNAME and does not return the associated A address. It seems like at that point, FreeIPA decides that instead of sticking in 'forward' mode and forwarding the request for the CNAME record to the forwarding server, it decides instead to switch into recursive mode and begin the lookup by querying root servers for externaldomain.net at which point since it is going out to the general internet, it gets back answers from our public facing DNS servers (remember we use split DNS). The answer it gets is (quite rightly) that there is no such CNAME record on the public DNS server. So I have a couple questions about how the forward first policy is supposed to work... 1. In forward first mode, if the forward server returns a CNAME, is FreeIPA supposed to ask the same forwarding server for the A record associated with the CNAME, or is it supposed to then flip into recursive mode and go to the root servers to find the CNAME? I would expect #1, but it seems like #2 is always happening no matter what. I would only expect it to attempt recursion if the initial query actually failed, not just returned something other than an A record. 2. We did some more network packet capture, and noticed that in forward first mode, the FreeIPA server, always sent out both a forward request to the forwarding server, and an additional simultaneous request to the root name servers (recursive mode). It got back responses to both the forwarded and recursive queries it had performed. The recursive query failed due to split DNS and the forwarded query succeeded due to it going to an internal server which had the correct records. Strangely enough... the IPA server ignored the successful forwarded answer, and sent back the 'failed' answer it had gotten through recursion back to the requesting client. What is the behavior supposed to be in this situation and why is the server always sending out the recursive request, even when it gets a valid answer from the forwarded request? From prasun.gera at gmail.com Mon Oct 5 23:44:07 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Mon, 5 Oct 2015 16:44:07 -0700 Subject: [Freeipa-users] admin loses access? In-Reply-To: <561294FA.4020803@redhat.com> References: <56116104.3020404@gmail.com> <56117E17.2050302@physik.uni-wuppertal.de> <56128BA6.4040805@redhat.com> <56128FFB.3020606@gmail.com> <561294FA.4020803@redhat.com> Message-ID: I was facing similar issues, and ended up changing the username from admin to something else since admin is a common name in brute force ssh attacks. It was getting locked out in spite of using fail2ban. I guess fail2ban can be tweaked to block the host before ipa blocks the admin account, but I didn't bother doing that. Changing the username seemed easier. On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden wrote: > Janelle wrote: > > On 10/5/15 7:39 AM, Rob Crittenden wrote: > >> Torsten Harenberg wrote: > >>> Hi Janelle, > >>> > >>> Am 04.10.2015 um 19:25 schrieb Janelle: > >>>> Just wondering if anyone knows why this happens from time to time on > >>>> servers: > >>>> > >>>> $ kinit admin > >>>> kinit: Clients credentials have been revoked while getting initial > >>>> credentials > >>>> > >>>> there are no failed logins to the admin account - not even any login > >>>> attempts, so it is not like someone is getting the account locked out. > >>>> Just curious if anyone else has seen in. With 16 masters, it occurs > >>>> randomly on some hosts, but eventually clears either on its own or > with > >>>> a restart of IPA. However, I just restarted IPA on this server and > >>>> after > >>>> about 2-3 minutes it works again. > >>>> > >>> I am seeing the same, see my mail "kinit admin not working anymore > >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. > >>> Actually, wasn't it you who wanted to open a ticket? > >>> > >>> Have a nice evening, > >>> > >>> Torsten > >>> > >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show > >> --user=admin` and provide that so we can potentially see what is going > >> on. > >> > >> rob > >> > > I am curious -- if you have 16 masters, but this only happens once in > > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to > > understand the thinking of where you are going?? I will for sure do this > > the next time it happens, but I want to understand logic? > > Lockout is per-master because the failed auth count and successful login > date is not replicated due to performance issues. > > The user-status command will collect the lockout attributes from each > server, but it doesn't do the calculations, so the pwpolicy is needed as > well in order to figure out whether on a given master the user is locked > out. > > rob > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Tue Oct 6 01:40:10 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Mon, 05 Oct 2015 21:40:10 -0400 Subject: [Freeipa-users] separating authoritative servers from recursive servers Message-ID: <5613267A.2020507@gmail.com> i have two bind instances in somewhat of a multi-master server arrangement, where they share the same ldap backend via bind-dyndb-ldap. currently, they are authoritative and recursive servers, and i want to change things up a bit. i want to move the recursive function to a third device. for this, i believe i need to set a forwarder for the two current servers. i believe i would do this by adding the idnsForwarders object (with value) on the OU that is the idnsConfigObject. i am looking for a sanity check, to ensure that i am not overlooking something important. are there any steps i am missing? i want the current two instances to be authoritative for all my forward and reverse zones, and use the forwarder for all recursion. the forwarder instance is already running, and is setup to answer queries from only the two current instances. i think i just need to point the current instances to the forwarder instance, and turn off recursion on them. thanks in advance, brendan From rcritten at redhat.com Tue Oct 6 02:35:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2015 22:35:10 -0400 Subject: [Freeipa-users] admin loses access? In-Reply-To: References: <56116104.3020404@gmail.com> <56117E17.2050302@physik.uni-wuppertal.de> <56128BA6.4040805@redhat.com> <56128FFB.3020606@gmail.com> <561294FA.4020803@redhat.com> Message-ID: <5613335E.4010303@redhat.com> Prasun Gera wrote: > I was facing similar issues, and ended up changing the username from > admin to something else since admin is a common name in brute force ssh > attacks. It was getting locked out in spite of using fail2ban. I guess > fail2ban can be tweaked to block the host before ipa blocks the admin > account, but I didn't bother doing that. Changing the username seemed > easier. Right, the power lies in the admins group. The only exception is in the replica connection checker where the name 'admin' is hardcoded. There is a ticket open to fix this. Otherwise AFAIK the name shouldn't matter. rob > > On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden > wrote: > > Janelle wrote: > > On 10/5/15 7:39 AM, Rob Crittenden wrote: > >> Torsten Harenberg wrote: > >>> Hi Janelle, > >>> > >>> Am 04.10.2015 um 19:25 schrieb Janelle: > >>>> Just wondering if anyone knows why this happens from time to > time on > >>>> servers: > >>>> > >>>> $ kinit admin > >>>> kinit: Clients credentials have been revoked while getting initial > >>>> credentials > >>>> > >>>> there are no failed logins to the admin account - not even any > login > >>>> attempts, so it is not like someone is getting the account > locked out. > >>>> Just curious if anyone else has seen in. With 16 masters, it occurs > >>>> randomly on some hosts, but eventually clears either on its own > or with > >>>> a restart of IPA. However, I just restarted IPA on this server and > >>>> after > >>>> about 2-3 minutes it works again. > >>>> > >>> I am seeing the same, see my mail "kinit admin not working anymore > >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT. > >>> Actually, wasn't it you who wanted to open a ticket? > >>> > >>> Have a nice evening, > >>> > >>> Torsten > >>> > >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show > >> --user=admin` and provide that so we can potentially see what is > going > >> on. > >> > >> rob > >> > > I am curious -- if you have 16 masters, but this only happens once in > > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to > > understand the thinking of where you are going?? I will for sure > do this > > the next time it happens, but I want to understand logic? > > Lockout is per-master because the failed auth count and successful login > date is not replicated due to performance issues. > > The user-status command will collect the lockout attributes from each > server, but it doesn't do the calculations, so the pwpolicy is needed as > well in order to figure out whether on a given master the user is locked > out. > > rob > > -- > 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 > > From dkupka at redhat.com Tue Oct 6 06:40:04 2015 From: dkupka at redhat.com (David Kupka) Date: Tue, 6 Oct 2015 08:40:04 +0200 Subject: [Freeipa-users] Possible bug in ipa-replica-install/pkispawn - or maybe lib mismatch In-Reply-To: References: Message-ID: <56136CC4.7020600@redhat.com> On 23/09/15 10:35, Michael Lasevich wrote: > Ok, I just went through process of migrating our IPA setup from 4.1.2 > running on Fedora 20 (?? may have been 21) to 4.1.4 on CentOS 7 (MKosek > Copr version) and run into a nasty bug. The replica-install crashes during > CA configuration with something like: > > ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpXXXXXX'' returned non-zero > exit status 1 > > Skipping CA works, but I needed the CA. > > Upon digging into this, I found the issue appears to be in pki python, in > file: > > /usr/lib/python2.7/site-packages/pki/system.py > > It looks like it makes a call to "/ca/rest/securityDomain/domainInfo" and > gets an XML doc which it converts to JSON. Somehow it gets mangled before > it looks at it. XML has outermost tag of "DomainInfo" - but JSON starts > with "Subsystem" (one layer lower) - I am guessing JSON converted strips > the "root" tag. > > I bypassed this by hardcoding id as "IPA" - but obviously that is > sub-optimal > > Looking at Fedora box, it looks like the difference is in the version of > PKI package that provides the lib - on Centos you get pki-base 10.1.2 > (pki-base-10.1.2-7.1.el7.centos.noarch) - while on Fedore it was a 10.2 > branch (and significantly different content in that file) > > Anyway, I saw some reports of this bug in searches and no answers - so I > figured I would offer this pointer in (hopefully) the right direction. > > -M > > > Hello Michael! Thanks for notifying us. Martin just updated the copr repository (https://copr.fedoraproject.org/coprs/mkosek/freeipa/) with newer version of PKI packages and I tested replication between Fedora 21 and CentOS 7.1 (both FreeIPA 4.1.4) and it works for me as expected. Could you please try it again? -- David Kupka From alexanders.mailinglists+nospam at gmail.com Tue Oct 6 09:26:42 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Tue, 6 Oct 2015 11:26:42 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: <20151005120744.GB19585@p.redhat.com> References: <20151002155951.GB3127@hendrix.redhat.com> <20151005120744.GB19585@p.redhat.com> Message-ID: Hi With further debugging, I discovered, that I messed up the /etc/sssd/sssd.conf file. There, I added: ? [domain/customer.company.internal] krb5_realm = customer.company.internal ? Exactly like that. With "krb5_realm = customer.company.internal"; ie. with the realm in lowercase letters. After having changed that to uppercase letters (ie. "krb5_realm = CUSTOMER.COMPANY.INTERNAL"), it works fine. Thanks for your time and help ;) Cheers, Alexander 2015-10-05 14:07 GMT+02:00 Sumit Bose : > On Mon, Oct 05, 2015 at 09:00:13AM +0200, Alexander Skwar wrote: > > Hi > > > > Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try > > to login with SSH and enter a password. > > Can you try to increase the debug_level to 0xFFF0? > > > > > kinit doesn't work. > > > > $ kinit -k > > kinit: Permission denied while getting initial credentials > > > > For this test, I was root and then did a "su - user" and then "kinit -k". > > Also after the "kinit -k", nothing is in the krb5_child.log. > > The 'kinit -k' has to be done as root. It will only check if the client > can connect to the KDC at all and tries to get a TGT for the host. > > It's expected that during this operation nothing is added to the SSSD > logs because the kinit utility work independent of SSSD. > > bye, > Sumit > > > > > Regards, > > Alexander > > > > > > 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > > > > > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > > > > Hello > > > > > > > > How do I get password authentication to work with freeipa-client > > > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > > > > > > > Long version follows :) > > > > > > > > We've got an IPA server with the Red Hat Identity Management server > > > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > > > > users and groups there and would now like to login with SSH. When I > > > > store a SSH key for the user account, I can login just fine, using > > > > this SSH key. But I'd like/need to use passwords as well. And sudo > > > > also doesn't work, when it's asking for passwords - I supposed, > > > > it's the same root cause. > > > > > > > > Let's stick with SSH. > > > > > > > > Initially, I installed the FreeIPA client with this command line: > > > > > > > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > > > > --enable-dns-updates --unattended \ > > > > --principal=admin --password=correctone \ > > > > --domain=customer.company.internal \ > > > > --server=auth01.customer.company.internal > > > > > > > > I then try to do a SSH login with: > > > > > > > > ssh -l ewt at customer.company.internal 192.168.229.143 > > > > or: > > > > ssh -l ewt 192.168.229.143 > > > > > > > > Password authentication doesn't work. > > > > > > > > In the /var/log/syslog on the system where I try to login, I find > this: > > > > > > > > 2015-10-02T15:33:38.771291+02:00 mgmt02 > [sssd[krb5_child[14154]]]: > > > > Key table entry not found > > > > > > > > After having turned up the debug level of the sssd with "sssd -i -f > -d > > > > 0x0770 --debug-timestamps=1", I find the following in the system log > > > > files: > > > > > > > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > > > > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > > > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > > > > pam_sss(sshd:auth): received for user ewt: 4 (System error) > > > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > > > > password for ewt from 212.71.117.1 port 58136 ssh2 > > > > > > > > TBH, I don't quite understand it. Anyway, in > > > > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > > > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > [read_pipe_handler] (0x0400): EOF received, client finished > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > [parse_krb5_child_response] (0x0020): message too short. > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > [krb5_auth_done] (0x0040): Could not parse child response [22]: > > > > Invalid argument > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > > > > > > > Well? What am I doing wrong or what might I have forgotten? > > > > > > We need to also see the krb5_child.log but please check if the keytab > is > > > correct (ie kinit -k works). > > > > > > -- > > > 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 > > > > > > > > > > > -- > > > > > > Alexander > > -- > > => *Google+* => http://plus.skwar.me <== > > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > > > -- > > 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 > > -- Alexander -- => *Google+* => http://plus.skwar.me <== => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 6 11:42:45 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 6 Oct 2015 13:42:45 +0200 Subject: [Freeipa-users] separating authoritative servers from recursive servers In-Reply-To: <5613267A.2020507@gmail.com> References: <5613267A.2020507@gmail.com> Message-ID: <5613B3B5.9040200@redhat.com> On 6.10.2015 03:40, Brendan Kearney wrote: > i have two bind instances in somewhat of a multi-master server arrangement, > where they share the same ldap backend via bind-dyndb-ldap. currently, they > are authoritative and recursive servers, and i want to change things up a > bit. i want to move the recursive function to a third device. for this, i > believe i need to set a forwarder for the two current servers. i believe i > would do this by adding the idnsForwarders object (with value) on the OU that > is the idnsConfigObject. > > i am looking for a sanity check, to ensure that i am not overlooking something > important. are there any steps i am missing? i want the current two > instances to be authoritative for all my forward and reverse zones, and use > the forwarder for all recursion. the forwarder instance is already running, > and is setup to answer queries from only the two current instances. i think i > just need to point the current instances to the forwarder instance, and turn > off recursion on them. Hmm, I think that there is some confusion about terms we use. Pure authoritative server would give out answers only for zones it is authoritative for (i.e. zones defined in /etc/named.conf or LDAP) and refuse to answer all other queries. Is that what are you looking for? In contrast, a recursive server would answer query for any zone. If you really want to separate authoritative and recursive roles, then you should: (0. As always: Make sure that delegation for all your zones is correct.) 1. Set up recursive-only server. Add 'allow-recursion { IP_range; };' to named.conf. 2. Reconfigure all clients to use the recursive-only server and not to ask authoritative servers directly. 3. Reconfigure authoritative servers by adding allow-recursion { none; }; to named.conf. No changes in LDAP should be necessary. Does it answer your question? -- Petr^2 Spacek From pspacek at redhat.com Tue Oct 6 11:48:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 6 Oct 2015 13:48:40 +0200 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <0fb30c0bd39a77fec7edc25c39cdc144.squirrel@webmail.nathanpeters.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> <56122EBD.1030405@redhat.com> <0fb30c0bd39a77fec7edc25c39cdc144.squirrel@webmail.nathanpeters.com> Message-ID: <5613B518.7060805@redhat.com> On 5.10.2015 21:57, nathan at nathanpeters.com wrote: >>>> Looking at the log entries, it appears that there may have been a >>>> network >>>> connectivity 'blip' (maybe a switch or router was restarted) at some >>>> point >>>> and even after connectivity was restored, the global forwarding was >>>> failing because the "we can't contact our forwarder" status seemed to >>>> get >>>> stuck in memory. >> >> Most likely. >> >>>> [root at dc1 ~]# ipa dnsconfig-show >>>> Global forwarders: 10.21.0.14 >>>> Allow PTR sync: TRUE >> >> This means that you are using the default forward policy which is 'first'. >> I.e. BIND daemon on the IPA server is trying to use the forwarder first >> and >> when it fails it fallbacks to asking server on the public Internet. >> >> I speculate that public servers know nothing about the name you were >> asking >> for and this negative answer got cached. This is default behavior in BIND >> and >> IPA did not change it. >> >> Workaround for network problems could be >> $ ipa dnsconfig-mod --forward-policy=only >> which will prevent BIND from falling back to public servers. >> >> Anyway, you should solve network connectivity problems, too :-) >> >> I hope this helps. >> >> -- >> Petr^2 Spacek >> >> -- >> 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 >> > > Ok, we managed to figure out what was happening here, but I still think > there is a bug somewhere in the FreeIPA DNS components that is > exacerbating the issue. > > We have split DNS in our company. We have a public copy of our DNS > records, which contain only A records. We also have an internal copy of > our DNS records, which contains a bunch of CNAME records. > > When we use nslookup to query the IPA server for stash.externaldomain.net > NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns > both the CNAME and the associated A address. > > When we query FreeIPA though a DNS client, FreeIPA returns that stash is a > CNAME and does not return the associated A address. It seems like at that > point, FreeIPA decides that instead of sticking in 'forward' mode and > forwarding the request for the CNAME record to the forwarding server, it > decides instead to switch into recursive mode and begin the lookup by > querying root servers for externaldomain.net at which point since it is > going out to the general internet, it gets back answers from our public > facing DNS servers (remember we use split DNS). > > The answer it gets is (quite rightly) that there is no such CNAME record > on the public DNS server. > > So I have a couple questions about how the forward first policy is > supposed to work... Here I would say that IPA does not do anything special - IPA just configures BIND and all the rest is standard BIND behavior. I.e. when in doubt, consult respective BIND docs. > 1. In forward first mode, if the forward server returns a CNAME, is > FreeIPA supposed to ask the same forwarding server for the A record > associated with the CNAME, or is it supposed to then flip into recursive > mode and go to the root servers to find the CNAME? I would expect #1, but > it seems like #2 is always happening no matter what. I would only expect > it to attempt recursion if the initial query actually failed, not just > returned something other than an A record. Your expectation #1 is correct, but there can be multiple reasons why it fails. Did you try to set forward policy = only as I advised you in the previous e-mail? Forward policy 'first' does not make sense when split-DNS is involved because you can end up with mixture of records from different views in one cache, which obviously results in a mess. > 2. We did some more network packet capture, and noticed that in forward > first mode, the FreeIPA server, always sent out both a forward request to > the forwarding server, and an additional simultaneous request to the root > name servers (recursive mode). It got back responses to both the > forwarded and recursive queries it had performed. The recursive query > failed due to split DNS and the forwarded query succeeded due to it going > to an internal server which had the correct records. Strangely enough... > the IPA server ignored the successful forwarded answer, and sent back the > 'failed' answer it had gotten through recursion back to the requesting > client. What is the behavior supposed to be in this situation and why is > the server always sending out the recursive request, even when it gets a > valid answer from the forwarded request? This is weird, but again - it can have multiple reasons. Do you see something in BIND logs? Does it e.g. complain about DNSSEC validation failures? Petr^2 Spacek From bpk678 at gmail.com Tue Oct 6 12:13:09 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 06 Oct 2015 08:13:09 -0400 Subject: [Freeipa-users] separating authoritative servers from recursive servers In-Reply-To: <5613B3B5.9040200@redhat.com> References: <5613267A.2020507@gmail.com> <5613B3B5.9040200@redhat.com> Message-ID: <5613BAD5.9020403@gmail.com> On 10/06/2015 07:42 AM, Petr Spacek wrote: > On 6.10.2015 03:40, Brendan Kearney wrote: >> i have two bind instances in somewhat of a multi-master server arrangement, >> where they share the same ldap backend via bind-dyndb-ldap. currently, they >> are authoritative and recursive servers, and i want to change things up a >> bit. i want to move the recursive function to a third device. for this, i >> believe i need to set a forwarder for the two current servers. i believe i >> would do this by adding the idnsForwarders object (with value) on the OU that >> is the idnsConfigObject. >> >> i am looking for a sanity check, to ensure that i am not overlooking something >> important. are there any steps i am missing? i want the current two >> instances to be authoritative for all my forward and reverse zones, and use >> the forwarder for all recursion. the forwarder instance is already running, >> and is setup to answer queries from only the two current instances. i think i >> just need to point the current instances to the forwarder instance, and turn >> off recursion on them. > Hmm, I think that there is some confusion about terms we use. > > Pure authoritative server would give out answers only for zones it is > authoritative for (i.e. zones defined in /etc/named.conf or LDAP) and refuse > to answer all other queries. Is that what are you looking for? > > In contrast, a recursive server would answer query for any zone. If you really > want to separate authoritative and recursive roles, then you should: > > (0. As always: Make sure that delegation for all your zones is correct.) > 1. Set up recursive-only server. Add 'allow-recursion { IP_range; };' to > named.conf. > 2. Reconfigure all clients to use the recursive-only server and not to ask > authoritative servers directly. > 3. Reconfigure authoritative servers by adding allow-recursion { none; }; to > named.conf. > > No changes in LDAP should be necessary. > > Does it answer your question? > i want to have separation of duties in my dns infrastructure. the intention is to have clients point to the current instances of dns for all records. behind the scenes, i want to have those current instances be authoritative for my internal zones, and for queries that they are not authoritative for, they reach out to the third server/instance for recursive queries. the third server/instance for recursive queries should not be contacted by clients. the end result is a hierarchy of roles for the dns instances. from the bind docs: The forwarding facility can be used to create a large site-wide cache on a few servers, reducing traffic over links to external name servers. It can also be used to allow queries by servers that do not have direct access to the Internet, but wish to look up exterior names anyway. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache. I plan to remove external access for the two current dns instances and force them to use the instance set as the forwarder for all external or recursive lookups. it seems that the idnsForwarders attribute is where i start working on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aebruno2 at buffalo.edu Tue Oct 6 12:22:35 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Tue, 6 Oct 2015 08:22:35 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <5612C610.8060706@redhat.com> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> Message-ID: <20151006122235.GA24698@dead.ccr.buffalo.edu> On Mon, Oct 05, 2015 at 02:48:48PM -0400, Rob Crittenden wrote: > Andrew E. Bruno wrote: > > On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote: > >> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: > >>> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: > >>>> What's the best way to re-initialize a replica? > >>>> > >>>> Suppose one of your replicas goes south.. is there a command to tell > >>>> that replicate to re-initialize from the first master (instead of > >>>> removing/re-adding the replica from the topology)? > >>> > >>> Found the command I was looking for: > >>> ipa-replica-manage re-initialize --from xxx > >>> > >>> However, one of our replicates is down and can't seem to re-initialize > >>> it. Starting ipa fails (via systemctl restart ipa): > >>> > >>> ipactl status > >>> Directory Service: RUNNING > >>> krb5kdc Service: STOPPED > >>> kadmin Service: STOPPED > >>> named Service: STOPPED > >>> ipa_memcached Service: STOPPED > >>> httpd Service: STOPPED > >>> pki-tomcatd Service: STOPPED > >>> ipa-otpd Service: STOPPED > >>> ipa: INFO: The ipactl command was successful > >>> > >>> > >>> Errors from the dirsrv show: > >>> > >>> : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > >>> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > >>> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) > >>> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > >>> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > >>> > >>> > >>> Attempting to re-initialize fails: > >>> > >>> ipa-replica-manage re-initialize --from master > >>> Connection timed out. > >>> > >>> > >>> I verified time is in sync and DNS forward/reverse resolution is working. > >>> > >>> Any pointers on what else to try? > >>> > >>> Thanks! > >>> > >>> --Andrew > >> > >> Given that your Kerberos server instance is down, I would start investigating > >> Kerberos logs to see why. > > > > > > So looks like the dirsrv service comes up but with GSS errors about kerb > > credentials. However, the rest of the services including the krb5kdc > > fail to come up. Errors from the kdc logs suggest DNS: > > DS complaining about GSS is somewhat normal during startup as it is a > bit noisy. The other errors suggest there is no data in the backend. An > ldapsearch would confirm that. > > > > > LOOKING_UP_CLIENT: DNS/replica at REALM Server error > > > > FreeIPA is configured to serve DNS and this replica resolves it's own > > DNS in /etc/resolv.conf (127.0.0.1) > > > > I tried pointing /etc/resolv.conf to another (good) replica and even > > tried adjusting /etc/krb5.conf to point at another kdc to try and get a > > ticket however it still tries to connect to the local kdc (which fails > > to start). > > > > I'm inclined to re-install this replica and start fresh. I'm curious if > > we can re-kickstart this host from a fresh os/freeipa install and run > > the ipa-replica-manage re-initialize --from master command. The replica > > will have the same name.. is this possible? Would we need to backup the > > /var/lib/ipa/replica-info-XXX.gpg file? > > It needs to have its own principal in order to re-initialize. It sounds > like it has nothing which is why replication is failing. > > I'd recommend generating a new replica file. There is no value in > re-using the old one and it could be harmful if the certificates are > expired. > > You'll need to delete all replication agreements this master had and > you'll need to use the --force option since it won't be accessible. When > you re-install the master it will get all the current data as part of > the setup so no need to re-initialize after that. I force removed the replica and still seeing the RUV's show up. # ipa-replica-manage -v --force del srv-m14-30.cbls.ccr.buffalo.edu >From the logs: [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Initiating CleanAllRUV Task... [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Retrieving maxcsn... [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Found maxcsn (5600051d001000050000) [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (5)... [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Sending cleanAllRUV task to all the replicas... [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning local ruv's... [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be cleaned... [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica is not cleaned yet (agmt="cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu" (srv-m14-31-02:389)) [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replicas have not been cleaned yet, retrying in 10 seconds [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Successfully cleaned rid(5). The replica is not showing up when running ipa-replica-manage list. # ipa-replica-manage list srv-m14-32.cbls.ccr.buffalo.edu: master srv-m14-31-02.cbls.ccr.buffalo.edu: master However, still seeing the ruvs in ldapsearch: ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 00050000 55b2aa68000200050000 .. nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 0005b0000 55b13e740000005b0000 Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 Thanks again for the all the help. --Andrew From d.korittki at mittwald.de Tue Oct 6 12:55:26 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Tue, 6 Oct 2015 14:55:26 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <56125C19.5010307@redhat.com> References: <560D4BFA.2040303@mittwald.de> <56125C19.5010307@redhat.com> Message-ID: <5613C4BE.8050900@mittwald.de> Thanks for the info, Tomas. I will definitely try this one out! Couldn?t wait for it to be released for CentOS if it really does what the changes you mentioned describe :-) We would like to have hostgroup of 10.000 hostmembers or even more in one group. We currently split these group into multiple smaller groups with max 1000 members, because adding, modifying or removing a members of a large group (~7k hostmembers) takes around 7 seconds (removing one host from the group alone). Kind regards, Dominik Korittki Am 05.10.2015 um 13:16 schrieb Tomas Babej: > On 10/01/2015 05:06 PM, Dominik Korittki wrote: >> Hello folks, >> >> I am running two FreeIPA Servers with around 100 users and around 15.000 >> hosts, which are used by users to login via ssh. The FreeIPA servers >> (which are Centos 7.0) ran good for a while, but as more and more hosts >> got migrated to serve as FreeIPA hosts, it started to get slow and >> unstable. >> >> For example, its hard to maintain hostgroups, which have more than 1.000 >> hosts. The ipa host-* commands are getting slower as the hostgroup >> grows. Is this normal? >> We also experience random dirsrv segfaults. Here's a dmesg line from the >> latest: >> >> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 >> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >> >> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >> problem. >> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that >> solve my problems? >> >> FreeIPA server version is 3.3.3-28.el7.centos >> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >> >> >> >> Kind regards, >> Dominik Korittki >> > > > Hi Dominik, > > performance issues are a known problem, there has been some work to > improve the performance with respect to large groups: > > 11bd9d96f191066f7ba760549f00179c128a9787 > efcd48ad01a39a67f131a2cea9d54771642222fb > > These improvements are in FreeIPA 4.2 only, however, which has not been > released for CentOS7 as of now. You may try to play with FreeIPA 4.2 on > Fedora, see https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/. > > HTH, > Tomas > > > From sbose at redhat.com Tue Oct 6 13:01:44 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 6 Oct 2015 15:01:44 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: <20151002155951.GB3127@hendrix.redhat.com> <20151005120744.GB19585@p.redhat.com> Message-ID: <20151006130144.GC30474@p.redhat.com> On Tue, Oct 06, 2015 at 11:26:42AM +0200, Alexander Skwar wrote: > Hi > > With further debugging, I discovered, that I messed up the > /etc/sssd/sssd.conf file. There, I added: > > ? > [domain/customer.company.internal] > > krb5_realm = customer.company.internal > ? > > > > Exactly like that. With "krb5_realm = customer.company.internal"; ie. with > the realm in lowercase letters. > > After having changed that to uppercase letters (ie. "krb5_realm = > CUSTOMER.COMPANY.INTERNAL"), it works fine. Thank you for the feedback. Can you check /var/log/ipaclient-install.log to see which realm ipa-client-install has discovered? In general ipa-client-install should be able to determine the right realm. In your case where domain and realm are the same except the case it shouldn't have set krb5_realm at all. bye, Sumit > > > > Thanks for your time and help ;) > > Cheers, > Alexander > > > > 2015-10-05 14:07 GMT+02:00 Sumit Bose : > > > On Mon, Oct 05, 2015 at 09:00:13AM +0200, Alexander Skwar wrote: > > > Hi > > > > > > Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when I try > > > to login with SSH and enter a password. > > > > Can you try to increase the debug_level to 0xFFF0? > > > > > > > > kinit doesn't work. > > > > > > $ kinit -k > > > kinit: Permission denied while getting initial credentials > > > > > > For this test, I was root and then did a "su - user" and then "kinit -k". > > > Also after the "kinit -k", nothing is in the krb5_child.log. > > > > The 'kinit -k' has to be done as root. It will only check if the client > > can connect to the KDC at all and tries to get a TGT for the host. > > > > It's expected that during this operation nothing is added to the SSSD > > logs because the kinit utility work independent of SSSD. > > > > bye, > > Sumit > > > > > > > > Regards, > > > Alexander > > > > > > > > > 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > > > > > > > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > > > > > Hello > > > > > > > > > > How do I get password authentication to work with freeipa-client > > > > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > > > > > > > > > Long version follows :) > > > > > > > > > > We've got an IPA server with the Red Hat Identity Management server > > > > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I configured > > > > > users and groups there and would now like to login with SSH. When I > > > > > store a SSH key for the user account, I can login just fine, using > > > > > this SSH key. But I'd like/need to use passwords as well. And sudo > > > > > also doesn't work, when it's asking for passwords - I supposed, > > > > > it's the same root cause. > > > > > > > > > > Let's stick with SSH. > > > > > > > > > > Initially, I installed the FreeIPA client with this command line: > > > > > > > > > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > > > > > --enable-dns-updates --unattended \ > > > > > --principal=admin --password=correctone \ > > > > > --domain=customer.company.internal \ > > > > > --server=auth01.customer.company.internal > > > > > > > > > > I then try to do a SSH login with: > > > > > > > > > > ssh -l ewt at customer.company.internal 192.168.229.143 > > > > > or: > > > > > ssh -l ewt 192.168.229.143 > > > > > > > > > > Password authentication doesn't work. > > > > > > > > > > In the /var/log/syslog on the system where I try to login, I find > > this: > > > > > > > > > > 2015-10-02T15:33:38.771291+02:00 mgmt02 > > [sssd[krb5_child[14154]]]: > > > > > Key table entry not found > > > > > > > > > > After having turned up the debug level of the sssd with "sssd -i -f > > -d > > > > > 0x0770 --debug-timestamps=1", I find the following in the system log > > > > > files: > > > > > > > > > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > > > > > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > > > > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > > > > > pam_sss(sshd:auth): received for user ewt: 4 (System error) > > > > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > > > > > password for ewt from 212.71.117.1 port 58136 ssh2 > > > > > > > > > > TBH, I don't quite understand it. Anyway, in > > > > > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > > > > > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > > [read_pipe_handler] (0x0400): EOF received, client finished > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > > [parse_krb5_child_response] (0x0020): message too short. > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > > [krb5_auth_done] (0x0040): Could not parse child response [22]: > > > > > Invalid argument > > > > > (Fri Oct 2 15:46:26 2015) [sssd[be[customer.company.internal]]] > > > > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > > > > > > > > > Well? What am I doing wrong or what might I have forgotten? > > > > > > > > We need to also see the krb5_child.log but please check if the keytab > > is > > > > correct (ie kinit -k works). > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > > -- > > > > > > > > > Alexander > > > -- > > > => *Google+* => http://plus.skwar.me <== > > > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > > > > > -- > > > 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 > > > > > > > -- > > > Alexander > -- > => *Google+* => http://plus.skwar.me <== > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > -- > 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 From rmb1993 at gmail.com Mon Oct 5 13:24:27 2015 From: rmb1993 at gmail.com (Ryan Belgrave) Date: Mon, 5 Oct 2015 13:24:27 +0000 (UTC) Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> <54F9EC96.5080702@redhat.com> <54F9F51D.8050205@linuxcoding.org> Message-ID: Herwono W Wijaya writes: > > > Tomorrow I will try to capture Univention LDAP traffic with > wireshark, and if possible I will try also this FreeIPA with vCenter > 6. Since I became one of the private beta testers so I had vCenter Any updates on this? I am getting the same issue in vCenter 6 with IPA 4.1.0 on Centos 7. The realm access logs seem fine no errors showing and doing the search vCenter is doing manually works perfectly. However vCenter is still logging errors with control not found. From rcritten at redhat.com Tue Oct 6 13:35:08 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Oct 2015 09:35:08 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151006122235.GA24698@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> Message-ID: <5613CE0C.9090408@redhat.com> Andrew E. Bruno wrote: > On Mon, Oct 05, 2015 at 02:48:48PM -0400, Rob Crittenden wrote: >> Andrew E. Bruno wrote: >>> On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote: >>>> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: >>>>> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: >>>>>> What's the best way to re-initialize a replica? >>>>>> >>>>>> Suppose one of your replicas goes south.. is there a command to tell >>>>>> that replicate to re-initialize from the first master (instead of >>>>>> removing/re-adding the replica from the topology)? >>>>> >>>>> Found the command I was looking for: >>>>> ipa-replica-manage re-initialize --from xxx >>>>> >>>>> However, one of our replicates is down and can't seem to re-initialize >>>>> it. Starting ipa fails (via systemctl restart ipa): >>>>> >>>>> ipactl status >>>>> Directory Service: RUNNING >>>>> krb5kdc Service: STOPPED >>>>> kadmin Service: STOPPED >>>>> named Service: STOPPED >>>>> ipa_memcached Service: STOPPED >>>>> httpd Service: STOPPED >>>>> pki-tomcatd Service: STOPPED >>>>> ipa-otpd Service: STOPPED >>>>> ipa: INFO: The ipactl command was successful >>>>> >>>>> >>>>> Errors from the dirsrv show: >>>>> >>>>> : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) >>>>> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) >>>>> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) >>>>> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) >>>>> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) >>>>> >>>>> >>>>> Attempting to re-initialize fails: >>>>> >>>>> ipa-replica-manage re-initialize --from master >>>>> Connection timed out. >>>>> >>>>> >>>>> I verified time is in sync and DNS forward/reverse resolution is working. >>>>> >>>>> Any pointers on what else to try? >>>>> >>>>> Thanks! >>>>> >>>>> --Andrew >>>> >>>> Given that your Kerberos server instance is down, I would start investigating >>>> Kerberos logs to see why. >>> >>> >>> So looks like the dirsrv service comes up but with GSS errors about kerb >>> credentials. However, the rest of the services including the krb5kdc >>> fail to come up. Errors from the kdc logs suggest DNS: >> >> DS complaining about GSS is somewhat normal during startup as it is a >> bit noisy. The other errors suggest there is no data in the backend. An >> ldapsearch would confirm that. >> >>> >>> LOOKING_UP_CLIENT: DNS/replica at REALM Server error >>> >>> FreeIPA is configured to serve DNS and this replica resolves it's own >>> DNS in /etc/resolv.conf (127.0.0.1) >>> >>> I tried pointing /etc/resolv.conf to another (good) replica and even >>> tried adjusting /etc/krb5.conf to point at another kdc to try and get a >>> ticket however it still tries to connect to the local kdc (which fails >>> to start). >>> >>> I'm inclined to re-install this replica and start fresh. I'm curious if >>> we can re-kickstart this host from a fresh os/freeipa install and run >>> the ipa-replica-manage re-initialize --from master command. The replica >>> will have the same name.. is this possible? Would we need to backup the >>> /var/lib/ipa/replica-info-XXX.gpg file? >> >> It needs to have its own principal in order to re-initialize. It sounds >> like it has nothing which is why replication is failing. >> >> I'd recommend generating a new replica file. There is no value in >> re-using the old one and it could be harmful if the certificates are >> expired. >> >> You'll need to delete all replication agreements this master had and >> you'll need to use the --force option since it won't be accessible. When >> you re-install the master it will get all the current data as part of >> the setup so no need to re-initialize after that. > > I force removed the replica and still seeing the RUV's show up. > > # ipa-replica-manage -v --force del srv-m14-30.cbls.ccr.buffalo.edu > > > From the logs: > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Initiating CleanAllRUV Task... > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Retrieving maxcsn... > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Found maxcsn (5600051d001000050000) > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (5)... > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Sending cleanAllRUV task to all the replicas... > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning local ruv's... > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be cleaned... > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica is not cleaned yet (agmt="cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu" (srv-m14-31-02:389)) > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replicas have not been cleaned yet, retrying in 10 seconds > [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... > [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Successfully cleaned rid(5). > > The replica is not showing up when running ipa-replica-manage list. > > # ipa-replica-manage list > srv-m14-32.cbls.ccr.buffalo.edu: master > srv-m14-31-02.cbls.ccr.buffalo.edu: master > > > However, still seeing the ruvs in ldapsearch: > > ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > > > nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > 00050000 55b2aa68000200050000 > > > .. > > nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > 0005b0000 55b13e740000005b0000 > > > Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 > > Thanks again for the all the help. > > --Andrew > > Note that the list of masters comes from entries in IPA, not from replication agreements. ipa-replica-manage list-ruv will show the RUV data in a simpler way. Yeah, I'd use clean-ruv to clean them up. rob From aebruno2 at buffalo.edu Tue Oct 6 13:52:52 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Tue, 6 Oct 2015 09:52:52 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <5613CE0C.9090408@redhat.com> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> Message-ID: <20151006135252.GB24698@dead.ccr.buffalo.edu> On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: > Andrew E. Bruno wrote: > > On Mon, Oct 05, 2015 at 02:48:48PM -0400, Rob Crittenden wrote: > >> Andrew E. Bruno wrote: > >>> On Mon, Oct 05, 2015 at 12:40:42PM +0200, Martin Kosek wrote: > >>>> On 10/02/2015 06:00 PM, Andrew E. Bruno wrote: > >>>>> On Fri, Oct 02, 2015 at 09:56:47AM -0400, Andrew E. Bruno wrote: > >>>>>> What's the best way to re-initialize a replica? > >>>>>> > >>>>>> Suppose one of your replicas goes south.. is there a command to tell > >>>>>> that replicate to re-initialize from the first master (instead of > >>>>>> removing/re-adding the replica from the topology)? > >>>>> > >>>>> Found the command I was looking for: > >>>>> ipa-replica-manage re-initialize --from xxx > >>>>> > >>>>> However, one of our replicates is down and can't seem to re-initialize > >>>>> it. Starting ipa fails (via systemctl restart ipa): > >>>>> > >>>>> ipactl status > >>>>> Directory Service: RUNNING > >>>>> krb5kdc Service: STOPPED > >>>>> kadmin Service: STOPPED > >>>>> named Service: STOPPED > >>>>> ipa_memcached Service: STOPPED > >>>>> httpd Service: STOPPED > >>>>> pki-tomcatd Service: STOPPED > >>>>> ipa-otpd Service: STOPPED > >>>>> ipa: INFO: The ipactl command was successful > >>>>> > >>>>> > >>>>> Errors from the dirsrv show: > >>>>> > >>>>> : GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > >>>>> [02/Oct/2015:11:45:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > >>>>> [02/Oct/2015:11:50:05 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/server at realm] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) > >>>>> [02/Oct/2015:11:50:05 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) > >>>>> [02/Oct/2015:11:50:05 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) > >>>>> > >>>>> > >>>>> Attempting to re-initialize fails: > >>>>> > >>>>> ipa-replica-manage re-initialize --from master > >>>>> Connection timed out. > >>>>> > >>>>> > >>>>> I verified time is in sync and DNS forward/reverse resolution is working. > >>>>> > >>>>> Any pointers on what else to try? > >>>>> > >>>>> Thanks! > >>>>> > >>>>> --Andrew > >>>> > >>>> Given that your Kerberos server instance is down, I would start investigating > >>>> Kerberos logs to see why. > >>> > >>> > >>> So looks like the dirsrv service comes up but with GSS errors about kerb > >>> credentials. However, the rest of the services including the krb5kdc > >>> fail to come up. Errors from the kdc logs suggest DNS: > >> > >> DS complaining about GSS is somewhat normal during startup as it is a > >> bit noisy. The other errors suggest there is no data in the backend. An > >> ldapsearch would confirm that. > >> > >>> > >>> LOOKING_UP_CLIENT: DNS/replica at REALM Server error > >>> > >>> FreeIPA is configured to serve DNS and this replica resolves it's own > >>> DNS in /etc/resolv.conf (127.0.0.1) > >>> > >>> I tried pointing /etc/resolv.conf to another (good) replica and even > >>> tried adjusting /etc/krb5.conf to point at another kdc to try and get a > >>> ticket however it still tries to connect to the local kdc (which fails > >>> to start). > >>> > >>> I'm inclined to re-install this replica and start fresh. I'm curious if > >>> we can re-kickstart this host from a fresh os/freeipa install and run > >>> the ipa-replica-manage re-initialize --from master command. The replica > >>> will have the same name.. is this possible? Would we need to backup the > >>> /var/lib/ipa/replica-info-XXX.gpg file? > >> > >> It needs to have its own principal in order to re-initialize. It sounds > >> like it has nothing which is why replication is failing. > >> > >> I'd recommend generating a new replica file. There is no value in > >> re-using the old one and it could be harmful if the certificates are > >> expired. > >> > >> You'll need to delete all replication agreements this master had and > >> you'll need to use the --force option since it won't be accessible. When > >> you re-install the master it will get all the current data as part of > >> the setup so no need to re-initialize after that. > > > > I force removed the replica and still seeing the RUV's show up. > > > > # ipa-replica-manage -v --force del srv-m14-30.cbls.ccr.buffalo.edu > > > > > > From the logs: > > > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Initiating CleanAllRUV Task... > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Retrieving maxcsn... > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Found maxcsn (5600051d001000050000) > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning rid (5)... > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting to process all the updates from the deleted replica... > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be online... > > [06/Oct/2015:07:43:47 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... > > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Sending cleanAllRUV task to all the replicas... > > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning local ruv's... > > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be cleaned... > > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replica is not cleaned yet (agmt="cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu" (srv-m14-31-02:389)) > > [06/Oct/2015:07:43:48 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Replicas have not been cleaned yet, retrying in 10 seconds > > [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... > > [06/Oct/2015:07:43:59 -0400] NSMMReplicationPlugin - CleanAllRUV Task: Successfully cleaned rid(5). > > > > The replica is not showing up when running ipa-replica-manage list. > > > > # ipa-replica-manage list > > srv-m14-32.cbls.ccr.buffalo.edu: master > > srv-m14-31-02.cbls.ccr.buffalo.edu: master > > > > > > However, still seeing the ruvs in ldapsearch: > > > > ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > > > > > > nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > > 00050000 55b2aa68000200050000 > > > > > > .. > > > > nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > > 0005b0000 55b13e740000005b0000 > > > > > > Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 > > > > Thanks again for the all the help. > > > > --Andrew > > > > > > Note that the list of masters comes from entries in IPA, not from > replication agreements. > > ipa-replica-manage list-ruv will show the RUV data in a simpler way. > > Yeah, I'd use clean-ruv to clean them up. > > rob > > I get an error trying to clean-ruv: # ipa-replica-manage clean-ruv 5 Replica ID 5 not found Can these safely be ignored? or will we hit problems when adding the replica back in? Thanks again. From rcritten at redhat.com Tue Oct 6 14:22:44 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Oct 2015 10:22:44 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151006135252.GB24698@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> Message-ID: <5613D934.3080701@redhat.com> Andrew E. Bruno wrote: > On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: >> Andrew E. Bruno wrote: >>> The replica is not showing up when running ipa-replica-manage list. >>> >>> # ipa-replica-manage list >>> srv-m14-32.cbls.ccr.buffalo.edu: master >>> srv-m14-31-02.cbls.ccr.buffalo.edu: master >>> >>> >>> However, still seeing the ruvs in ldapsearch: >>> >>> ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL >>> >>> >>> nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 >>> 00050000 55b2aa68000200050000 >>> >>> >>> .. >>> >>> nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 >>> 0005b0000 55b13e740000005b0000 >>> >>> >>> Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 >>> >>> Thanks again for the all the help. >>> >>> --Andrew >>> >>> >> >> Note that the list of masters comes from entries in IPA, not from >> replication agreements. >> >> ipa-replica-manage list-ruv will show the RUV data in a simpler way. >> >> Yeah, I'd use clean-ruv to clean them up. >> >> rob >> >> > > I get an error trying to clean-ruv: > > # ipa-replica-manage clean-ruv 5 > Replica ID 5 not found > > Can these safely be ignored? or will we hit problems when adding the > replica back in? ipa-replica-manage list-ruv will show you the current RUV list. If it isn't there then yeah, you're done. Having unused RUV in a master causes it to do unnecessary replication calculations. rob From pspacek at redhat.com Tue Oct 6 14:25:00 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 6 Oct 2015 16:25:00 +0200 Subject: [Freeipa-users] separating authoritative servers from recursive servers In-Reply-To: <5613BAD5.9020403@gmail.com> References: <5613267A.2020507@gmail.com> <5613B3B5.9040200@redhat.com> <5613BAD5.9020403@gmail.com> Message-ID: <5613D9BC.1030203@redhat.com> On 6.10.2015 14:13, Brendan Kearney wrote: > On 10/06/2015 07:42 AM, Petr Spacek wrote: >> On 6.10.2015 03:40, Brendan Kearney wrote: >>> i have two bind instances in somewhat of a multi-master server arrangement, >>> where they share the same ldap backend via bind-dyndb-ldap. currently, they >>> are authoritative and recursive servers, and i want to change things up a >>> bit. i want to move the recursive function to a third device. for this, i >>> believe i need to set a forwarder for the two current servers. i believe i >>> would do this by adding the idnsForwarders object (with value) on the OU that >>> is the idnsConfigObject. >>> >>> i am looking for a sanity check, to ensure that i am not overlooking something >>> important. are there any steps i am missing? i want the current two >>> instances to be authoritative for all my forward and reverse zones, and use >>> the forwarder for all recursion. the forwarder instance is already running, >>> and is setup to answer queries from only the two current instances. i think i >>> just need to point the current instances to the forwarder instance, and turn >>> off recursion on them. >> Hmm, I think that there is some confusion about terms we use. >> >> Pure authoritative server would give out answers only for zones it is >> authoritative for (i.e. zones defined in /etc/named.conf or LDAP) and refuse >> to answer all other queries. Is that what are you looking for? >> >> In contrast, a recursive server would answer query for any zone. If you really >> want to separate authoritative and recursive roles, then you should: >> >> (0. As always: Make sure that delegation for all your zones is correct.) >> 1. Set up recursive-only server. Add 'allow-recursion { IP_range; };' to >> named.conf. >> 2. Reconfigure all clients to use the recursive-only server and not to ask >> authoritative servers directly. >> 3. Reconfigure authoritative servers by adding allow-recursion { none; }; to >> named.conf. >> >> No changes in LDAP should be necessary. >> >> Does it answer your question? >> > i want to have separation of duties in my dns infrastructure. the intention > is to have clients point to the current instances of dns for all records. > behind the scenes, i want to have those current instances be authoritative for > my internal zones, and for queries that they are not authoritative for, they > reach out to the third server/instance for recursive queries. the third > server/instance for recursive queries should not be contacted by clients. the > end result is a hierarchy of roles for the dns instances. > > from the bind docs: > The forwarding facility can be used to create a large site-wide cache on a few > servers, reducing traffic over links to external name servers. It can also be > used to allow queries by servers that do not have direct access to the > Internet, but wish to look up exterior names anyway. Forwarding occurs only on > those queries for which the server is not authoritative and does not have the > answer in its cache. > > I plan to remove external access for the two current dns instances and force > them to use the instance set as the forwarder for all external or recursive > lookups. it seems that the idnsForwarders attribute is where i start working > on this. Okay, now I can see what you are trying to achieve. Please note that your 'authoritative' servers will be at the same time used as recursive - the fact that they forward the query to another server does not change anything important because there will be only one shared cache in the 'authoritative' DNS servers. In other words, you are not getting anything separation-wise. Bug in recursive part will crash your authoritative server. Cache poisoning will be a thread to your authoritative servers, too. If you insist on this setup, you can either configure forwarders {} and forward-policy {} options in named.conf on each server or globally configure it using idnsForwarder and idnsForwardPolicy attributes in idnsConfig object. I hope this helps. -- Petr^2 Spacek From aebruno2 at buffalo.edu Tue Oct 6 14:30:41 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Tue, 6 Oct 2015 10:30:41 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <5613D934.3080701@redhat.com> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> <5613D934.3080701@redhat.com> Message-ID: <20151006143041.GC24698@dead.ccr.buffalo.edu> On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote: > Andrew E. Bruno wrote: > > On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: > >> Andrew E. Bruno wrote: > >>> The replica is not showing up when running ipa-replica-manage list. > >>> > >>> # ipa-replica-manage list > >>> srv-m14-32.cbls.ccr.buffalo.edu: master > >>> srv-m14-31-02.cbls.ccr.buffalo.edu: master > >>> > >>> > >>> However, still seeing the ruvs in ldapsearch: > >>> > >>> ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > >>> > >>> > >>> nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > >>> 00050000 55b2aa68000200050000 > >>> > >>> > >>> .. > >>> > >>> nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > >>> 0005b0000 55b13e740000005b0000 > >>> > >>> > >>> Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 > >>> > >>> Thanks again for the all the help. > >>> > >>> --Andrew > >>> > >>> > >> > >> Note that the list of masters comes from entries in IPA, not from > >> replication agreements. > >> > >> ipa-replica-manage list-ruv will show the RUV data in a simpler way. > >> > >> Yeah, I'd use clean-ruv to clean them up. > >> > >> rob > >> > >> > > > > I get an error trying to clean-ruv: > > > > # ipa-replica-manage clean-ruv 5 > > Replica ID 5 not found > > > > Can these safely be ignored? or will we hit problems when adding the > > replica back in? > > ipa-replica-manage list-ruv will show you the current RUV list. If it > isn't there then yeah, you're done. > > Having unused RUV in a master causes it to do unnecessary replication > calculations. > > rob Yes, list-ruv seems to show the correct RUV list. # ipa-replica-manage list-ruv srv-m14-32.cbls.ccr.buffalo.edu:389: 4 srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3 It's just the ldapsearch that's showing repid 5 : ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL dn: cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu,cn=replica,cn=dc\3Dcbls\2Cdc\3Dc cr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config cn: meTosrv-m14-31-02.cbls.ccr.buffalo.edu objectClass: nsds5replicationagreement objectClass: top .. nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 00050000 55b2aa68000200050000 dn: cn=masterAgreement1-srv-m14-31-02.cbls.ccr.buffalo.edu-pki-tomcat,cn=repli ca,cn=o\3Dipaca,cn=mapping tree,cn=config objectClass: top objectClass: nsds5replicationagreement ... nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 0005b0000 55b13e740000005b0000 Last time we had a replicate fail we manually ran a cleanall ruv via ldapmodify for the ipaca rid which wasn't properly deleted. However, this time we're seeing the rid in both ipca dn and the replica dn? Just want to be sure.. are you saying these can be safely ignored? and we can trust that the list-ruv is correct (and not causing unnecessary replication calculations). We plan on adding the failed replica back with the same name. --Andrew From alexanders.mailinglists+nospam at gmail.com Tue Oct 6 13:39:43 2015 From: alexanders.mailinglists+nospam at gmail.com (Alexander Skwar) Date: Tue, 6 Oct 2015 15:39:43 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: <20151006130144.GC30474@p.redhat.com> References: <20151002155951.GB3127@hendrix.redhat.com> <20151005120744.GB19585@p.redhat.com> <20151006130144.GC30474@p.redhat.com> Message-ID: Hello Sumit ipa-client-install hasn't set krb5_realm. I did that. We're using Chef-Solo to manage our systems and I have /etc/sssd/sssd.conf in chef. So it overwrote, whatever ipa-client-install put there. And that's how the mistake happened. I think the ipa-client-install discovered everything right. I'm attaching the log. Best regards, Alexander 2015-10-06 15:01 GMT+02:00 Sumit Bose : > On Tue, Oct 06, 2015 at 11:26:42AM +0200, Alexander Skwar wrote: > > Hi > > > > With further debugging, I discovered, that I messed up the > > /etc/sssd/sssd.conf file. There, I added: > > > > ? > > [domain/customer.company.internal] > > > > krb5_realm = customer.company.internal > > ? > > > > > > > > Exactly like that. With "krb5_realm = customer.company.internal"; ie. > with > > the realm in lowercase letters. > > > > After having changed that to uppercase letters (ie. "krb5_realm = > > CUSTOMER.COMPANY.INTERNAL"), it works fine. > > Thank you for the feedback. Can you check /var/log/ipaclient-install.log > to see which realm ipa-client-install has discovered? In general > ipa-client-install should be able to determine the right realm. In your > case where domain and realm are the same except the case it shouldn't > have set krb5_realm at all. > > bye, > Sumit > > > > > > > > > Thanks for your time and help ;) > > > > Cheers, > > Alexander > > > > > > > > 2015-10-05 14:07 GMT+02:00 Sumit Bose : > > > > > On Mon, Oct 05, 2015 at 09:00:13AM +0200, Alexander Skwar wrote: > > > > Hi > > > > > > > > Hm, there's nothing at all in the /var/log/sssd/krb5_child.log when > I try > > > > to login with SSH and enter a password. > > > > > > Can you try to increase the debug_level to 0xFFF0? > > > > > > > > > > > kinit doesn't work. > > > > > > > > $ kinit -k > > > > kinit: Permission denied while getting initial credentials > > > > > > > > For this test, I was root and then did a "su - user" and then "kinit > -k". > > > > Also after the "kinit -k", nothing is in the krb5_child.log. > > > > > > The 'kinit -k' has to be done as root. It will only check if the client > > > can connect to the KDC at all and tries to get a TGT for the host. > > > > > > It's expected that during this operation nothing is added to the SSSD > > > logs because the kinit utility work independent of SSSD. > > > > > > bye, > > > Sumit > > > > > > > > > > > Regards, > > > > Alexander > > > > > > > > > > > > 2015-10-02 17:59 GMT+02:00 Jakub Hrozek : > > > > > > > > > On Fri, Oct 02, 2015 at 04:28:57PM +0200, Alexander Skwar wrote: > > > > > > Hello > > > > > > > > > > > > How do I get password authentication to work with freeipa-client > > > > > > 3.3.4-0ubuntu3.1 on Ubuntu 14.04 for ssh and sudo? > > > > > > > > > > > > Long version follows :) > > > > > > > > > > > > We've got an IPA server with the Red Hat Identity Management > server > > > > > > on RHEL 7.1 servers; FreeIPA v4.1.0 is being used there. I > configured > > > > > > users and groups there and would now like to login with SSH. > When I > > > > > > store a SSH key for the user account, I can login just fine, > using > > > > > > this SSH key. But I'd like/need to use passwords as well. And > sudo > > > > > > also doesn't work, when it's asking for passwords - I supposed, > > > > > > it's the same root cause. > > > > > > > > > > > > Let's stick with SSH. > > > > > > > > > > > > Initially, I installed the FreeIPA client with this command line: > > > > > > > > > > > > ipa-client-install --force-join --mkhomedir --ssh-trust-dns \ > > > > > > --enable-dns-updates --unattended \ > > > > > > --principal=admin --password=correctone \ > > > > > > --domain=customer.company.internal \ > > > > > > --server=auth01.customer.company.internal > > > > > > > > > > > > I then try to do a SSH login with: > > > > > > > > > > > > ssh -l ewt at customer.company.internal 192.168.229.143 > > > > > > or: > > > > > > ssh -l ewt 192.168.229.143 > > > > > > > > > > > > Password authentication doesn't work. > > > > > > > > > > > > In the /var/log/syslog on the system where I try to login, I find > > > this: > > > > > > > > > > > > 2015-10-02T15:33:38.771291+02:00 mgmt02 > > > [sssd[krb5_child[14154]]]: > > > > > > Key table entry not found > > > > > > > > > > > > After having turned up the debug level of the sssd with "sssd -i > -f > > > -d > > > > > > 0x0770 --debug-timestamps=1", I find the following in the system > log > > > > > > files: > > > > > > > > > > > > 2015-10-02T15:40:48.756399+02:00 mgmt02 sshd[14194]: > > > > > > pam_unix(sshd:auth): authentication failure; logname= uid=0 > euid=0 > > > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > > > 2015-10-02T15:40:48.775896+02:00 mgmt02 sshd[14194]: > > > > > > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > > > > > > tty=ssh ruser= rhost=212.71.117.1 user=ewt > > > > > > 2015-10-02T15:40:48.775927+02:00 mgmt02 sshd[14194]: > > > > > > pam_sss(sshd:auth): received for user ewt: 4 (System error) > > > > > > 2015-10-02T15:40:50.988591+02:00 mgmt02 sshd[14194]: Failed > > > > > > password for ewt from 212.71.117.1 port 58136 ssh2 > > > > > > > > > > > > TBH, I don't quite understand it. Anyway, in > > > > > > /var/log/sssd/sssd_customer.company.internal.log I noticed: > > > > > > > > > > > > (Fri Oct 2 15:46:26 2015) > [sssd[be[customer.company.internal]]] > > > > > > [read_pipe_handler] (0x0400): EOF received, client finished > > > > > > (Fri Oct 2 15:46:26 2015) > [sssd[be[customer.company.internal]]] > > > > > > [parse_krb5_child_response] (0x0020): message too short. > > > > > > (Fri Oct 2 15:46:26 2015) > [sssd[be[customer.company.internal]]] > > > > > > [krb5_auth_done] (0x0040): Could not parse child response [22]: > > > > > > Invalid argument > > > > > > (Fri Oct 2 15:46:26 2015) > [sssd[be[customer.company.internal]]] > > > > > > [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. > > > > > > > > > > > > Well? What am I doing wrong or what might I have forgotten? > > > > > > > > > > We need to also see the krb5_child.log but please check if the > keytab > > > is > > > > > correct (ie kinit -k works). > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Alexander > > > > -- > > > > => *Google+* => http://plus.skwar.me <== > > > > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > > > > > > > -- > > > > 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 > > > > > > > > > > > > -- > > > > > > Alexander > > -- > > => *Google+* => http://plus.skwar.me <== > > => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== > > > -- > > 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 > > -- Alexander -- => *Google+* => http://plus.skwar.me <== => *Chat* (Jabber/Google Talk) => a.skwar at gmail.com <== -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaclient-install.log Type: text/x-log Size: 72343 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 6 15:41:38 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 6 Oct 2015 17:41:38 +0200 Subject: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers In-Reply-To: References: <55FAA0DB.80201@redhat.com> <55FAAAF2.9070904@redhat.com> <55FBCEDE.7090906@redhat.com> Message-ID: <5613EBB2.8090905@redhat.com> On 09/22/2015 01:03 AM, Craig White wrote: > -----Original Message----- > From: Petr Vobornik [mailto:pvoborni at redhat.com] > Sent: Friday, September 18, 2015 1:44 AM > To: Craig White; Martin Kosek; freeipa-users at redhat.com; Jan Cholasta > Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers > > On 09/17/2015 06:19 PM, Craig White wrote: >> -----Original Message----- >> From: Petr Vobornik [mailto:pvoborni at redhat.com] >> Sent: Thursday, September 17, 2015 4:59 AM >> To: Martin Kosek; Craig White; freeipa-users at redhat.com; Jan Cholasta >> Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA >> 3.0.0) servers >> >>>> What's the trick to get rid of an old, discontinued 'master' ? >>>> >>>> Craig White >>> >>> Quickly looking at ipa-replica-manage code, the del command will end >>> if there is no RUV. So it seems that in some of your previous RUV was >>> deleted, but server record was not. >>> >>> What does >>> # ipa-replica-manage list-ruv >>> show? >>> >>> Petr or Honza, is the only option here to >>> 1) Use ldapdelete to delete the master record in cn=masters as a >>> hotfix for this issue >> >> It will fix the replica manage output but replica cleanup does more things than just a removal of master entry. It also: >> deletes services of the host > > This part could be done in web ui - check for /ipa1.stt.local at STT.LOCAL > > where is usually DNS, HTTP and ldap > ---- > > The webui also shows a dogtag/ipa1.stt.local at STT.LOCAL but no other dogtag URL's (like the new master). Is it no longer needed or should it be changed to the new CA-master? > > ---- >> removes s4u2proxy configuration >> removes some ACIs >> >> More info: >> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/r >> eplication.py#n1185 >> >> >>> 2) File a ticket to avoid get_ruv function exit the whole "del" >>> command when --force is in play to fix this long-term >> >> https://fedorahosted.org/freeipa/ticket/5307 >> ---- >> OK - I think I see the LDAP entries and just wanting confirmation >> before I do great harm :-) >> >> Dn: cn=ipa1.stt.local,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local > > yes > > > If by ipa1_ETC you mean (assuming that your realm is STT.LOCAL): >> Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - >> attribute memberPrincipal ipa1_ETC > > HTTP/ipa1.stt.local at STT.LOCAL > >> Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local >> - attribute memberPrincipal ipa1_ETC > > ldap/ipa1.stt.local at STT.LOCAL > > > >> >> The one DN and the 2 attributes are what I should delete to get rid of this dead master? >> >> Rummaging around, I do see other hanging chads (pardon the election season humor)... >> >> DN: dnaHostname ipa1.stt.local + >> 0,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently >> 'dnaPortNum 0 and dnaSecurePortNum 636) >> DN: dnaHostname ipa1.stt.local + >> 389,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently >> 'dnaPortNum 389 and dnaSecurePortNum 636) >> >> And if were to delete the first one, there wouldn't be any entries pointing to port '0' but that just looks strange to me anyway. If I delete both the above, then all that is left is just the 2 new RHEL 7 IPA/iDM servers on ports 389/636 which seems right to me. > > Check if the DNA range configuration for the deleted master does contain dna RemainingValues other than 0. In that case you might want to check DNA configuration of other masters to be sure that other master can issue posix numbers. > > DNA ranges could be also configured using ipa-replica-manage. > ----- > > Yes, the other servers are there and seem to handle the right stuff > > ----- > >> >> If there are actual ACI's to edit, I am afraid I don't have a tool to do that very easily. > > Could be seen e.g., when browsing LDAP structure in Apache Directory studio as Directory Manager. It's 'aci' attribute of entry cn=masters,cn=ipa,cn=etc,$SUFFIX > > There should be two which contain the deleted replica hostname. One has name "Read IPA Masters" the other "Modify IPA Masters". > > ---- > Not sure I understand. > > There are entries for the 3 servers in question > Ipa1, ipa3, ipa4 but in cn=masters,cn=ipa,cn=etc,$SUFFIX there isn't anything (i.e. attributes) that are called IPA Masters or Modify IPA Masters under any of them. > > Thanks > It's an 'aci' attribute of the container - visible for Directory Manager. -- Petr Vobornik From karl.forner at gmail.com Tue Oct 6 16:28:14 2015 From: karl.forner at gmail.com (Karl Forner) Date: Tue, 6 Oct 2015 18:28:14 +0200 Subject: [Freeipa-users] sudo rules do not seem to work Message-ID: Hello, I had assumed sudo rules worked because I have an "allow_all for admins" sudo rule that seemed to work, but I wonder if there is an implicit rule for the special group admins ? Because I have tried to replicate this allow_all rule for for other user groups, and it does not seem to work at all. What's strange is that "sudo -l" report the appropriate rules, but they do not work. For instance, some users have: (ALL) ALL listed with sudo -l, but they can not use sudo. My user has: (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status (ALL) ALL (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod -R g[+-]* * (ALL) NOPASSWD: /usr/bin/less (ALL) ALL but I'm prompted a password when doing "sudo /usr/bin/less". How can I debug this ? Best regards, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Tue Oct 6 16:53:04 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 6 Oct 2015 12:53:04 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151006143041.GC24698@dead.ccr.buffalo.edu> References: <20151002135647.GA18409@dead.ccr.buffalo.edu> <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> <5613D934.3080701@redhat.com> <20151006143041.GC24698@dead.ccr.buffalo.edu> Message-ID: <5613FC70.4090100@redhat.com> On 10/06/2015 10:30 AM, Andrew E. Bruno wrote: > On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote: >> Andrew E. Bruno wrote: >>> On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: >>>> Andrew E. Bruno wrote: >>>>> The replica is not showing up when running ipa-replica-manage list. >>>>> >>>>> # ipa-replica-manage list >>>>> srv-m14-32.cbls.ccr.buffalo.edu: master >>>>> srv-m14-31-02.cbls.ccr.buffalo.edu: master >>>>> >>>>> >>>>> However, still seeing the ruvs in ldapsearch: >>>>> >>>>> ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL >>>>> >>>>> >>>>> nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 >>>>> 00050000 55b2aa68000200050000 >>>>> >>>>> >>>>> .. >>>>> >>>>> nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 >>>>> 0005b0000 55b13e740000005b0000 >>>>> >>>>> >>>>> Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 >>>>> >>>>> Thanks again for the all the help. >>>>> >>>>> --Andrew >>>>> >>>>> >>>> Note that the list of masters comes from entries in IPA, not from >>>> replication agreements. >>>> >>>> ipa-replica-manage list-ruv will show the RUV data in a simpler way. >>>> >>>> Yeah, I'd use clean-ruv to clean them up. >>>> >>>> rob >>>> >>>> >>> I get an error trying to clean-ruv: >>> >>> # ipa-replica-manage clean-ruv 5 >>> Replica ID 5 not found >>> >>> Can these safely be ignored? or will we hit problems when adding the >>> replica back in? >> ipa-replica-manage list-ruv will show you the current RUV list. If it >> isn't there then yeah, you're done. >> >> Having unused RUV in a master causes it to do unnecessary replication >> calculations. >> >> rob > Yes, list-ruv seems to show the correct RUV list. > > # ipa-replica-manage list-ruv > srv-m14-32.cbls.ccr.buffalo.edu:389: 4 > srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3 > > It's just the ldapsearch that's showing repid 5 : > > ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL I think this can be ignored sicne its on the repl agreement, and not the backend. What does this ldapsearch return: replace -b with your suffix ldapsearch -Y GSSAPI -b|"dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsds50ruv| Mark > > dn: cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu,cn=replica,cn=dc\3Dcbls\2Cdc\3Dc > cr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config > cn: meTosrv-m14-31-02.cbls.ccr.buffalo.edu > objectClass: nsds5replicationagreement > objectClass: top > .. > nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > 00050000 55b2aa68000200050000 > > > > dn: cn=masterAgreement1-srv-m14-31-02.cbls.ccr.buffalo.edu-pki-tomcat,cn=repli > ca,cn=o\3Dipaca,cn=mapping tree,cn=config > objectClass: top > objectClass: nsds5replicationagreement > ... > nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > 0005b0000 55b13e740000005b0000 > > > > Last time we had a replicate fail we manually ran a cleanall ruv via ldapmodify > for the ipaca rid which wasn't properly deleted. However, this time we're > seeing the rid in both ipca dn and the replica dn? > > Just want to be sure.. are you saying these can be safely ignored? and we can > trust that the list-ruv is correct (and not causing unnecessary replication > calculations). We plan on adding the failed replica back with the same name. > > --Andrew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Tue Oct 6 16:57:58 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Tue, 6 Oct 2015 09:57:58 -0700 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <5613B518.7060805@redhat.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> <56122EBD.1030405@redhat.com> <0fb30c0bd39a77fec7edc25c39cdc144.squirrel@webmail.nathanpeters.com> <5613B518.7060805@redhat.com> Message-ID: <779898645141558eac03ee2abfbc993d.squirrel@webmail.nathanpeters.com> > Your expectation #1 is correct, but there can be multiple reasons why it > fails. > > Did you try to set forward policy = only as I advised you in the previous > e-mail? Forward policy 'first' does not make sense when split-DNS is > involved > because you can end up with mixture of records from different views in one > cache, which obviously results in a mess. Yes, we ended up having to use the forward only policy to get this working. That is unfortunate, because if our forwarding server ever goes down or gets rebooted, that essentially disconnects us from being able to resolve external internet domain names. It would be nice to have recursion as a fallback, but it seems to go into that mode too often to be useful in our split DNS situation. >> 2. We did some more network packet capture, and noticed that in forward >> first mode, the FreeIPA server, always sent out both a forward request >> to >> the forwarding server, and an additional simultaneous request to the >> root >> name servers (recursive mode). It got back responses to both the >> forwarded and recursive queries it had performed. The recursive query >> failed due to split DNS and the forwarded query succeeded due to it >> going >> to an internal server which had the correct records. Strangely >> enough... >> the IPA server ignored the successful forwarded answer, and sent back >> the >> 'failed' answer it had gotten through recursion back to the requesting >> client. What is the behavior supposed to be in this situation and why >> is >> the server always sending out the recursive request, even when it gets a >> valid answer from the forwarded request? > > This is weird, but again - it can have multiple reasons. Do you see > something > in BIND logs? Does it e.g. complain about DNSSEC validation failures? > > Petr^2 Spacek > Yes, we actually were getting DNSSEC validation failures. We had to disable DNSSEC to get the forward only policy to work. With DNSSEC turned on, forward only would not work because DNSSEC still tried to directly contact root servers. From schogan at us.ibm.com Tue Oct 6 16:16:37 2015 From: schogan at us.ibm.com (Sean Hogan) Date: Tue, 6 Oct 2015 09:16:37 -0700 Subject: [Freeipa-users] Groups Message-ID: <201510061616.t96GGoG8031302@d01av03.pok.ibm.com> Hello, I have been rolling out an IPA deployment for IBM Watson for the past 3 months. Initially I did not want to take on application ids (linux OS Ids owning apps). I now have to so I have created the accounts in IPA however new files created by user wdadeploy are being created with wdadeploy:wdadeploy where the app team wants new files owned wdadeploy:wdaadmins. Is there a way to accomplish this? I wanted the application IDs to stay local but they want to see if this works. Sean Hogan Security Engineer CISSP,RHCSA,CCNA,MCP,HDI Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan at us.ibm.com | Tel 919 486 1397 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09780907.gif Type: image/gif Size: 10163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09354604.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09304130.gif Type: image/gif Size: 1650 bytes Desc: not available URL: From aebruno2 at buffalo.edu Tue Oct 6 17:13:32 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Tue, 6 Oct 2015 13:13:32 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <5613FC70.4090100@redhat.com> References: <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> <5613D934.3080701@redhat.com> <20151006143041.GC24698@dead.ccr.buffalo.edu> <5613FC70.4090100@redhat.com> Message-ID: <20151006171332.GD24698@dead.ccr.buffalo.edu> On Tue, Oct 06, 2015 at 12:53:04PM -0400, Mark Reynolds wrote: > > > On 10/06/2015 10:30 AM, Andrew E. Bruno wrote: > >On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote: > >>Andrew E. Bruno wrote: > >>>On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: > >>>>Andrew E. Bruno wrote: > >>>>>The replica is not showing up when running ipa-replica-manage list. > >>>>> > >>>>> # ipa-replica-manage list > >>>>> srv-m14-32.cbls.ccr.buffalo.edu: master > >>>>> srv-m14-31-02.cbls.ccr.buffalo.edu: master > >>>>> > >>>>> > >>>>>However, still seeing the ruvs in ldapsearch: > >>>>> > >>>>>ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > >>>>> > >>>>> > >>>>>nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > >>>>> 00050000 55b2aa68000200050000 > >>>>> > >>>>> > >>>>>.. > >>>>> > >>>>>nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > >>>>> 0005b0000 55b13e740000005b0000 > >>>>> > >>>>> > >>>>>Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 > >>>>> > >>>>>Thanks again for the all the help. > >>>>> > >>>>>--Andrew > >>>>> > >>>>> > >>>>Note that the list of masters comes from entries in IPA, not from > >>>>replication agreements. > >>>> > >>>>ipa-replica-manage list-ruv will show the RUV data in a simpler way. > >>>> > >>>>Yeah, I'd use clean-ruv to clean them up. > >>>> > >>>>rob > >>>> > >>>> > >>>I get an error trying to clean-ruv: > >>> > >>> # ipa-replica-manage clean-ruv 5 > >>> Replica ID 5 not found > >>> > >>>Can these safely be ignored? or will we hit problems when adding the > >>>replica back in? > >>ipa-replica-manage list-ruv will show you the current RUV list. If it > >>isn't there then yeah, you're done. > >> > >>Having unused RUV in a master causes it to do unnecessary replication > >>calculations. > >> > >>rob > >Yes, list-ruv seems to show the correct RUV list. > > > ># ipa-replica-manage list-ruv > >srv-m14-32.cbls.ccr.buffalo.edu:389: 4 > >srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3 > > > >It's just the ldapsearch that's showing repid 5 : > > > >ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > I think this can be ignored sicne its on the repl agreement, and not the > backend. > > What does this ldapsearch return: > > replace -b with your suffix > > ldapsearch -Y GSSAPI -b|"dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' > nsds50ruv| > > > Mark Here's the results of the above query: dn: cn=replica,cn=dc\3Dcbls\2Cdc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tr ee,cn=config nsds50ruv: {replicageneration} 55a95591000000040000 nsds50ruv: {replica 4 ldap://srv-m14-32.cbls.ccr.buffalo.edu:389} 55a955fa0000 00040000 561400b3000700040000 nsds50ruv: {replica 3 ldap://srv-m14-31-02.cbls.ccr.buffalo.edu:389} 55a955960 00000030000 5613f7b5000200030000 nsds50ruv: {replica 5} 5600051d001000050000 5600051d001000050000 Still see that replica 5? Is that normal? Thanks! --Andrew From rcritten at redhat.com Tue Oct 6 17:14:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Oct 2015 13:14:36 -0400 Subject: [Freeipa-users] Groups In-Reply-To: <201510061616.t96GGoG8031302@d01av03.pok.ibm.com> References: <201510061616.t96GGoG8031302@d01av03.pok.ibm.com> Message-ID: <5614017C.3010700@redhat.com> Sean Hogan wrote: > Hello, > > I have been rolling out an IPA deployment for IBM Watson for the past 3 > months. Initially I did not want to take on application ids (linux OS > Ids owning apps). I now have to so I have created the accounts in IPA > however new files created by user wdadeploy are being created with > wdadeploy:wdadeploy where the app team wants new files owned > wdadeploy:wdaadmins. Is there a way to accomplish this? I wanted the > application IDs to stay local but they want to see if this works. By default IPA creates users with a user-private group. This is a POSIX group that cannot have members with the same name as the user (and the UID and GID will match). SSSD gets the primary group from the GID attribute in the user so you have a couple of options that I can see: 1. Modify the user to set the GID to the GID of wdaadmins 2. 1. and also detach the private group from the user since it isn't being used any more (and you can delete it if you know you'll never use it). Note that once detached it can never be re-attached (or not via any IPA-provided tools anyway). Now strictly speaking I don't think that wdadeploy needs to be a member of wdaadmins for this to work but that would probably be quite confusing in the long-run. Use the id command to confirm that the gid resolves to wdaadmins. rob From mareynol at redhat.com Tue Oct 6 18:29:49 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 6 Oct 2015 14:29:49 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <20151006171332.GD24698@dead.ccr.buffalo.edu> References: <20151002160059.GB18409@dead.ccr.buffalo.edu> <561253AA.4050509@redhat.com> <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> <5613D934.3080701@redhat.com> <20151006143041.GC24698@dead.ccr.buffalo.edu> <5613FC70.4090100@redhat.com> <20151006171332.GD24698@dead.ccr.buffalo.edu> Message-ID: <5614131D.9050907@redhat.com> On 10/06/2015 01:13 PM, Andrew E. Bruno wrote: > On Tue, Oct 06, 2015 at 12:53:04PM -0400, Mark Reynolds wrote: >> >> On 10/06/2015 10:30 AM, Andrew E. Bruno wrote: >>> On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote: >>>> Andrew E. Bruno wrote: >>>>> On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: >>>>>> Andrew E. Bruno wrote: >>>>>>> The replica is not showing up when running ipa-replica-manage list. >>>>>>> >>>>>>> # ipa-replica-manage list >>>>>>> srv-m14-32.cbls.ccr.buffalo.edu: master >>>>>>> srv-m14-31-02.cbls.ccr.buffalo.edu: master >>>>>>> >>>>>>> >>>>>>> However, still seeing the ruvs in ldapsearch: >>>>>>> >>>>>>> ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL >>>>>>> >>>>>>> >>>>>>> nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 >>>>>>> 00050000 55b2aa68000200050000 >>>>>>> >>>>>>> >>>>>>> .. >>>>>>> >>>>>>> nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 >>>>>>> 0005b0000 55b13e740000005b0000 >>>>>>> >>>>>>> >>>>>>> Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 >>>>>>> >>>>>>> Thanks again for the all the help. >>>>>>> >>>>>>> --Andrew >>>>>>> >>>>>>> >>>>>> Note that the list of masters comes from entries in IPA, not from >>>>>> replication agreements. >>>>>> >>>>>> ipa-replica-manage list-ruv will show the RUV data in a simpler way. >>>>>> >>>>>> Yeah, I'd use clean-ruv to clean them up. >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>> I get an error trying to clean-ruv: >>>>> >>>>> # ipa-replica-manage clean-ruv 5 >>>>> Replica ID 5 not found >>>>> >>>>> Can these safely be ignored? or will we hit problems when adding the >>>>> replica back in? >>>> ipa-replica-manage list-ruv will show you the current RUV list. If it >>>> isn't there then yeah, you're done. >>>> >>>> Having unused RUV in a master causes it to do unnecessary replication >>>> calculations. >>>> >>>> rob >>> Yes, list-ruv seems to show the correct RUV list. >>> >>> # ipa-replica-manage list-ruv >>> srv-m14-32.cbls.ccr.buffalo.edu:389: 4 >>> srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3 >>> >>> It's just the ldapsearch that's showing repid 5 : >>> >>> ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL >> I think this can be ignored sicne its on the repl agreement, and not the >> backend. >> >> What does this ldapsearch return: >> >> replace -b with your suffix >> >> ldapsearch -Y GSSAPI -b|"dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >> nsds50ruv| >> >> >> Mark > > Here's the results of the above query: > > > dn: cn=replica,cn=dc\3Dcbls\2Cdc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tr > ee,cn=config > nsds50ruv: {replicageneration} 55a95591000000040000 > nsds50ruv: {replica 4 ldap://srv-m14-32.cbls.ccr.buffalo.edu:389} 55a955fa0000 > 00040000 561400b3000700040000 > nsds50ruv: {replica 3 ldap://srv-m14-31-02.cbls.ccr.buffalo.edu:389} 55a955960 > 00000030000 5613f7b5000200030000 > nsds50ruv: {replica 5} 5600051d001000050000 5600051d001000050000 > > > Still see that replica 5? Is that normal? It's still present, and if you were having replication issues its possible the changelog recreated that old replica ID (replica 5) after it was cleaned. This changelog resurrection bug has been fixed upstream- fyi. So, you need to rerun cleanallruv. If the IPA CLI is not detecting the replica id you are trying to delete, then you can run the 389-ds-base cleanallruv.pl script and run it on the server with the old rid: cleanallruv.pl -D "cn=directory manager" -w password -b "dc=cbls,dc=ccr,dc=buffalo,dc=edu" -r 5 Wait a minute, and rerun that ldapsearch to see if the replica ID was removed/cleaned. Mark > > Thanks! > > --Andrew > From aebruno2 at buffalo.edu Tue Oct 6 18:45:41 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Tue, 6 Oct 2015 14:45:41 -0400 Subject: [Freeipa-users] re-initialize replica In-Reply-To: <5614131D.9050907@redhat.com> References: <20151005183851.GF11918@dead.ccr.buffalo.edu> <5612C610.8060706@redhat.com> <20151006122235.GA24698@dead.ccr.buffalo.edu> <5613CE0C.9090408@redhat.com> <20151006135252.GB24698@dead.ccr.buffalo.edu> <5613D934.3080701@redhat.com> <20151006143041.GC24698@dead.ccr.buffalo.edu> <5613FC70.4090100@redhat.com> <20151006171332.GD24698@dead.ccr.buffalo.edu> <5614131D.9050907@redhat.com> Message-ID: <20151006184541.GE24698@dead.ccr.buffalo.edu> On Tue, Oct 06, 2015 at 02:29:49PM -0400, Mark Reynolds wrote: > > > On 10/06/2015 01:13 PM, Andrew E. Bruno wrote: > >On Tue, Oct 06, 2015 at 12:53:04PM -0400, Mark Reynolds wrote: > >> > >>On 10/06/2015 10:30 AM, Andrew E. Bruno wrote: > >>>On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote: > >>>>Andrew E. Bruno wrote: > >>>>>On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote: > >>>>>>Andrew E. Bruno wrote: > >>>>>>>The replica is not showing up when running ipa-replica-manage list. > >>>>>>> > >>>>>>> # ipa-replica-manage list > >>>>>>> srv-m14-32.cbls.ccr.buffalo.edu: master > >>>>>>> srv-m14-31-02.cbls.ccr.buffalo.edu: master > >>>>>>> > >>>>>>> > >>>>>>>However, still seeing the ruvs in ldapsearch: > >>>>>>> > >>>>>>>ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > >>>>>>> > >>>>>>> > >>>>>>>nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000 > >>>>>>> 00050000 55b2aa68000200050000 > >>>>>>> > >>>>>>> > >>>>>>>.. > >>>>>>> > >>>>>>>nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000 > >>>>>>> 0005b0000 55b13e740000005b0000 > >>>>>>> > >>>>>>> > >>>>>>>Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5 > >>>>>>> > >>>>>>>Thanks again for the all the help. > >>>>>>> > >>>>>>>--Andrew > >>>>>>> > >>>>>>> > >>>>>>Note that the list of masters comes from entries in IPA, not from > >>>>>>replication agreements. > >>>>>> > >>>>>>ipa-replica-manage list-ruv will show the RUV data in a simpler way. > >>>>>> > >>>>>>Yeah, I'd use clean-ruv to clean them up. > >>>>>> > >>>>>>rob > >>>>>> > >>>>>> > >>>>>I get an error trying to clean-ruv: > >>>>> > >>>>> # ipa-replica-manage clean-ruv 5 > >>>>> Replica ID 5 not found > >>>>> > >>>>>Can these safely be ignored? or will we hit problems when adding the > >>>>>replica back in? > >>>>ipa-replica-manage list-ruv will show you the current RUV list. If it > >>>>isn't there then yeah, you're done. > >>>> > >>>>Having unused RUV in a master causes it to do unnecessary replication > >>>>calculations. > >>>> > >>>>rob > >>>Yes, list-ruv seems to show the correct RUV list. > >>> > >>># ipa-replica-manage list-ruv > >>>srv-m14-32.cbls.ccr.buffalo.edu:389: 4 > >>>srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3 > >>> > >>>It's just the ldapsearch that's showing repid 5 : > >>> > >>>ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement -LL > >>I think this can be ignored sicne its on the repl agreement, and not the > >>backend. > >> > >>What does this ldapsearch return: > >> > >>replace -b with your suffix > >> > >>ldapsearch -Y GSSAPI -b|"dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' > >>nsds50ruv| > >> > >> > >>Mark > > > >Here's the results of the above query: > > > > > >dn: cn=replica,cn=dc\3Dcbls\2Cdc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tr > > ee,cn=config > >nsds50ruv: {replicageneration} 55a95591000000040000 > >nsds50ruv: {replica 4 ldap://srv-m14-32.cbls.ccr.buffalo.edu:389} 55a955fa0000 > > 00040000 561400b3000700040000 > >nsds50ruv: {replica 3 ldap://srv-m14-31-02.cbls.ccr.buffalo.edu:389} 55a955960 > > 00000030000 5613f7b5000200030000 > >nsds50ruv: {replica 5} 5600051d001000050000 5600051d001000050000 > > > > > >Still see that replica 5? Is that normal? > It's still present, and if you were having replication issues its possible > the changelog recreated that old replica ID (replica 5) after it was > cleaned. This changelog resurrection bug has been fixed upstream- fyi. > > So, you need to rerun cleanallruv. If the IPA CLI is not detecting the > replica id you are trying to delete, then you can run the 389-ds-base > cleanallruv.pl script and run it on the server with the old rid: > > cleanallruv.pl -D "cn=directory manager" -w password -b > "dc=cbls,dc=ccr,dc=buffalo,dc=edu" -r 5 > > Wait a minute, and rerun that ldapsearch to see if the replica ID was > removed/cleaned. > > Mark Worked like a charm. cleanallruv.pl removed the replicate id and I verified it was gone via the ldapsearch. Thanks so much. Appreciate all the help. From lesley.j.kimmel at gmail.com Tue Oct 6 17:35:15 2015 From: lesley.j.kimmel at gmail.com (Lesley Kimmel) Date: Tue, 6 Oct 2015 12:35:15 -0500 Subject: [Freeipa-users] RedHat IdM Active Directory Integration Message-ID: Hi all; I'm working an initiative to centralize user accounts in Active Directory. We have a large RHEL (6+) footprint and want to manage these as well. I am a Red Hat Engineer on the project and, while it is possible to integrate all of the RHEL clients directly to AD, I have a nagging feeling that using IdM as an intermediary would be a good approach. However, I have never implemented it and experienced the solidity of integration with AD so I can't formulate a solid argument at this point. My primary belief is that using IdM would allow for the Unix administrators better control over their environment. However, even in that case we also have Satellite so we likely wouldn't use IdM for policy centralization. I'm curious whether it is possible to store all user, group and system objects in Active Directory and then allow the configuration of host based access control policies from IdM using those AD objects. That might be one argument for it. As an add-on to that question how is the HBAC actually implemented in IdM? It doesn't simply push down a policy for pam_access does it? Also, if users were configured with Smart Card information in AD could these users authenticate to Linux clients with IdM as an intermediary? Thanks ahead of time! -LK -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesley.j.kimmel at gmail.com Tue Oct 6 18:48:21 2015 From: lesley.j.kimmel at gmail.com (Lesley Kimmel) Date: Tue, 6 Oct 2015 13:48:21 -0500 Subject: [Freeipa-users] RedHat IdM Active Directory Integration Message-ID: Hi all; I'm working an initiative to centralize user accounts in Active Directory. We have a large RHEL (6+) footprint and want to manage these as well. I am a Red Hat Engineer on the project and, while it is possible to integrate all of the RHEL clients directly to AD, I have a nagging feeling that using IdM as an intermediary would be a good approach. However, I have never implemented it and experienced the solidity of integration with AD so I can't formulate a solid argument at this point. My primary belief is that using IdM would allow for the Unix administrators better control over their environment. However, even in that case we also have Satellite so we likely wouldn't use IdM for policy centralization. I'm curious whether it is possible to store all user, group and system objects in Active Directory and then allow the configuration of host based access control policies from IdM using those AD objects. That might be one argument for it. As an add-on to that question how is the HBAC actually implemented in IdM? It doesn't simply push down a policy for pam_access does it? Also, if users were configured with Smart Card information in AD could these users authenticate to Linux clients with IdM as an intermediary? Thanks ahead of time! -LK -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 7 02:06:19 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 6 Oct 2015 22:06:19 -0400 Subject: [Freeipa-users] Groups In-Reply-To: <5614017C.3010700@redhat.com> References: <201510061616.t96GGoG8031302@d01av03.pok.ibm.com> <5614017C.3010700@redhat.com> Message-ID: <56147E1B.1040608@redhat.com> On 06/10/15 13:14, Rob Crittenden wrote: > Sean Hogan wrote: >> Hello, >> >> I have been rolling out an IPA deployment for IBM Watson for the past 3 >> months. Initially I did not want to take on application ids (linux OS >> Ids owning apps). I now have to so I have created the accounts in IPA >> however new files created by user wdadeploy are being created with >> wdadeploy:wdadeploy where the app team wants new files owned >> wdadeploy:wdaadmins. Is there a way to accomplish this? I wanted the >> application IDs to stay local but they want to see if this works. > > By default IPA creates users with a user-private group. This is a POSIX > group that cannot have members with the same name as the user (and the > UID and GID will match). > > SSSD gets the primary group from the GID attribute in the user so you > have a couple of options that I can see: > > 1. Modify the user to set the GID to the GID of wdaadmins > 2. 1. and also detach the private group from the user since it isn't > being used any more (and you can delete it if you know you'll never use > it). Note that once detached it can never be re-attached (or not via any > IPA-provided tools anyway). > > Now strictly speaking I don't think that wdadeploy needs to be a member > of wdaadmins for this to work but that would probably be quite confusing > in the long-run. > > Use the id command to confirm that the gid resolves to wdaadmins. Another option is to keep stuff as it is in IPA and use file system default ACLs so that wdaadmins get read/write or whatever access on the files wdadeploy creates. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Wed Oct 7 02:37:17 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Oct 2015 02:37:17 +0000 Subject: [Freeipa-users] dogtag v CA less In-Reply-To: <56147E1B.1040608@redhat.com> References: <201510061616.t96GGoG8031302@d01av03.pok.ibm.com> <5614017C.3010700@redhat.com>,<56147E1B.1040608@redhat.com> Message-ID: Hi, I am trying to determine what the difference is between the 2 options above in IPA4.1 and the implications and complications are of using one or other. Also which one would be the better choice and why? Can someone explain in simple terms please? regards Steven From ender at kofeina.net Wed Oct 7 06:35:11 2015 From: ender at kofeina.net (=?windows-1250?Q?=A3ukasz_Jaworski?=) Date: Wed, 7 Oct 2015 08:35:11 +0200 Subject: [Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki Message-ID: <791274AA-7856-4E48-B8D5-D665E6FE5490@kofeina.net> Hi, I have problem with setup new replicas. I tried setup two replicas, both failed with the same error. environment: Fedora 21 packages: freeipa-server-4.1.3-2.fc21.x86_64 389-ds-base-1.3.3.8-1.fc21.x86_64 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 pki-server-10.2.0-5.fc21.noarch same on server and replicas Output from ipa-replica-install: (?) Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/22]: creating certificate server user [2/22]: configuring certificate server instance [3/22]: stopping certificate server instance to update CS.cfg [4/22]: backing up CS.cfg [5/22]: disabling nonces [6/22]: set up CRL publishing [7/22]: enable PKIX certificate path discovery and validation [8/22]: starting certificate server instance [error] RuntimeError: CA did not start in 300.0s Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. >From /var/log/ipareplica.log 2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted 2015-10-07T06:25:58Z DEBUG Waiting for CA to start... 2015-10-07T06:25:59Z DEBUG Starting external process 2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://182.example.com:8443/ca/admin/c a/getStatus' 2015-10-07T06:25:59Z DEBUG Process finished, return code=8 2015-10-07T06:25:59Z DEBUG stdout= 2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59-- https://182.example.com:8443/ca/admin/ca/getStatus Resolving 182.example.com (182.example.com)... xx.xx.xx.xx Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... connected. WARNING: cannot verify 182.example.com's certificate, issued by ?CN=Certificate Authority,O=ecample.com?: Self-signed certificate encountered. HTTP request sent, awaiting response... HTTP/1.1 500 Internal Server Error Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 2923 Date: Wed, 07 Oct 2015 06:25:59 GMT Connection: close 2015-10-07 08:25:59 ERROR 500: Internal Server Error. Any idea? Best regards, Ender -- ?ukasz Jaworski From jhrozek at redhat.com Wed Oct 7 08:02:41 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Oct 2015 10:02:41 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: Message-ID: <20151007080241.GP3048@hendrix> On Mon, Oct 05, 2015 at 01:25:09PM +0000, Zoske, Fabian wrote: > Dear Jakub, > > I found only the following entries in the /var/log/auth.log: > > Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed > Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify password for [f.zoske at de.eu.local] > Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local > Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user f.zoske at de.eu.local: 7 (Authentication failure) > Oct 5 11:57:38 hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/cat /etc/sssd/sssd.conf > Oct 5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local > Oct 5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local > Oct 5 11:57:43 hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash > Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local > Oct 5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local > Oct 5 11:57:47 hl-srv10 sudo: f.zoske at de.eu.local : TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash > Oct 5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for user root by f.zoske at de.eu.local(uid=0) > > In /var/log/sssd/ no entries were logged. Nothing gets logged in by default, you need to increase debug_level, see: https://fedorahosted.org/sssd/wiki/Troubleshooting I would look into the domain log and krb5_child.log first > > My sssd.conf: > [domain/ipa-lx.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa-lx.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = hl-srv10.ipa-lx.com > chpass_provider = ipa > ipa_server = _srv_, dc01.ipa-lx.com > ldap_tls_cacert = /etc/ipa/ca.crt > ldap_sudo_use_host_filter = false > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > default_domain_suffix = de.eu.local > domains = ei-ag.it > > [nss] > override_shell = /bin/bash > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > Best regards, > Fabian > -- > 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 From jhrozek at redhat.com Wed Oct 7 08:03:13 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Oct 2015 10:03:13 +0200 Subject: [Freeipa-users] sudo rules do not seem to work In-Reply-To: References: Message-ID: <20151007080313.GQ3048@hendrix> On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote: > Hello, > > I had assumed sudo rules worked because I have an "allow_all for admins" > sudo rule that seemed to work, but I wonder if there is an implicit rule > for the special group admins ? > > > Because I have tried to replicate this allow_all rule for for other user > groups, and it does not seem to work at all. > What's strange is that "sudo -l" report the appropriate rules, but they do > not work. > > For instance, some users have: (ALL) ALL listed with sudo -l, but they can > not use sudo. > > My user has: > (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status > (ALL) ALL > (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod > -R g[+-]* * > (ALL) NOPASSWD: /usr/bin/less > (ALL) ALL > > but I'm prompted a password when doing "sudo /usr/bin/less". > > How can I debug this ? Pavel (CC) has a nice sudo debug howto, maybe it would be helpful? From alex.williams at brighter-technology.com Wed Oct 7 07:49:57 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Wed, 7 Oct 2015 08:49:57 +0100 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 Message-ID: <5614CEA5.9040406@brighter-technology.com> Hi guys, yesterday I finally managed to get our IPA3.0.0 servers in a state that I could upgrade the schema to dogtag 10, using the migration script and launched a new RHEL7.1 IPA4.1 server as a replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be our CRL master), I can no longer search for hosts or DNS entries, or host groups, either in the UI, or on the command line. They're there, they show up when you go to the hosts, dns or user page in a list, but you cannot then refine the search. This is also true of ipa host-find and ipa hostgroup-find on the command line. Is this a bug in IPA4.1? Is it a schema issue? Is it just because we still have an IPA3 server running the show and an IPA4 replica? I can't really justify dropping our production IPA3 servers, if searching for records doesn't work in IPA4.1. I still appear to be able to search in the UI of one of our other IPA3 servers, despite the fact it has had its schema updated and it has been connected to the new IPA4 server. Thanks in advance for any help anyone can offer. Cheers Alex From sbose at redhat.com Wed Oct 7 08:37:09 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Oct 2015 10:37:09 +0200 Subject: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04 In-Reply-To: References: <20151002155951.GB3127@hendrix.redhat.com> <20151005120744.GB19585@p.redhat.com> <20151006130144.GC30474@p.redhat.com> Message-ID: <20151007083709.GE30474@p.redhat.com> On Tue, Oct 06, 2015 at 03:39:43PM +0200, Alexander Skwar wrote: > Hello Sumit > > ipa-client-install hasn't set krb5_realm. I did that. > > We're using Chef-Solo to manage our systems and I have /etc/sssd/sssd.conf > in chef. So it overwrote, whatever ipa-client-install put there. And that's > how the mistake happened. Thank you for the details, I was afraid there might be an issue with ipa-client-install. Btw, please note that there are important differences in /etc/sssd/sssd.conf for IPA clients and servers. Additionally if you have multiple IPA servers you should make sure that suitable server names are used in ipa_server = _srv_, ipa-server.ipa.domain on IPA clients. Although it is only a fallback server name it would be good to have all IPA servers involved here so that in the case of issues not all clients will fall back to the same server. bye, Sumit > > I think the ipa-client-install discovered everything right. I'm attaching > the log. yes, all looks good. > > Best regards, > Alexander > > > > From sbose at redhat.com Wed Oct 7 08:51:17 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Oct 2015 10:51:17 +0200 Subject: [Freeipa-users] RedHat IdM Active Directory Integration In-Reply-To: References: Message-ID: <20151007085117.GF30474@p.redhat.com> On Tue, Oct 06, 2015 at 01:48:21PM -0500, Lesley Kimmel wrote: > Hi all; > > I'm working an initiative to centralize user accounts in Active Directory. > We have a large RHEL (6+) footprint and want to manage these as well. I am > a Red Hat Engineer on the project and, while it is possible to integrate > all of the RHEL clients directly to AD, I have a nagging feeling that using > IdM as an intermediary would be a good approach. However, I have never > implemented it and experienced the solidity of integration with AD so I > can't formulate a solid argument at this point. > > My primary belief is that using IdM would allow for the Unix administrators > better control over their environment. However, even in that case we also > have Satellite so we likely wouldn't use IdM for policy centralization. I'm > curious whether it is possible to store all user, group and system objects > in Active Directory and then allow the configuration of host based access > control policies from IdM using those AD objects. That might be one Does https://www.youtube.com/watch?v=sQnNFJOzwa8 help you for a start? You can find additional details about HBAC on the IdM documentation at https://access.redhat.com/articles/1586893 . > argument for it. As an add-on to that question how is the HBAC actually > implemented in IdM? It doesn't simply push down a policy for pam_access > does it? no, SSSD on the clients read and evaluate the HBAC rules and grants or denies access accordingly. > > Also, if users were configured with Smart Card information in AD could > these users authenticate to Linux clients with IdM as an intermediary? Initial Smart Card support will be available in RHEL-7.2, but only for local authentication. In the next releases we will improve this. But is it open to what extend those features will be made available in RHEL6. Btw, authentication will always go directly to the right server, AD in your case, and not use IdM as a man-in-the-middle (only in special cases where legacy clients are involved). HTH bye, Sumit > > Thanks ahead of time! > > -LK > -- > 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 From mbasti at redhat.com Wed Oct 7 08:53:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 10:53:24 +0200 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614CEA5.9040406@brighter-technology.com> References: <5614CEA5.9040406@brighter-technology.com> Message-ID: <5614DD84.7030904@redhat.com> On 10/07/2015 09:49 AM, Alex Williams wrote: > Hi guys, > > yesterday I finally managed to get our IPA3.0.0 servers in a state > that I could upgrade the schema to dogtag 10, using the migration > script and launched a new RHEL7.1 IPA4.1 server as a replica. > Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old > RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be our > CRL master), I can no longer search for hosts or DNS entries, or host > groups, either in the UI, or on the command line. > > They're there, they show up when you go to the hosts, dns or user page > in a list, but you cannot then refine the search. This is also true of > ipa host-find and ipa hostgroup-find on the command line. Is this a > bug in IPA4.1? Is it a schema issue? Is it just because we still have > an IPA3 server running the show and an IPA4 replica? I can't really > justify dropping our production IPA3 servers, if searching for records > doesn't work in IPA4.1. > > I still appear to be able to search in the UI of one of our other IPA3 > servers, despite the fact it has had its schema updated and it has > been connected to the new IPA4 server. > > Thanks in advance for any help anyone can offer. > > Cheers > > Alex > Hello, can you provide more info please: * are you kinited as admin user? * does ipa dnszone-find returns all results? * does ipa dnszone-find return something? * does ipa dnszone-show return the zone? We had issue with access control, where non admin users cannot search for zones, I'm not sure about hosts, and host groups. I do not think that this is a schema upgrade issue nor related to Dogtag 10. Martin From pbrezina at redhat.com Wed Oct 7 09:19:02 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 07 Oct 2015 11:19:02 +0200 Subject: [Freeipa-users] sudo rules do not seem to work In-Reply-To: <20151007080313.GQ3048@hendrix> References: <20151007080313.GQ3048@hendrix> Message-ID: <5614E386.30800@redhat.com> On 10/07/2015 10:03 AM, Jakub Hrozek wrote: > On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote: >> Hello, >> >> I had assumed sudo rules worked because I have an "allow_all for admins" >> sudo rule that seemed to work, but I wonder if there is an implicit rule >> for the special group admins ? >> >> >> Because I have tried to replicate this allow_all rule for for other user >> groups, and it does not seem to work at all. >> What's strange is that "sudo -l" report the appropriate rules, but they do >> not work. >> >> For instance, some users have: (ALL) ALL listed with sudo -l, but they can >> not use sudo. >> >> My user has: >> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status >> (ALL) ALL >> (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod >> -R g[+-]* * >> (ALL) NOPASSWD: /usr/bin/less >> (ALL) ALL >> >> but I'm prompted a password when doing "sudo /usr/bin/less". >> >> How can I debug this ? > > Pavel (CC) has a nice sudo debug howto, maybe it would be helpful? Hi, you are prompted for password because (ALL) ALL rule is applied because of last-match rule. See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. From mkosek at redhat.com Wed Oct 7 09:19:05 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 7 Oct 2015 11:19:05 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <5612696B.7050601@mittwald.de> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> Message-ID: <5614E389.4010001@redhat.com> On 10/05/2015 02:13 PM, Dominik Korittki wrote: > > > Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >> Dominik Korittki wrote: >>> Hello folks, >>> >>> I am running two FreeIPA Servers with around 100 users and around 15.000 >>> hosts, which are used by users to login via ssh. The FreeIPA servers >>> (which are Centos 7.0) ran good for a while, but as more and more hosts >>> got migrated to serve as FreeIPA hosts, it started to get slow and >>> unstable. >>> >>> For example, its hard to maintain hostgroups, which have more than 1.000 >>> hosts. The ipa host-* commands are getting slower as the hostgroup >>> grows. Is this normal? >> >> You mean the ipa hostgroup-* commands? Whenever the entry is displayed >> (show and add) it needs to dereference all members so yes, it is >> understandable that it gets somewhat slower with more members. How slow >> are we talking about? >> >>> We also experience random dirsrv segfaults. Here's a dmesg line from the >>> latest: >>> >>> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 >>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >> >> You probably want to start here: >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes > > A stacktrace from the latest crash is attached to this email. After restarting > the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors > (hostname is ipa01.internal): Ludwig or Thierry, can you please take a look at the stack and file 389-DS ticket if appropriate? > > [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All Interfaces port > 389 for LDAP requests > [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for LDAPS > requests > [05/Oct/2015:13:51:30 +0200] - Listening on /var/run/slapd-INTERNAL.socket for > LDAPI requests > [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: could > not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local > error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. > Minor code may provide more information (No Kerberos credentials available)) > errno 0 (Success) > [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform > interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local > error) > [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - > agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth > failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information (No Kerberos > credentials available)) > [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program - > agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN > 54bea480000000600000 not found, we aren't as up to date, or we purged > [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data required > to update replica has been purged. The replica must be reinitialized. > [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Incremental > update failed and requires administrator action > [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - > agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth > resumed > > > These lines are present since a replayed a ldif dump from ipa02 to ipa01, but i > didn't think that it related to the segfault problem (therefore i said there > are no related problems in the logfile). > > But I am starting to believe that these errors could be in relation to each other. > > > Kind regards, > Dominik Korittki > > >> >> >>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >>> problem. > > Not sure about that anymore. > >>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that >>> solve my problems? >>> >>> FreeIPA server version is 3.3.3-28.el7.centos >>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>> >>> >>> >>> Kind regards, >>> Dominik Korittki >>> >> >> >> >> > > From alex.williams at brighter-technology.com Wed Oct 7 09:23:18 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Wed, 7 Oct 2015 10:23:18 +0100 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614DD84.7030904@redhat.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> Message-ID: <5614E486.5090609@brighter-technology.com> On 07/10/15 09:53, Martin Basti wrote: > > > On 10/07/2015 09:49 AM, Alex Williams wrote: >> Hi guys, >> >> yesterday I finally managed to get our IPA3.0.0 servers in a state >> that I could upgrade the schema to dogtag 10, using the migration >> script and launched a new RHEL7.1 IPA4.1 server as a replica. >> Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old >> RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be >> our CRL master), I can no longer search for hosts or DNS entries, or >> host groups, either in the UI, or on the command line. >> >> They're there, they show up when you go to the hosts, dns or user >> page in a list, but you cannot then refine the search. This is also >> true of ipa host-find and ipa hostgroup-find on the command line. Is >> this a bug in IPA4.1? Is it a schema issue? Is it just because we >> still have an IPA3 server running the show and an IPA4 replica? I >> can't really justify dropping our production IPA3 servers, if >> searching for records doesn't work in IPA4.1. >> >> I still appear to be able to search in the UI of one of our other >> IPA3 servers, despite the fact it has had its schema updated and it >> has been connected to the new IPA4 server. >> >> Thanks in advance for any help anyone can offer. >> >> Cheers >> >> Alex >> > Hello, > > can you provide more info please: > > * are you kinited as admin user? > * does ipa dnszone-find returns all results? > * does ipa dnszone-find return something? > * does ipa dnszone-show return the zone? > > We had issue with access control, where non admin users cannot search > for zones, I'm not sure about hosts, and host groups. > I do not think that this is a schema upgrade issue nor related to > Dogtag 10. > > Martin Hi Martin, thanks for the quick response. So, I have not kinited as the admin user, however as root and as my own username (A member of the admins group in IPA), all of the commands you requested that I test, work fine. As it turns out, I can run all of the following on the command line, as my user, or as root and it all works fine. My colleague who attempted to do so this morning under his username, can do so if he kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? Unfortunately, my user still cannot search for hosts, hostgroups, or DNS entries within the UI. ipa user-find - returns a list of 100 users ipa user-find $username - returns the details of that user ipa host-find returns a list of 100 hosts ipa host-find $hostname - returns the details of the host ipa host-find $partial-hostname - returns a list of hosts which have the search string inside their hostname ipa hostgroup-find - returns a list of hostgroups ipa hostgroup-find $hostgroupname - returns details of the hostgroup Regards Alex From ender at kofeina.net Wed Oct 7 09:44:26 2015 From: ender at kofeina.net (=?windows-1250?Q?=A3ukasz_Jaworski?=) Date: Wed, 7 Oct 2015 11:44:26 +0200 Subject: [Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki In-Reply-To: <791274AA-7856-4E48-B8D5-D665E6FE5490@kofeina.net> References: <791274AA-7856-4E48-B8D5-D665E6FE5490@kofeina.net> Message-ID: Looks like system is missing ca cert (should it be added during ipa-replica-install?) I don't know if missing cert is main problem in my case, but I made some tests: try 1: openssl s_client -connect `hostname -f`:8443 (?) Verify return code: 19 (self signed certificate in certificate chain) try 2: openssl s_client -connect `hostname -f`:8443 -CAfile /etc/ipa/ca.crt (?) Verify return code: 0 (ok) After I've added ipa.cert into /etc/pki/tls/cert.pem cat /etc/ipa/ca.crt >> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem try 3: openssl s_client -connect `hostname -f`:8443 (?) Verify return code: 0 (ok) Best regards, Ender -- ?ukasz Jaworski Wiadomo?? napisana przez ?ukasz Jaworski w dniu 7 pa? 2015, o godz. 08:35: > Hi, > > I have problem with setup new replicas. > I tried setup two replicas, both failed with the same error. > > environment: > Fedora 21 > > packages: > freeipa-server-4.1.3-2.fc21.x86_64 > 389-ds-base-1.3.3.8-1.fc21.x86_64 > 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 > pki-server-10.2.0-5.fc21.noarch > > same on server and replicas > > > Output from ipa-replica-install: > (?) > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/22]: creating certificate server user > [2/22]: configuring certificate server instance > [3/22]: stopping certificate server instance to update CS.cfg > [4/22]: backing up CS.cfg > [5/22]: disabling nonces > [6/22]: set up CRL publishing > [7/22]: enable PKIX certificate path discovery and validation > [8/22]: starting certificate server instance > [error] RuntimeError: CA did not start in 300.0s > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > >> From /var/log/ipareplica.log > 2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted > 2015-10-07T06:25:58Z DEBUG Waiting for CA to start... > 2015-10-07T06:25:59Z DEBUG Starting external process > 2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://182.example.com:8443/ca/admin/c > a/getStatus' > 2015-10-07T06:25:59Z DEBUG Process finished, return code=8 > 2015-10-07T06:25:59Z DEBUG stdout= > 2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59-- https://182.example.com:8443/ca/admin/ca/getStatus > Resolving 182.example.com (182.example.com)... xx.xx.xx.xx > Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... connected. > WARNING: cannot verify 182.example.com's certificate, issued by ?CN=Certificate Authority,O=ecample.com?: > Self-signed certificate encountered. > HTTP request sent, awaiting response... > HTTP/1.1 500 Internal Server Error > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=utf-8 > Content-Language: en > Content-Length: 2923 > Date: Wed, 07 Oct 2015 06:25:59 GMT > Connection: close > 2015-10-07 08:25:59 ERROR 500: Internal Server Error. > > Any idea? > > Best regards, > Ender > > -- > ?ukasz Jaworski > > > -- > 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 From jhrozek at redhat.com Wed Oct 7 09:45:44 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Oct 2015 11:45:44 +0200 Subject: [Freeipa-users] sudo rules do not seem to work In-Reply-To: <5614E386.30800@redhat.com> References: <20151007080313.GQ3048@hendrix> <5614E386.30800@redhat.com> Message-ID: <20151007094544.GW3048@hendrix> On Wed, Oct 07, 2015 at 11:19:02AM +0200, Pavel B?ezina wrote: > On 10/07/2015 10:03 AM, Jakub Hrozek wrote: > >On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote: > >>Hello, > >> > >>I had assumed sudo rules worked because I have an "allow_all for admins" > >>sudo rule that seemed to work, but I wonder if there is an implicit rule > >>for the special group admins ? > >> > >> > >>Because I have tried to replicate this allow_all rule for for other user > >>groups, and it does not seem to work at all. > >>What's strange is that "sudo -l" report the appropriate rules, but they do > >>not work. > >> > >>For instance, some users have: (ALL) ALL listed with sudo -l, but they can > >>not use sudo. > >> > >>My user has: > >> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status > >> (ALL) ALL > >> (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod > >>-R g[+-]* * > >> (ALL) NOPASSWD: /usr/bin/less > >> (ALL) ALL > >> > >>but I'm prompted a password when doing "sudo /usr/bin/less". > >> > >>How can I debug this ? > > > >Pavel (CC) has a nice sudo debug howto, maybe it would be helpful? > > Hi, > you are prompted for password because (ALL) ALL rule is applied because of > last-match rule. See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html > sudoOrder. This might be a nice addition to your howto :) From mbasti at redhat.com Wed Oct 7 09:57:25 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 11:57:25 +0200 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614E486.5090609@brighter-technology.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> Message-ID: <5614EC85.8070904@redhat.com> On 10/07/2015 11:23 AM, Alex Williams wrote: > On 07/10/15 09:53, Martin Basti wrote: >> >> >> On 10/07/2015 09:49 AM, Alex Williams wrote: >>> Hi guys, >>> >>> yesterday I finally managed to get our IPA3.0.0 servers in a state >>> that I could upgrade the schema to dogtag 10, using the migration >>> script and launched a new RHEL7.1 IPA4.1 server as a replica. >>> Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old >>> RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be >>> our CRL master), I can no longer search for hosts or DNS entries, or >>> host groups, either in the UI, or on the command line. >>> >>> They're there, they show up when you go to the hosts, dns or user >>> page in a list, but you cannot then refine the search. This is also >>> true of ipa host-find and ipa hostgroup-find on the command line. Is >>> this a bug in IPA4.1? Is it a schema issue? Is it just because we >>> still have an IPA3 server running the show and an IPA4 replica? I >>> can't really justify dropping our production IPA3 servers, if >>> searching for records doesn't work in IPA4.1. >>> >>> I still appear to be able to search in the UI of one of our other >>> IPA3 servers, despite the fact it has had its schema updated and it >>> has been connected to the new IPA4 server. >>> >>> Thanks in advance for any help anyone can offer. >>> >>> Cheers >>> >>> Alex >>> >> Hello, >> >> can you provide more info please: >> >> * are you kinited as admin user? >> * does ipa dnszone-find returns all results? >> * does ipa dnszone-find return something? >> * does ipa dnszone-show return the zone? >> >> We had issue with access control, where non admin users cannot search >> for zones, I'm not sure about hosts, and host groups. >> I do not think that this is a schema upgrade issue nor related to >> Dogtag 10. >> >> Martin > > Hi Martin, > > thanks for the quick response. So, I have not kinited as the admin > user, however as root and as my own username (A member of the admins > group in IPA), all of the commands you requested that I test, work > fine. As it turns out, I can run all of the following on the command > line, as my user, or as root and it all works fine. My colleague who > attempted to do so this morning under his username, can do so if he > kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? > Unfortunately, my user still cannot search for hosts, hostgroups, or > DNS entries within the UI. > > ipa user-find - returns a list of 100 users > ipa user-find $username - returns the details of that user > ipa host-find returns a list of 100 hosts > ipa host-find $hostname - returns the details of the host > ipa host-find $partial-hostname - returns a list of hosts which have > the search string inside their hostname > ipa hostgroup-find - returns a list of hostgroups > ipa hostgroup-find $hostgroupname - returns details of the hostgroup > > Regards > > Alex If I understand correctly, you as admin group user, can search in CLI and cannot search in webUI? That is weird. For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS disallow some queries from user that are not in admin group. Martin From mkosek at redhat.com Wed Oct 7 10:01:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 7 Oct 2015 12:01:44 +0200 Subject: [Freeipa-users] RedHat IdM Active Directory Integration In-Reply-To: References: Message-ID: <5614ED88.7070802@redhat.com> On 10/06/2015 07:35 PM, Lesley Kimmel wrote: > Hi all; > > I'm working an initiative to centralize user accounts in Active Directory. > We have a large RHEL (6+) footprint and want to manage these as well. I am > a Red Hat Engineer on the project and, while it is possible to integrate > all of the RHEL clients directly to AD, I have a nagging feeling that using > IdM as an intermediary would be a good approach. However, I have never > implemented it and experienced the solidity of integration with AD so I > can't formulate a solid argument at this point. > > My primary belief is that using IdM would allow for the Unix administrators > better control over their environment. Yes, it would allow you easy control/integration for Linux based services, like SUDO, automount and others. It may also save some costs, as if you join the hosts directly to AD, you may need to pay the CLAs. > However, even in that case we also > have Satellite so we likely wouldn't use IdM for policy centralization. What policy do you have in mind right now, authorization? > I'm > curious whether it is possible to store all user, group and system objects > in Active Directory and then allow the configuration of host based access > control policies from IdM using those AD objects. Yes, this should work with IdM external groups used in HBAC: https://www.youtube.com/watch?v=sQnNFJOzwa8 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html#about-hbac > That might be one > argument for it. As an add-on to that question how is the HBAC actually > implemented in IdM? It doesn't simply push down a policy for pam_access > does it? HBAC is evaluated on the client (SSSD), i.e. that makes SSSD a requirement to use HBAC. > > Also, if users were configured with Smart Card information in AD could > these users authenticate to Linux clients with IdM as an intermediary? This *may* work with the current Smart Card implementation in SSSD 1.13. It should just work with IdM users and registered SC certificates out of the box, for AD, some additional configuration will be required, Sumit will know more. From pspacek at redhat.com Wed Oct 7 10:05:04 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 7 Oct 2015 12:05:04 +0200 Subject: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working In-Reply-To: <779898645141558eac03ee2abfbc993d.squirrel@webmail.nathanpeters.com> References: <0b25b6317a7d34927e8f81743a88e157.squirrel@webmail.nathanpeters.com> <7a8d700fff553f33563e9648f378fae8.squirrel@webmail.nathanpeters.com> <56122EBD.1030405@redhat.com> <0fb30c0bd39a77fec7edc25c39cdc144.squirrel@webmail.nathanpeters.com> <5613B518.7060805@redhat.com> <779898645141558eac03ee2abfbc993d.squirrel@webmail.nathanpeters.com> Message-ID: <5614EE50.7010604@redhat.com> On 6.10.2015 18:57, nathan at nathanpeters.com wrote: >> Your expectation #1 is correct, but there can be multiple reasons why it >> fails. >> >> Did you try to set forward policy = only as I advised you in the previous >> e-mail? Forward policy 'first' does not make sense when split-DNS is >> involved >> because you can end up with mixture of records from different views in one >> cache, which obviously results in a mess. > > Yes, we ended up having to use the forward only policy to get this > working. That is unfortunate, because if our forwarding server ever goes > down or gets rebooted, that essentially disconnects us from being able to > resolve external internet domain names. It would be nice to have > recursion as a fallback, but it seems to go into that mode too often to be > useful in our split DNS situation. > >>> 2. We did some more network packet capture, and noticed that in forward >>> first mode, the FreeIPA server, always sent out both a forward request >>> to >>> the forwarding server, and an additional simultaneous request to the >>> root >>> name servers (recursive mode). It got back responses to both the >>> forwarded and recursive queries it had performed. The recursive query >>> failed due to split DNS and the forwarded query succeeded due to it >>> going >>> to an internal server which had the correct records. Strangely >>> enough... >>> the IPA server ignored the successful forwarded answer, and sent back >>> the >>> 'failed' answer it had gotten through recursion back to the requesting >>> client. What is the behavior supposed to be in this situation and why >>> is >>> the server always sending out the recursive request, even when it gets a >>> valid answer from the forwarded request? >> >> This is weird, but again - it can have multiple reasons. Do you see >> something >> in BIND logs? Does it e.g. complain about DNSSEC validation failures? >> >> Petr^2 Spacek >> > > Yes, we actually were getting DNSSEC validation failures. We had to > disable DNSSEC to get the forward only policy to work. With DNSSEC turned > on, forward only would not work because DNSSEC still tried to directly > contact root servers. It is very likely that this was caused by some misconfiguration in your DNS views. Could you share error messages from BIND logs? We could use them to improve detection logic so we can warn users early instead of tedious debugging. BTW what version if IPA do you use? We were adding checks to catch common misconfigurations to version 4.2. -- Petr Spacek @ Red Hat From guillem.liarte at googlemail.com Wed Oct 7 10:07:08 2015 From: guillem.liarte at googlemail.com (Guillem Liarte) Date: Wed, 7 Oct 2015 12:07:08 +0200 Subject: [Freeipa-users] Slow SSH login for IPA users only Message-ID: All, I have an IPA 4.1 installation that works perfectly. We just suffer from slow logins ( this is also slow in other operations such invoking SUDO ) IPA user: 1st. login: 30 seconds 2nd login: 8 seconds 3rd login: 6.5 seconds 4rth login: 20 seconds Local user: Consistently under 2 seconds In SSH have tried: Setting UseDNS to no Setting GSSAPIAuthentication to no I have tried various things that would work on an slow SSH, with no effect. In fact, local users have no problem. DNS both forward and reverse works well, works fast and gives consistent results. That is no the issue. While trying to find out more about the issue, I see that after the client has connected, it spends most of the time here: [...] debug2: input_userauth_pk_ok: fp e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx debug3: sign_and_send_pubkey: RSA e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx debug1: Authentication succeeded (publickey). [...] At first I though it might be the key retrival from the IPA service, but it is actually quite fast: time /usr/bin/sss_ssh_authorizedkeys testuser real 0m0.209s We have all the configration files just as they were after installing the ipa-client. The only modification was made to sshd_config as these two lines: AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser nobody I also tried removing the _srv_ in the ipa server line in sssd.conf, but that did not make any difference either. So, in brief: - SSH is fast for local users - authorized keys get retrieved quickly - no DNS issues. - IPA users take from 6 to 30 seconds to login (and also to perform sudo invocations) - While watching ssh logins, for ipa users, it takes a long time to pass these two: - input_userauth_pk_ok - sign_and_send_pubkey Could someone give me an idea of what to try next? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From canepa.n at mmfg.it Wed Oct 7 10:08:22 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Wed, 7 Oct 2015 12:08:22 +0200 Subject: [Freeipa-users] ACI for full replica Message-ID: <5614EF16.9040206@mmfg.it> Hello, I'm trying to replicate a subtree of the data from FreeIPA to a "foreign" LDAP server, by using LSC (http://lsc-project.org). The replication seems to work correctly, but I was unable to create an user (maybe even not visible from the web GUI) which could read userPassword field. Which ACI/Role/Group should I use for this purpose? Thank you for any hint: I did not find such information inside the documentation. Nicola -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. From alex.williams at brighter-technology.com Wed Oct 7 10:10:18 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Wed, 7 Oct 2015 11:10:18 +0100 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614EC85.8070904@redhat.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> Message-ID: <5614EF8A.2000504@brighter-technology.com> On 07/10/15 10:57, Martin Basti wrote: > > > On 10/07/2015 11:23 AM, Alex Williams wrote: >> On 07/10/15 09:53, Martin Basti wrote: >>> >>> >>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>> Hi guys, >>>> >>>> yesterday I finally managed to get our IPA3.0.0 servers in a state >>>> that I could upgrade the schema to dogtag 10, using the migration >>>> script and launched a new RHEL7.1 IPA4.1 server as a replica. >>>> Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old >>>> RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be >>>> our CRL master), I can no longer search for hosts or DNS entries, >>>> or host groups, either in the UI, or on the command line. >>>> >>>> They're there, they show up when you go to the hosts, dns or user >>>> page in a list, but you cannot then refine the search. This is also >>>> true of ipa host-find and ipa hostgroup-find on the command line. >>>> Is this a bug in IPA4.1? Is it a schema issue? Is it just because >>>> we still have an IPA3 server running the show and an IPA4 replica? >>>> I can't really justify dropping our production IPA3 servers, if >>>> searching for records doesn't work in IPA4.1. >>>> >>>> I still appear to be able to search in the UI of one of our other >>>> IPA3 servers, despite the fact it has had its schema updated and it >>>> has been connected to the new IPA4 server. >>>> >>>> Thanks in advance for any help anyone can offer. >>>> >>>> Cheers >>>> >>>> Alex >>>> >>> Hello, >>> >>> can you provide more info please: >>> >>> * are you kinited as admin user? >>> * does ipa dnszone-find returns all results? >>> * does ipa dnszone-find return something? >>> * does ipa dnszone-show return the zone? >>> >>> We had issue with access control, where non admin users cannot >>> search for zones, I'm not sure about hosts, and host groups. >>> I do not think that this is a schema upgrade issue nor related to >>> Dogtag 10. >>> >>> Martin >> >> Hi Martin, >> >> thanks for the quick response. So, I have not kinited as the admin >> user, however as root and as my own username (A member of the admins >> group in IPA), all of the commands you requested that I test, work >> fine. As it turns out, I can run all of the following on the command >> line, as my user, or as root and it all works fine. My colleague who >> attempted to do so this morning under his username, can do so if he >> kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? >> Unfortunately, my user still cannot search for hosts, hostgroups, or >> DNS entries within the UI. >> >> ipa user-find - returns a list of 100 users >> ipa user-find $username - returns the details of that user >> ipa host-find returns a list of 100 hosts >> ipa host-find $hostname - returns the details of the host >> ipa host-find $partial-hostname - returns a list of hosts which have >> the search string inside their hostname >> ipa hostgroup-find - returns a list of hostgroups >> ipa hostgroup-find $hostgroupname - returns details of the hostgroup >> >> Regards >> >> Alex > > If I understand correctly, you as admin group user, can search in CLI > and cannot search in webUI? That is weird. > > For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS > disallow some queries from user that are not in admin group. > > Martin Hi Martin, yes, that's exactly right, we seem to be able to search in the CLI, provided we're in the admin group, or kinit to the admin user. For some reason though, searching in the UI brings back nothing at all. It works ok for users, but not for hosts, hostgroups, or DNS entries. All of the entries are there, they are listed in full when you visit the respective page, but even searching for a full hostname doesn't work, let alone part of it. CLI is always an option obviously, but we don't really want everyone who uses this to have to use the CLI, just to search for a hostname or DNS entry. I've also verified that replication of things like hosts and DNS entries is working perfectly well between the IPA4 and IPA3 servers. If I add a new DNS entry in IPA3, it shows up immediately in IPA4 and I can then delete it in IPA4 and it's removed instantly from the IPA3 server. Cheers Alex From mbasti at redhat.com Wed Oct 7 10:28:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 12:28:55 +0200 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614EF8A.2000504@brighter-technology.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> <5614EF8A.2000504@brighter-technology.com> Message-ID: <5614F3E7.5050505@redhat.com> On 10/07/2015 12:10 PM, Alex Williams wrote: > On 07/10/15 10:57, Martin Basti wrote: >> >> >> On 10/07/2015 11:23 AM, Alex Williams wrote: >>> On 07/10/15 09:53, Martin Basti wrote: >>>> >>>> >>>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>>> Hi guys, >>>>> >>>>> yesterday I finally managed to get our IPA3.0.0 servers in a state >>>>> that I could upgrade the schema to dogtag 10, using the migration >>>>> script and launched a new RHEL7.1 IPA4.1 server as a replica. >>>>> Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old >>>>> RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be >>>>> our CRL master), I can no longer search for hosts or DNS entries, >>>>> or host groups, either in the UI, or on the command line. >>>>> >>>>> They're there, they show up when you go to the hosts, dns or user >>>>> page in a list, but you cannot then refine the search. This is >>>>> also true of ipa host-find and ipa hostgroup-find on the command >>>>> line. Is this a bug in IPA4.1? Is it a schema issue? Is it just >>>>> because we still have an IPA3 server running the show and an IPA4 >>>>> replica? I can't really justify dropping our production IPA3 >>>>> servers, if searching for records doesn't work in IPA4.1. >>>>> >>>>> I still appear to be able to search in the UI of one of our other >>>>> IPA3 servers, despite the fact it has had its schema updated and >>>>> it has been connected to the new IPA4 server. >>>>> >>>>> Thanks in advance for any help anyone can offer. >>>>> >>>>> Cheers >>>>> >>>>> Alex >>>>> >>>> Hello, >>>> >>>> can you provide more info please: >>>> >>>> * are you kinited as admin user? >>>> * does ipa dnszone-find returns all results? >>>> * does ipa dnszone-find return something? >>>> * does ipa dnszone-show return the zone? >>>> >>>> We had issue with access control, where non admin users cannot >>>> search for zones, I'm not sure about hosts, and host groups. >>>> I do not think that this is a schema upgrade issue nor related to >>>> Dogtag 10. >>>> >>>> Martin >>> >>> Hi Martin, >>> >>> thanks for the quick response. So, I have not kinited as the admin >>> user, however as root and as my own username (A member of the admins >>> group in IPA), all of the commands you requested that I test, work >>> fine. As it turns out, I can run all of the following on the command >>> line, as my user, or as root and it all works fine. My colleague who >>> attempted to do so this morning under his username, can do so if he >>> kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? >>> Unfortunately, my user still cannot search for hosts, hostgroups, or >>> DNS entries within the UI. >>> >>> ipa user-find - returns a list of 100 users >>> ipa user-find $username - returns the details of that user >>> ipa host-find returns a list of 100 hosts >>> ipa host-find $hostname - returns the details of the host >>> ipa host-find $partial-hostname - returns a list of hosts which have >>> the search string inside their hostname >>> ipa hostgroup-find - returns a list of hostgroups >>> ipa hostgroup-find $hostgroupname - returns details of the hostgroup >>> >>> Regards >>> >>> Alex >> >> If I understand correctly, you as admin group user, can search in CLI >> and cannot search in webUI? That is weird. >> >> For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS >> disallow some queries from user that are not in admin group. >> >> Martin > > Hi Martin, > > yes, that's exactly right, we seem to be able to search in the CLI, > provided we're in the admin group, or kinit to the admin user. For > some reason though, searching in the UI brings back nothing at all. It > works ok for users, but not for hosts, hostgroups, or DNS entries. All > of the entries are there, they are listed in full when you visit the > respective page, but even searching for a full hostname doesn't work, > let alone part of it. CLI is always an option obviously, but we don't > really want everyone who uses this to have to use the CLI, just to > search for a hostname or DNS entry. Please login in webUI as admin and try search, in this case search should work, if not, there is something broken. I found related tickets: https://fedorahosted.org/freeipa/ticket/5055 https://fedorahosted.org/freeipa/ticket/5130 But I found nothing about hosts and hostsgroup, I will prepare test environment and try. > > I've also verified that replication of things like hosts and DNS > entries is working perfectly well between the IPA4 and IPA3 servers. > If I add a new DNS entry in IPA3, it shows up immediately in IPA4 and > I can then delete it in IPA4 and it's removed instantly from the IPA3 > server. > > Cheers > > Alex > From mbasti at redhat.com Wed Oct 7 10:31:24 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 12:31:24 +0200 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614F3E7.5050505@redhat.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> <5614EF8A.2000504@brighter-technology.com> <5614F3E7.5050505@redhat.com> Message-ID: <5614F47C.5040300@redhat.com> On 10/07/2015 12:28 PM, Martin Basti wrote: > > > On 10/07/2015 12:10 PM, Alex Williams wrote: >> On 07/10/15 10:57, Martin Basti wrote: >>> >>> >>> On 10/07/2015 11:23 AM, Alex Williams wrote: >>>> On 07/10/15 09:53, Martin Basti wrote: >>>>> >>>>> >>>>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>>>> Hi guys, >>>>>> >>>>>> yesterday I finally managed to get our IPA3.0.0 servers in a >>>>>> state that I could upgrade the schema to dogtag 10, using the >>>>>> migration script and launched a new RHEL7.1 IPA4.1 server as a >>>>>> replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server AND >>>>>> the old RHEL6.6 IPA3.0.0 server that I replicated from (Also >>>>>> happens to be our CRL master), I can no longer search for hosts >>>>>> or DNS entries, or host groups, either in the UI, or on the >>>>>> command line. >>>>>> >>>>>> They're there, they show up when you go to the hosts, dns or user >>>>>> page in a list, but you cannot then refine the search. This is >>>>>> also true of ipa host-find and ipa hostgroup-find on the command >>>>>> line. Is this a bug in IPA4.1? Is it a schema issue? Is it just >>>>>> because we still have an IPA3 server running the show and an IPA4 >>>>>> replica? I can't really justify dropping our production IPA3 >>>>>> servers, if searching for records doesn't work in IPA4.1. >>>>>> >>>>>> I still appear to be able to search in the UI of one of our other >>>>>> IPA3 servers, despite the fact it has had its schema updated and >>>>>> it has been connected to the new IPA4 server. >>>>>> >>>>>> Thanks in advance for any help anyone can offer. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Alex >>>>>> >>>>> Hello, >>>>> >>>>> can you provide more info please: >>>>> >>>>> * are you kinited as admin user? >>>>> * does ipa dnszone-find returns all results? >>>>> * does ipa dnszone-find return something? >>>>> * does ipa dnszone-show return the zone? >>>>> >>>>> We had issue with access control, where non admin users cannot >>>>> search for zones, I'm not sure about hosts, and host groups. >>>>> I do not think that this is a schema upgrade issue nor related to >>>>> Dogtag 10. >>>>> >>>>> Martin >>>> >>>> Hi Martin, >>>> >>>> thanks for the quick response. So, I have not kinited as the admin >>>> user, however as root and as my own username (A member of the >>>> admins group in IPA), all of the commands you requested that I >>>> test, work fine. As it turns out, I can run all of the following on >>>> the command line, as my user, or as root and it all works fine. My >>>> colleague who attempted to do so this morning under his username, >>>> can do so if he kinits to admin. So I'm assuming the CLI bit, might >>>> be an ACL issue? Unfortunately, my user still cannot search for >>>> hosts, hostgroups, or DNS entries within the UI. >>>> >>>> ipa user-find - returns a list of 100 users >>>> ipa user-find $username - returns the details of that user >>>> ipa host-find returns a list of 100 hosts >>>> ipa host-find $hostname - returns the details of the host >>>> ipa host-find $partial-hostname - returns a list of hosts which >>>> have the search string inside their hostname >>>> ipa hostgroup-find - returns a list of hostgroups >>>> ipa hostgroup-find $hostgroupname - returns details of the hostgroup >>>> >>>> Regards >>>> >>>> Alex >>> >>> If I understand correctly, you as admin group user, can search in >>> CLI and cannot search in webUI? That is weird. >>> >>> For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS >>> disallow some queries from user that are not in admin group. >>> >>> Martin >> >> Hi Martin, >> >> yes, that's exactly right, we seem to be able to search in the CLI, >> provided we're in the admin group, or kinit to the admin user. For >> some reason though, searching in the UI brings back nothing at all. >> It works ok for users, but not for hosts, hostgroups, or DNS entries. >> All of the entries are there, they are listed in full when you visit >> the respective page, but even searching for a full hostname doesn't >> work, let alone part of it. CLI is always an option obviously, but we >> don't really want everyone who uses this to have to use the CLI, just >> to search for a hostname or DNS entry. > Please login in webUI as admin and try search, in this case search > should work, if not, there is something broken. > > I found related tickets: > https://fedorahosted.org/freeipa/ticket/5055 > https://fedorahosted.org/freeipa/ticket/5130 > > But I found nothing about hosts and hostsgroup, I will prepare test > environment and try. Nevermind, here is hosts/hostgroup/service/netgroup ticket https://fedorahosted.org/freeipa/ticket/5167 >> >> I've also verified that replication of things like hosts and DNS >> entries is working perfectly well between the IPA4 and IPA3 servers. >> If I add a new DNS entry in IPA3, it shows up immediately in IPA4 and >> I can then delete it in IPA4 and it's removed instantly from the IPA3 >> server. >> >> Cheers >> >> Alex >> > From mkosek at redhat.com Wed Oct 7 10:32:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 7 Oct 2015 12:32:39 +0200 Subject: [Freeipa-users] RedHat IdM Active Directory Integration In-Reply-To: <5614ED88.7070802@redhat.com> References: <5614ED88.7070802@redhat.com> Message-ID: <5614F4C7.6050407@redhat.com> On 10/07/2015 12:01 PM, Martin Kosek wrote: > On 10/06/2015 07:35 PM, Lesley Kimmel wrote: >> Hi all; >> >> I'm working an initiative to centralize user accounts in Active Directory. >> We have a large RHEL (6+) footprint and want to manage these as well. I am >> a Red Hat Engineer on the project and, while it is possible to integrate >> all of the RHEL clients directly to AD, I have a nagging feeling that using >> IdM as an intermediary would be a good approach. However, I have never >> implemented it and experienced the solidity of integration with AD so I >> can't formulate a solid argument at this point. >> >> My primary belief is that using IdM would allow for the Unix administrators >> better control over their environment. > > Yes, it would allow you easy control/integration for Linux based services, like > SUDO, automount and others. It may also save some costs, as if you join the > hosts directly to AD, you may need to pay the CLAs. BTW, Dmitri Pal also published a set of great blogs about IdM that can help you too: http://rhelblog.redhat.com/2015/05/27/direct-or-indirect-that-is-the-question/ ... aaand a related presentation: https://drive.google.com/file/d/0B3tfpNCVjJdCU1d3c0gzTE9pU2c/view?usp=sharing > >> However, even in that case we also >> have Satellite so we likely wouldn't use IdM for policy centralization. > > What policy do you have in mind right now, authorization? > >> I'm >> curious whether it is possible to store all user, group and system objects >> in Active Directory and then allow the configuration of host based access >> control policies from IdM using those AD objects. > > Yes, this should work with IdM external groups used in HBAC: > https://www.youtube.com/watch?v=sQnNFJOzwa8 > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html#about-hbac > >> That might be one >> argument for it. As an add-on to that question how is the HBAC actually >> implemented in IdM? It doesn't simply push down a policy for pam_access >> does it? > > HBAC is evaluated on the client (SSSD), i.e. that makes SSSD a requirement to > use HBAC. > >> >> Also, if users were configured with Smart Card information in AD could >> these users authenticate to Linux clients with IdM as an intermediary? > > This *may* work with the current Smart Card implementation in SSSD 1.13. It > should just work with IdM users and registered SC certificates out of the box, > for AD, some additional configuration will be required, Sumit will know more. > From sbose at redhat.com Wed Oct 7 10:35:57 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Oct 2015 12:35:57 +0200 Subject: [Freeipa-users] Slow SSH login for IPA users only In-Reply-To: References: Message-ID: <20151007103557.GH30474@p.redhat.com> On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote: > All, > > I have an IPA 4.1 installation that works perfectly. We just suffer from > slow logins ( this is also slow in other operations such invoking SUDO ) > > IPA user: > > 1st. login: 30 seconds > 2nd login: 8 seconds > 3rd login: 6.5 seconds > 4rth login: 20 seconds > > Local user: > > Consistently under 2 seconds > > In SSH have tried: > > Setting UseDNS to no > Setting GSSAPIAuthentication to no > > I have tried various things that would work on an slow SSH, with no effect. > In fact, local users have no problem. > > DNS both forward and reverse works well, works fast and gives consistent > results. That is no the issue. > > While trying to find out more about the issue, I see that after the client > has connected, it spends most of the time here: > > [...] > debug2: input_userauth_pk_ok: fp > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > debug3: sign_and_send_pubkey: RSA > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > debug1: Authentication succeeded (publickey). > [...] > > At first I though it might be the key retrival from the IPA service, but it > is actually quite fast: > > time /usr/bin/sss_ssh_authorizedkeys testuser > real 0m0.209s > > We have all the configration files just as they were after installing the > ipa-client. The only modification was made to sshd_config as these two > lines: > > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys > AuthorizedKeysCommandUser nobody > > I also tried removing the _srv_ in the ipa server line in sssd.conf, but > that did not make any difference either. > > So, in brief: > > - SSH is fast for local users > - authorized keys get retrieved quickly > - no DNS issues. > - IPA users take from 6 to 30 seconds to login (and also to perform sudo > invocations) > - While watching ssh logins, for ipa users, it takes a long time to pass > these two: > > - input_userauth_pk_ok > - sign_and_send_pubkey > > Could someone give me an idea of what to try next? Please check the SSSD logs especailly the ones for the domain. You might need to increase the debug_level, please see https://fedorahosted.org/sssd/wiki/Troubleshooting for details. bye, Sumit > > 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 From alex.williams at brighter-technology.com Wed Oct 7 11:26:43 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Wed, 7 Oct 2015 12:26:43 +0100 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <5614F47C.5040300@redhat.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> <5614EF8A.2000504@brighter-technology.com> <5614F3E7.5050505@redhat.com> <5614F47C.5040300@redhat.com> Message-ID: <56150173.10006@brighter-technology.com> On 07/10/15 11:31, Martin Basti wrote: > > > On 10/07/2015 12:28 PM, Martin Basti wrote: >> >> >> On 10/07/2015 12:10 PM, Alex Williams wrote: >>> On 07/10/15 10:57, Martin Basti wrote: >>>> >>>> >>>> On 10/07/2015 11:23 AM, Alex Williams wrote: >>>>> On 07/10/15 09:53, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> yesterday I finally managed to get our IPA3.0.0 servers in a >>>>>>> state that I could upgrade the schema to dogtag 10, using the >>>>>>> migration script and launched a new RHEL7.1 IPA4.1 server as a >>>>>>> replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server >>>>>>> AND the old RHEL6.6 IPA3.0.0 server that I replicated from (Also >>>>>>> happens to be our CRL master), I can no longer search for hosts >>>>>>> or DNS entries, or host groups, either in the UI, or on the >>>>>>> command line. >>>>>>> >>>>>>> They're there, they show up when you go to the hosts, dns or >>>>>>> user page in a list, but you cannot then refine the search. This >>>>>>> is also true of ipa host-find and ipa hostgroup-find on the >>>>>>> command line. Is this a bug in IPA4.1? Is it a schema issue? Is >>>>>>> it just because we still have an IPA3 server running the show >>>>>>> and an IPA4 replica? I can't really justify dropping our >>>>>>> production IPA3 servers, if searching for records doesn't work >>>>>>> in IPA4.1. >>>>>>> >>>>>>> I still appear to be able to search in the UI of one of our >>>>>>> other IPA3 servers, despite the fact it has had its schema >>>>>>> updated and it has been connected to the new IPA4 server. >>>>>>> >>>>>>> Thanks in advance for any help anyone can offer. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Alex >>>>>>> >>>>>> Hello, >>>>>> >>>>>> can you provide more info please: >>>>>> >>>>>> * are you kinited as admin user? >>>>>> * does ipa dnszone-find returns all results? >>>>>> * does ipa dnszone-find return something? >>>>>> * does ipa dnszone-show return the zone? >>>>>> >>>>>> We had issue with access control, where non admin users cannot >>>>>> search for zones, I'm not sure about hosts, and host groups. >>>>>> I do not think that this is a schema upgrade issue nor related to >>>>>> Dogtag 10. >>>>>> >>>>>> Martin >>>>> >>>>> Hi Martin, >>>>> >>>>> thanks for the quick response. So, I have not kinited as the admin >>>>> user, however as root and as my own username (A member of the >>>>> admins group in IPA), all of the commands you requested that I >>>>> test, work fine. As it turns out, I can run all of the following >>>>> on the command line, as my user, or as root and it all works fine. >>>>> My colleague who attempted to do so this morning under his >>>>> username, can do so if he kinits to admin. So I'm assuming the CLI >>>>> bit, might be an ACL issue? Unfortunately, my user still cannot >>>>> search for hosts, hostgroups, or DNS entries within the UI. >>>>> >>>>> ipa user-find - returns a list of 100 users >>>>> ipa user-find $username - returns the details of that user >>>>> ipa host-find returns a list of 100 hosts >>>>> ipa host-find $hostname - returns the details of the host >>>>> ipa host-find $partial-hostname - returns a list of hosts which >>>>> have the search string inside their hostname >>>>> ipa hostgroup-find - returns a list of hostgroups >>>>> ipa hostgroup-find $hostgroupname - returns details of the hostgroup >>>>> >>>>> Regards >>>>> >>>>> Alex >>>> >>>> If I understand correctly, you as admin group user, can search in >>>> CLI and cannot search in webUI? That is weird. >>>> >>>> For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS >>>> disallow some queries from user that are not in admin group. >>>> >>>> Martin >>> >>> Hi Martin, >>> >>> yes, that's exactly right, we seem to be able to search in the CLI, >>> provided we're in the admin group, or kinit to the admin user. For >>> some reason though, searching in the UI brings back nothing at all. >>> It works ok for users, but not for hosts, hostgroups, or DNS >>> entries. All of the entries are there, they are listed in full when >>> you visit the respective page, but even searching for a full >>> hostname doesn't work, let alone part of it. CLI is always an option >>> obviously, but we don't really want everyone who uses this to have >>> to use the CLI, just to search for a hostname or DNS entry. >> Please login in webUI as admin and try search, in this case search >> should work, if not, there is something broken. >> >> I found related tickets: >> https://fedorahosted.org/freeipa/ticket/5055 >> https://fedorahosted.org/freeipa/ticket/5130 >> >> But I found nothing about hosts and hostsgroup, I will prepare test >> environment and try. > Nevermind, here is hosts/hostgroup/service/netgroup ticket > https://fedorahosted.org/freeipa/ticket/5167 >>> >>> I've also verified that replication of things like hosts and DNS >>> entries is working perfectly well between the IPA4 and IPA3 servers. >>> If I add a new DNS entry in IPA3, it shows up immediately in IPA4 >>> and I can then delete it in IPA4 and it's removed instantly from the >>> IPA3 server. >>> >>> Cheers >>> >>> Alex >>> >> > Hi Martin, thanks for that, that does in fact seem to be the issue. As per your instructions, logging in as 'admin' to the UI, allows the search feature to work. That does beg the question as to how my user can use its kerberos ticket on the CLI, but not in the UI though? Either way, the fix for the issue looks to be trivial (Replacing a few python files by the looks of things), so I'll give that a go and at worst, I guess we may have to wait until RHEL7.2 becomes a release and we'll upgrade to that. Cheers Alex From mbasti at redhat.com Wed Oct 7 11:40:57 2015 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Oct 2015 13:40:57 +0200 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <56150173.10006@brighter-technology.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> <5614EF8A.2000504@brighter-technology.com> <5614F3E7.5050505@redhat.com> <5614F47C.5040300@redhat.com> <56150173.10006@brighter-technology.com> Message-ID: <561504C9.20702@redhat.com> On 10/07/2015 01:26 PM, Alex Williams wrote: > On 07/10/15 11:31, Martin Basti wrote: >> >> >> On 10/07/2015 12:28 PM, Martin Basti wrote: >>> >>> >>> On 10/07/2015 12:10 PM, Alex Williams wrote: >>>> On 07/10/15 10:57, Martin Basti wrote: >>>>> >>>>> >>>>> On 10/07/2015 11:23 AM, Alex Williams wrote: >>>>>> On 07/10/15 09:53, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> yesterday I finally managed to get our IPA3.0.0 servers in a >>>>>>>> state that I could upgrade the schema to dogtag 10, using the >>>>>>>> migration script and launched a new RHEL7.1 IPA4.1 server as a >>>>>>>> replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server >>>>>>>> AND the old RHEL6.6 IPA3.0.0 server that I replicated from >>>>>>>> (Also happens to be our CRL master), I can no longer search for >>>>>>>> hosts or DNS entries, or host groups, either in the UI, or on >>>>>>>> the command line. >>>>>>>> >>>>>>>> They're there, they show up when you go to the hosts, dns or >>>>>>>> user page in a list, but you cannot then refine the search. >>>>>>>> This is also true of ipa host-find and ipa hostgroup-find on >>>>>>>> the command line. Is this a bug in IPA4.1? Is it a schema >>>>>>>> issue? Is it just because we still have an IPA3 server running >>>>>>>> the show and an IPA4 replica? I can't really justify dropping >>>>>>>> our production IPA3 servers, if searching for records doesn't >>>>>>>> work in IPA4.1. >>>>>>>> >>>>>>>> I still appear to be able to search in the UI of one of our >>>>>>>> other IPA3 servers, despite the fact it has had its schema >>>>>>>> updated and it has been connected to the new IPA4 server. >>>>>>>> >>>>>>>> Thanks in advance for any help anyone can offer. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> can you provide more info please: >>>>>>> >>>>>>> * are you kinited as admin user? >>>>>>> * does ipa dnszone-find returns all results? >>>>>>> * does ipa dnszone-find return something? >>>>>>> * does ipa dnszone-show return the zone? >>>>>>> >>>>>>> We had issue with access control, where non admin users cannot >>>>>>> search for zones, I'm not sure about hosts, and host groups. >>>>>>> I do not think that this is a schema upgrade issue nor related >>>>>>> to Dogtag 10. >>>>>>> >>>>>>> Martin >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> thanks for the quick response. So, I have not kinited as the >>>>>> admin user, however as root and as my own username (A member of >>>>>> the admins group in IPA), all of the commands you requested that >>>>>> I test, work fine. As it turns out, I can run all of the >>>>>> following on the command line, as my user, or as root and it all >>>>>> works fine. My colleague who attempted to do so this morning >>>>>> under his username, can do so if he kinits to admin. So I'm >>>>>> assuming the CLI bit, might be an ACL issue? Unfortunately, my >>>>>> user still cannot search for hosts, hostgroups, or DNS entries >>>>>> within the UI. >>>>>> >>>>>> ipa user-find - returns a list of 100 users >>>>>> ipa user-find $username - returns the details of that user >>>>>> ipa host-find returns a list of 100 hosts >>>>>> ipa host-find $hostname - returns the details of the host >>>>>> ipa host-find $partial-hostname - returns a list of hosts which >>>>>> have the search string inside their hostname >>>>>> ipa hostgroup-find - returns a list of hostgroups >>>>>> ipa hostgroup-find $hostgroupname - returns details of the hostgroup >>>>>> >>>>>> Regards >>>>>> >>>>>> Alex >>>>> >>>>> If I understand correctly, you as admin group user, can search in >>>>> CLI and cannot search in webUI? That is weird. >>>>> >>>>> For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS >>>>> disallow some queries from user that are not in admin group. >>>>> >>>>> Martin >>>> >>>> Hi Martin, >>>> >>>> yes, that's exactly right, we seem to be able to search in the CLI, >>>> provided we're in the admin group, or kinit to the admin user. For >>>> some reason though, searching in the UI brings back nothing at all. >>>> It works ok for users, but not for hosts, hostgroups, or DNS >>>> entries. All of the entries are there, they are listed in full when >>>> you visit the respective page, but even searching for a full >>>> hostname doesn't work, let alone part of it. CLI is always an >>>> option obviously, but we don't really want everyone who uses this >>>> to have to use the CLI, just to search for a hostname or DNS entry. >>> Please login in webUI as admin and try search, in this case search >>> should work, if not, there is something broken. >>> >>> I found related tickets: >>> https://fedorahosted.org/freeipa/ticket/5055 >>> https://fedorahosted.org/freeipa/ticket/5130 >>> >>> But I found nothing about hosts and hostsgroup, I will prepare test >>> environment and try. >> Nevermind, here is hosts/hostgroup/service/netgroup ticket >> https://fedorahosted.org/freeipa/ticket/5167 >>>> >>>> I've also verified that replication of things like hosts and DNS >>>> entries is working perfectly well between the IPA4 and IPA3 >>>> servers. If I add a new DNS entry in IPA3, it shows up immediately >>>> in IPA4 and I can then delete it in IPA4 and it's removed instantly >>>> from the IPA3 server. >>>> >>>> Cheers >>>> >>>> Alex >>>> >>> >> > > > Hi Martin, > > thanks for that, that does in fact seem to be the issue. As per your > instructions, logging in as 'admin' to the UI, allows the search > feature to work. That does beg the question as to how my user can use > its kerberos ticket on the CLI, but not in the UI though? Either way, > the fix for the issue looks to be trivial (Replacing a few python > files by the looks of things), so I'll give that a go and at worst, I > guess we may have to wait until RHEL7.2 becomes a release and we'll > upgrade to that. > > Cheers > > Alex > > > I see you have RHEL, please contact customer support, they may help you, don't do hotfixing by yourself. Please share the tickets and information listed in this thread with them. They may: * approve hotfix for you * or do z-stream release which will fix this * or something else, I do not know I do not understand what you mean by kerberos and webUI. WebUI uses the same commands as CLI, what does not work in CLI will not work in WebUI and vice versa. Also webUI do not need kerberos, there is also form based authentication (username/password) Martin From alex.williams at brighter-technology.com Wed Oct 7 11:47:15 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Wed, 7 Oct 2015 12:47:15 +0100 Subject: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10 In-Reply-To: <561504C9.20702@redhat.com> References: <5614CEA5.9040406@brighter-technology.com> <5614DD84.7030904@redhat.com> <5614E486.5090609@brighter-technology.com> <5614EC85.8070904@redhat.com> <5614EF8A.2000504@brighter-technology.com> <5614F3E7.5050505@redhat.com> <5614F47C.5040300@redhat.com> <56150173.10006@brighter-technology.com> <561504C9.20702@redhat.com> Message-ID: <56150643.5090000@brighter-technology.com> On 07/10/15 12:40, Martin Basti wrote: > > > On 10/07/2015 01:26 PM, Alex Williams wrote: >> On 07/10/15 11:31, Martin Basti wrote: >>> >>> >>> On 10/07/2015 12:28 PM, Martin Basti wrote: >>>> >>>> >>>> On 10/07/2015 12:10 PM, Alex Williams wrote: >>>>> On 07/10/15 10:57, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 10/07/2015 11:23 AM, Alex Williams wrote: >>>>>>> On 07/10/15 09:53, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 10/07/2015 09:49 AM, Alex Williams wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> yesterday I finally managed to get our IPA3.0.0 servers in a >>>>>>>>> state that I could upgrade the schema to dogtag 10, using the >>>>>>>>> migration script and launched a new RHEL7.1 IPA4.1 server as a >>>>>>>>> replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server >>>>>>>>> AND the old RHEL6.6 IPA3.0.0 server that I replicated from >>>>>>>>> (Also happens to be our CRL master), I can no longer search >>>>>>>>> for hosts or DNS entries, or host groups, either in the UI, or >>>>>>>>> on the command line. >>>>>>>>> >>>>>>>>> They're there, they show up when you go to the hosts, dns or >>>>>>>>> user page in a list, but you cannot then refine the search. >>>>>>>>> This is also true of ipa host-find and ipa hostgroup-find on >>>>>>>>> the command line. Is this a bug in IPA4.1? Is it a schema >>>>>>>>> issue? Is it just because we still have an IPA3 server running >>>>>>>>> the show and an IPA4 replica? I can't really justify dropping >>>>>>>>> our production IPA3 servers, if searching for records doesn't >>>>>>>>> work in IPA4.1. >>>>>>>>> >>>>>>>>> I still appear to be able to search in the UI of one of our >>>>>>>>> other IPA3 servers, despite the fact it has had its schema >>>>>>>>> updated and it has been connected to the new IPA4 server. >>>>>>>>> >>>>>>>>> Thanks in advance for any help anyone can offer. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> can you provide more info please: >>>>>>>> >>>>>>>> * are you kinited as admin user? >>>>>>>> * does ipa dnszone-find returns all results? >>>>>>>> * does ipa dnszone-find return something? >>>>>>>> * does ipa dnszone-show return the zone? >>>>>>>> >>>>>>>> We had issue with access control, where non admin users cannot >>>>>>>> search for zones, I'm not sure about hosts, and host groups. >>>>>>>> I do not think that this is a schema upgrade issue nor related >>>>>>>> to Dogtag 10. >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> thanks for the quick response. So, I have not kinited as the >>>>>>> admin user, however as root and as my own username (A member of >>>>>>> the admins group in IPA), all of the commands you requested that >>>>>>> I test, work fine. As it turns out, I can run all of the >>>>>>> following on the command line, as my user, or as root and it all >>>>>>> works fine. My colleague who attempted to do so this morning >>>>>>> under his username, can do so if he kinits to admin. So I'm >>>>>>> assuming the CLI bit, might be an ACL issue? Unfortunately, my >>>>>>> user still cannot search for hosts, hostgroups, or DNS entries >>>>>>> within the UI. >>>>>>> >>>>>>> ipa user-find - returns a list of 100 users >>>>>>> ipa user-find $username - returns the details of that user >>>>>>> ipa host-find returns a list of 100 hosts >>>>>>> ipa host-find $hostname - returns the details of the host >>>>>>> ipa host-find $partial-hostname - returns a list of hosts which >>>>>>> have the search string inside their hostname >>>>>>> ipa hostgroup-find - returns a list of hostgroups >>>>>>> ipa hostgroup-find $hostgroupname - returns details of the >>>>>>> hostgroup >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Alex >>>>>> >>>>>> If I understand correctly, you as admin group user, can search in >>>>>> CLI and cannot search in webUI? That is weird. >>>>>> >>>>>> For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS >>>>>> disallow some queries from user that are not in admin group. >>>>>> >>>>>> Martin >>>>> >>>>> Hi Martin, >>>>> >>>>> yes, that's exactly right, we seem to be able to search in the >>>>> CLI, provided we're in the admin group, or kinit to the admin >>>>> user. For some reason though, searching in the UI brings back >>>>> nothing at all. It works ok for users, but not for hosts, >>>>> hostgroups, or DNS entries. All of the entries are there, they are >>>>> listed in full when you visit the respective page, but even >>>>> searching for a full hostname doesn't work, let alone part of it. >>>>> CLI is always an option obviously, but we don't really want >>>>> everyone who uses this to have to use the CLI, just to search for >>>>> a hostname or DNS entry. >>>> Please login in webUI as admin and try search, in this case search >>>> should work, if not, there is something broken. >>>> >>>> I found related tickets: >>>> https://fedorahosted.org/freeipa/ticket/5055 >>>> https://fedorahosted.org/freeipa/ticket/5130 >>>> >>>> But I found nothing about hosts and hostsgroup, I will prepare test >>>> environment and try. >>> Nevermind, here is hosts/hostgroup/service/netgroup ticket >>> https://fedorahosted.org/freeipa/ticket/5167 >>>>> >>>>> I've also verified that replication of things like hosts and DNS >>>>> entries is working perfectly well between the IPA4 and IPA3 >>>>> servers. If I add a new DNS entry in IPA3, it shows up immediately >>>>> in IPA4 and I can then delete it in IPA4 and it's removed >>>>> instantly from the IPA3 server. >>>>> >>>>> Cheers >>>>> >>>>> Alex >>>>> >>>> >>> >> >> >> Hi Martin, >> >> thanks for that, that does in fact seem to be the issue. As per your >> instructions, logging in as 'admin' to the UI, allows the search >> feature to work. That does beg the question as to how my user can use >> its kerberos ticket on the CLI, but not in the UI though? Either way, >> the fix for the issue looks to be trivial (Replacing a few python >> files by the looks of things), so I'll give that a go and at worst, I >> guess we may have to wait until RHEL7.2 becomes a release and we'll >> upgrade to that. >> >> Cheers >> >> Alex >> >> >> > I see you have RHEL, please contact customer support, they may help > you, don't do hotfixing by yourself. > Please share the tickets and information listed in this thread with them. > They may: > * approve hotfix for you > * or do z-stream release which will fix this > * or something else, I do not know > > I do not understand what you mean by kerberos and webUI. WebUI uses > the same commands as CLI, what does not work in CLI will not work in > WebUI and vice versa. Also webUI do not need kerberos, there is also > form based authentication (username/password) > > Martin Hi Martin, thanks, I do have a ticket open with RHEL, but in all honesty, I tend to find they just don't answer very quickly at all through the support portal and it's much faster to find answers to these issues by speaking to you guys. The last issue I had, was in creating a replica of my existing IPA3 server, it took support 3 days, just to ask me for clarification on what I meant. Meanwhile, I fixed it by staying up late and talking to the PKI guys on IRC in the USA, who not only told me what my problem was, but created a new freeipa document, to back it up as well and make sure future users with the same issue can refer to it. I'll point support at this thread and see what they come up with. Thanks again for your help. Kind Regards Alex From tbordaz at redhat.com Wed Oct 7 13:25:50 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 07 Oct 2015 15:25:50 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <5614E389.4010001@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> <5614E389.4010001@redhat.com> Message-ID: <56151D5E.2040102@redhat.com> On 10/07/2015 11:19 AM, Martin Kosek wrote: > On 10/05/2015 02:13 PM, Dominik Korittki wrote: >> >> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >>> Dominik Korittki wrote: >>>> Hello folks, >>>> >>>> I am running two FreeIPA Servers with around 100 users and around 15.000 >>>> hosts, which are used by users to login via ssh. The FreeIPA servers >>>> (which are Centos 7.0) ran good for a while, but as more and more hosts >>>> got migrated to serve as FreeIPA hosts, it started to get slow and >>>> unstable. >>>> >>>> For example, its hard to maintain hostgroups, which have more than 1.000 >>>> hosts. The ipa host-* commands are getting slower as the hostgroup >>>> grows. Is this normal? >>> You mean the ipa hostgroup-* commands? Whenever the entry is displayed >>> (show and add) it needs to dereference all members so yes, it is >>> understandable that it gets somewhat slower with more members. How slow >>> are we talking about? >>> >>>> We also experience random dirsrv segfaults. Here's a dmesg line from the >>>> latest: >>>> >>>> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1 >>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >>> You probably want to start here: >>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >> A stacktrace from the latest crash is attached to this email. After restarting >> the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors >> (hostname is ipa01.internal): > Ludwig or Thierry, can you please take a look at the stack and file 389-DS > ticket if appropriate? Hello Dominik, DS is crashing during a BIND and from the arguments values we can guess it was due to a heap corruption that corrupted it operation pblock. This bind operation was likely victim of the heap corruption more than responsible of it. Using valgrind is the best way to track such problem but as you already suffer from bad performance I doubt it would be acceptable. How frequently does it crash ? did you identify a kind of test case ? thanks thierry >> [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All Interfaces port >> 389 for LDAP requests >> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for LDAPS >> requests >> [05/Oct/2015:13:51:30 +0200] - Listening on /var/run/slapd-INTERNAL.socket for >> LDAPI requests >> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: could >> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local >> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (No Kerberos credentials available)) >> errno 0 (Success) >> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local >> error) >> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth >> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information (No Kerberos >> credentials available)) >> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program - >> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN >> 54bea480000000600000 not found, we aren't as up to date, or we purged >> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data required >> to update replica has been purged. The replica must be reinitialized. >> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Incremental >> update failed and requires administrator action >> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - >> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth >> resumed >> >> >> These lines are present since a replayed a ldif dump from ipa02 to ipa01, but i >> didn't think that it related to the segfault problem (therefore i said there >> are no related problems in the logfile). >> >> But I am starting to believe that these errors could be in relation to each other. >> >> >> Kind regards, >> Dominik Korittki >> >> >>> >>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >>>> problem. >> Not sure about that anymore. >> >>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that >>>> solve my problems? >>>> >>>> FreeIPA server version is 3.3.3-28.el7.centos >>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>>> >>>> >>>> >>>> Kind regards, >>>> Dominik Korittki >>>> >>> >>> >>> >> From rcritten at redhat.com Wed Oct 7 13:51:46 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2015 09:51:46 -0400 Subject: [Freeipa-users] ACI for full replica In-Reply-To: <5614EF16.9040206@mmfg.it> References: <5614EF16.9040206@mmfg.it> Message-ID: <56152372.9030609@redhat.com> Nicola Canepa wrote: > Hello, I'm trying to replicate a subtree of the data from FreeIPA to a > "foreign" LDAP server, by using LSC (http://lsc-project.org). > The replication seems to work correctly, but I was unable to create an > user (maybe even not visible from the web GUI) which could read > userPassword field. > Which ACI/Role/Group should I use for this purpose? > > Thank you for any hint: I did not find such information inside the > documentation. Depending on the type of bind user you're using you'd need to add your own permission or ACI to grant read on userPassword. I'd tread very carefully here and triple check that the ACI does only what you need and doesn't otherwise leak data, and especially watch those who can assign roles to avoid accidental disclosure. rob From rcritten at redhat.com Wed Oct 7 14:24:28 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2015 10:24:28 -0400 Subject: [Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki In-Reply-To: <791274AA-7856-4E48-B8D5-D665E6FE5490@kofeina.net> References: <791274AA-7856-4E48-B8D5-D665E6FE5490@kofeina.net> Message-ID: <56152B1C.8000004@redhat.com> ?ukasz Jaworski wrote: > Hi, > > I have problem with setup new replicas. > I tried setup two replicas, both failed with the same error. > > environment: > Fedora 21 > > packages: > freeipa-server-4.1.3-2.fc21.x86_64 > 389-ds-base-1.3.3.8-1.fc21.x86_64 > 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 > pki-server-10.2.0-5.fc21.noarch > > same on server and replicas > > > Output from ipa-replica-install: > (?) > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/22]: creating certificate server user > [2/22]: configuring certificate server instance > [3/22]: stopping certificate server instance to update CS.cfg > [4/22]: backing up CS.cfg > [5/22]: disabling nonces > [6/22]: set up CRL publishing > [7/22]: enable PKIX certificate path discovery and validation > [8/22]: starting certificate server instance > [error] RuntimeError: CA did not start in 300.0s > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > >>From /var/log/ipareplica.log > 2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted > 2015-10-07T06:25:58Z DEBUG Waiting for CA to start... > 2015-10-07T06:25:59Z DEBUG Starting external process > 2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' 'https://182.example.com:8443/ca/admin/c > a/getStatus' > 2015-10-07T06:25:59Z DEBUG Process finished, return code=8 > 2015-10-07T06:25:59Z DEBUG stdout= > 2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59-- https://182.example.com:8443/ca/admin/ca/getStatus > Resolving 182.example.com (182.example.com)... xx.xx.xx.xx > Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... connected. > WARNING: cannot verify 182.example.com's certificate, issued by ?CN=Certificate Authority,O=ecample.com?: > Self-signed certificate encountered. > HTTP request sent, awaiting response... > HTTP/1.1 500 Internal Server Error > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=utf-8 > Content-Language: en > Content-Length: 2923 > Date: Wed, 07 Oct 2015 06:25:59 GMT > Connection: close > 2015-10-07 08:25:59 ERROR 500: Internal Server Error. > > Any idea? > You'll need to check the dogtag logs for errors. Start with /var/log/pki/pki-tomcat/ca/debug rob From d.korittki at mittwald.de Wed Oct 7 15:03:45 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Wed, 7 Oct 2015 17:03:45 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <56151D5E.2040102@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> <5614E389.4010001@redhat.com> <56151D5E.2040102@redhat.com> Message-ID: <56153451.2030308@mittwald.de> Am 07.10.2015 um 15:25 schrieb thierry bordaz: > On 10/07/2015 11:19 AM, Martin Kosek wrote: >> On 10/05/2015 02:13 PM, Dominik Korittki wrote: >>> >>> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >>>> Dominik Korittki wrote: >>>>> Hello folks, >>>>> >>>>> I am running two FreeIPA Servers with around 100 users and around >>>>> 15.000 >>>>> hosts, which are used by users to login via ssh. The FreeIPA servers >>>>> (which are Centos 7.0) ran good for a while, but as more and more >>>>> hosts >>>>> got migrated to serve as FreeIPA hosts, it started to get slow and >>>>> unstable. >>>>> >>>>> For example, its hard to maintain hostgroups, which have more than >>>>> 1.000 >>>>> hosts. The ipa host-* commands are getting slower as the hostgroup >>>>> grows. Is this normal? >>>> You mean the ipa hostgroup-* commands? Whenever the entry is displayed >>>> (show and add) it needs to dereference all members so yes, it is >>>> understandable that it gets somewhat slower with more members. How slow >>>> are we talking about? >>>> >>>>> We also experience random dirsrv segfaults. Here's a dmesg line >>>>> from the >>>>> latest: >>>>> >>>>> [690787.647261] traps: ns-slapd[5217] general protection >>>>> ip:7f8d6b6d6bc1 >>>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >>>> You probably want to start here: >>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >>> A stacktrace from the latest crash is attached to this email. After >>> restarting >>> the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors >>> (hostname is ipa01.internal): >> Ludwig or Thierry, can you please take a look at the stack and file >> 389-DS >> ticket if appropriate? > > Hello Dominik, > > DS is crashing during a BIND and from the arguments values we can guess > it was due to a heap corruption that corrupted it operation pblock. > This bind operation was likely victim of the heap corruption more than > responsible of it. > > Using valgrind is the best way to track such problem but as you already > suffer from bad performance I doubt it would be acceptable. > How frequently does it crash ? did you identify a kind of test case ? At first the crashes happenend at a daily basis. Simply restarting the dirsrv daemon resolved the issue for another day but later on the daemon did not survive more than 15 minutes most of the time. There were exceptions though. Sometimes the daemon ran for several hours until it chrashed. I did not really identify a testcase. However, I supposed it could have something to do with replication, as I have seen replication related errors in dirsrv error log (mentioned in an earlier mail in this topic). So did the following: ipa01 has a replication agreement with ipa02. ipa01 was the one with segfaults. I removed ipa01 from the replication agreement (ipa-replica-manage del), did an ipa-server-install --uninstall on ipa01 and created ipa01 as a replica of ipa02. Since then I did not experience any crashes (for now). Instead i'm having trouble rebuilding a clean replication agreement (old RUV stuff still in database), but thats another story I will eventually post on the mailinglist as a new topic. As for valgrind: Never used it before. Is there a handy explanation of how to use it in combination with 389ds? If I still experience those crashes and I get it managed to use I could try it out. Kind regards, Dominik Korittki > > thanks > thierry >>> [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All >>> Interfaces port >>> 389 for LDAP requests >>> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 >>> for LDAPS >>> requests >>> [05/Oct/2015:13:51:30 +0200] - Listening on >>> /var/run/slapd-INTERNAL.socket for >>> LDAPI requests >>> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - >>> Error: could >>> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 >>> (Local >>> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS >>> failure. >>> Minor code may provide more information (No Kerberos credentials >>> available)) >>> errno 0 (Success) >>> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform >>> interactive bind for id [] authentication mechanism [GSSAPI]: error >>> -2 (Local >>> error) >>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>> GSSAPI auth >>> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>> GSSAPI Error: >>> Unspecified GSS failure. Minor code may provide more information (No >>> Kerberos >>> credentials available)) >>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program - >>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN >>> 54bea480000000600000 not found, we aren't as up to date, or we purged >>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>> Data required >>> to update replica has been purged. The replica must be reinitialized. >>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>> Incremental >>> update failed and requires administrator action >>> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - >>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>> GSSAPI auth >>> resumed >>> >>> >>> These lines are present since a replayed a ldif dump from ipa02 to >>> ipa01, but i >>> didn't think that it related to the segfault problem (therefore i >>> said there >>> are no related problems in the logfile). >>> >>> But I am starting to believe that these errors could be in relation >>> to each other. >>> >>> >>> Kind regards, >>> Dominik Korittki >>> >>> >>>> >>>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the >>>>> problem. >>> Not sure about that anymore. >>> >>>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does >>>>> that >>>>> solve my problems? >>>>> >>>>> FreeIPA server version is 3.3.3-28.el7.centos >>>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> Dominik Korittki >>>>> >>>> >>>> >>>> >>> > > > > -- Mittwald CM Service GmbH & Co KG K?nigsberger Stra?e 6 32339 Espelkamp Tel: +49(0)5772-293-100 Fax: +49(0)5772-293-333 Gesch?ftsf?hrer: Robert Meyer HRA 6640, AG Bad Oeynhausen Komplementaerin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen From tbordaz at redhat.com Wed Oct 7 15:30:07 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 07 Oct 2015 17:30:07 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <56153451.2030308@mittwald.de> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> <5614E389.4010001@redhat.com> <56151D5E.2040102@redhat.com> <56153451.2030308@mittwald.de> Message-ID: <56153A7F.1080103@redhat.com> On 10/07/2015 05:03 PM, Dominik Korittki wrote: > > > Am 07.10.2015 um 15:25 schrieb thierry bordaz: >> On 10/07/2015 11:19 AM, Martin Kosek wrote: >>> On 10/05/2015 02:13 PM, Dominik Korittki wrote: >>>> >>>> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >>>>> Dominik Korittki wrote: >>>>>> Hello folks, >>>>>> >>>>>> I am running two FreeIPA Servers with around 100 users and around >>>>>> 15.000 >>>>>> hosts, which are used by users to login via ssh. The FreeIPA servers >>>>>> (which are Centos 7.0) ran good for a while, but as more and more >>>>>> hosts >>>>>> got migrated to serve as FreeIPA hosts, it started to get slow and >>>>>> unstable. >>>>>> >>>>>> For example, its hard to maintain hostgroups, which have more than >>>>>> 1.000 >>>>>> hosts. The ipa host-* commands are getting slower as the hostgroup >>>>>> grows. Is this normal? >>>>> You mean the ipa hostgroup-* commands? Whenever the entry is >>>>> displayed >>>>> (show and add) it needs to dereference all members so yes, it is >>>>> understandable that it gets somewhat slower with more members. How >>>>> slow >>>>> are we talking about? >>>>> >>>>>> We also experience random dirsrv segfaults. Here's a dmesg line >>>>>> from the >>>>>> latest: >>>>>> >>>>>> [690787.647261] traps: ns-slapd[5217] general protection >>>>>> ip:7f8d6b6d6bc1 >>>>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >>>>> You probably want to start here: >>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >>>> A stacktrace from the latest crash is attached to this email. After >>>> restarting >>>> the service, this is what I get in >>>> /var/log/dirsrv/slapd-INTERNAL/errors >>>> (hostname is ipa01.internal): >>> Ludwig or Thierry, can you please take a look at the stack and file >>> 389-DS >>> ticket if appropriate? >> >> Hello Dominik, >> >> DS is crashing during a BIND and from the arguments values we can guess >> it was due to a heap corruption that corrupted it operation pblock. >> This bind operation was likely victim of the heap corruption more than >> responsible of it. >> >> Using valgrind is the best way to track such problem but as you already >> suffer from bad performance I doubt it would be acceptable. >> How frequently does it crash ? did you identify a kind of test case ? > > At first the crashes happenend at a daily basis. Simply restarting the > dirsrv daemon resolved the issue for another day but later on the > daemon did not survive more than 15 minutes most of the time. There > were exceptions though. Sometimes the daemon ran for several hours > until it chrashed. > I did not really identify a testcase. However, I supposed it could > have something to do with replication, as I have seen replication > related errors in dirsrv error log (mentioned in an earlier mail in > this topic). heap corruption are usually dynamic and if the server became more and more slow, it could change the dynamic in favor of heap corruption. > > So did the following: > ipa01 has a replication agreement with ipa02. ipa01 was the one with > segfaults. I removed ipa01 from the replication agreement > (ipa-replica-manage del), did an ipa-server-install --uninstall on > ipa01 and created ipa01 as a replica of ipa02. Since then I did not > experience any crashes (for now). > Instead i'm having trouble rebuilding a clean replication agreement > (old RUV stuff still in database), but thats another story I will > eventually post on the mailinglist as a new topic. > > As for valgrind: Never used it before. Is there a handy explanation of > how to use it in combination with 389ds? If I still experience those > crashes and I get it managed to use I could try it out. You may follow this procedure http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind (but remove --leak-check=yes because this is not a leak issue) thanks thierry > > > Kind regards, > Dominik Korittki > >> >> thanks >> thierry >>>> [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All >>>> Interfaces port >>>> 389 for LDAP requests >>>> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 >>>> for LDAPS >>>> requests >>>> [05/Oct/2015:13:51:30 +0200] - Listening on >>>> /var/run/slapd-INTERNAL.socket for >>>> LDAPI requests >>>> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - >>>> Error: could >>>> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 >>>> (Local >>>> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS >>>> failure. >>>> Minor code may provide more information (No Kerberos credentials >>>> available)) >>>> errno 0 (Success) >>>> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not >>>> perform >>>> interactive bind for id [] authentication mechanism [GSSAPI]: error >>>> -2 (Local >>>> error) >>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>> GSSAPI auth >>>> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>> GSSAPI Error: >>>> Unspecified GSS failure. Minor code may provide more information (No >>>> Kerberos >>>> credentials available)) >>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog >>>> program - >>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN >>>> 54bea480000000600000 not found, we aren't as up to date, or we purged >>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>> Data required >>>> to update replica has been purged. The replica must be reinitialized. >>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>> Incremental >>>> update failed and requires administrator action >>>> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - >>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>> GSSAPI auth >>>> resumed >>>> >>>> >>>> These lines are present since a replayed a ldif dump from ipa02 to >>>> ipa01, but i >>>> didn't think that it related to the segfault problem (therefore i >>>> said there >>>> are no related problems in the logfile). >>>> >>>> But I am starting to believe that these errors could be in relation >>>> to each other. >>>> >>>> >>>> Kind regards, >>>> Dominik Korittki >>>> >>>> >>>>> >>>>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates >>>>>> to the >>>>>> problem. >>>> Not sure about that anymore. >>>> >>>>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does >>>>>> that >>>>>> solve my problems? >>>>>> >>>>>> FreeIPA server version is 3.3.3-28.el7.centos >>>>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>>>>> >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> Dominik Korittki >>>>>> >>>>> >>>>> >>>>> >>>> >> >> >> >> > From aly.khimji at gmail.com Wed Oct 7 17:11:52 2015 From: aly.khimji at gmail.com (Aly Khimji) Date: Wed, 7 Oct 2015 13:11:52 -0400 Subject: [Freeipa-users] FreeIPA DMZ topology Message-ID: Hey guys, Question for you, would having a replica be the ideal solution for authorizing hosts in a DMZ? Do you have any use cases for DMZ access/authorization or topologies you can share for DMZ zones where FreeIPA is used? Aly -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Wed Oct 7 17:18:48 2015 From: jbaird at follett.com (Baird, Josh) Date: Wed, 7 Oct 2015 17:18:48 +0000 Subject: [Freeipa-users] FreeIPA DMZ topology In-Reply-To: References: Message-ID: I'm also interested in how people are handling this - especially when using AD Trusts. When using a trust, the IPA host not only has to communicate with IPA servers, but with potentially every AD domain controller in your HUB site. For us, this is a large number of domain controllers which means we would need a large number of ACL's on our firewalls to permit the IPA DMZ client access to the AD domain controllers. Any suggestions? Thanks, Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Aly Khimji Sent: Wednesday, October 07, 2015 1:12 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] FreeIPA DMZ topology Hey guys, Question for you, would having a replica be the ideal solution for authorizing hosts in a DMZ? Do you have any use cases for DMZ access/authorization or topologies you can share for DMZ zones where FreeIPA is used? Aly -------------- next part -------------- An HTML attachment was scrubbed... URL: From aly.khimji at gmail.com Wed Oct 7 17:30:33 2015 From: aly.khimji at gmail.com (Aly Khimji) Date: Wed, 7 Oct 2015 13:30:33 -0400 Subject: [Freeipa-users] FreeIPA DMZ topology In-Reply-To: References: Message-ID: Yes sorry I should expand on my question as per Josh's point my scenario also has an AD trust involved. I recently learned of KDC proxying but I am not sure if replica's and KDC proxies are the preferred/accepted design solutions for DMZ's Aly On Wed, Oct 7, 2015 at 1:18 PM, Baird, Josh wrote: > I'm also interested in how people are handling this - especially when > using AD Trusts. > > > > When using a trust, the IPA host not only has to communicate with IPA > servers, but with potentially every AD domain controller in your HUB site. > For us, this is a large number of domain controllers which means we would > need a large number of ACL's on our firewalls to permit the IPA DMZ client > access to the AD domain controllers. > > > > Any suggestions? > > > > Thanks, > > > > Josh > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Aly Khimji > *Sent:* Wednesday, October 07, 2015 1:12 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] FreeIPA DMZ topology > > > > Hey guys, > > > > Question for you, would having a replica be the ideal solution for > authorizing hosts in a DMZ? > > > Do you have any use cases for DMZ access/authorization or topologies you > can share for DMZ zones where FreeIPA is used? > > > > Aly > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgunn at mongodb.com Wed Oct 7 17:36:56 2015 From: pgunn at mongodb.com (Pat Gunn) Date: Wed, 07 Oct 2015 17:36:56 +0000 Subject: [Freeipa-users] Web login problems Message-ID: Hi, I'm trying to build a cluster of 3 IPA (staging at this point, but eventually later I'll make a prod version) systems (that will reside in AWS) that will manage select systems in our infrastructure (mostly but not entirely in AWS). The systems will be fronted (like most of our infrastructure) with a load-balancer that manages pooling and SSL termination; we'd like freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will then route that to a specific one of the three servers based on pool settings). The systems are running CentOS7 and have the RPM-bundled version of FreeIPA (4.1.0). Our three IPA servers are named freeipa-staging-[123].vpc3.$INTERNALNAME.cc - the servers that will be managed by this will have a variety of names and locations (and $INTERNALNAME differs from $ORGNAME but both are valid DNSnames) After running ipa-server-install on the first box (no integrated DNS enabled, realmname is IPA-STAGING.$ORGNAME.ORG), I modified the ipa-rewrite.conf to trim it down to this: RewriteEngine on RewriteRule ^/$ /ipa/ui [L,NC,R=301] RewriteRule ^/ipa/ui/js/freeipa/plugins.js$ /ipa/wsgi/plugins.py [PT] After the stack starts, I can kinit and run commands. Everything looks good. The WebUI isn't working for me though - when I enter admin and the password, I get "Your session has expired. Please re-login". By contrast, when I give the wrong password, it tells me it's wrong. After enabling debugging in ipa.conf, this is what I get from the httpd error log: [Wed Oct 07 17:29:50.370982 2015] [:error] [pid 3000] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Oct 07 17:29:50.371088 2015] [:error] [pid 3000] ipa: DEBUG: WSGI login_password.__call__: [Wed Oct 07 17:29:50.371438 2015] [:error] [pid 3000] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/ freeipa-staging-1.vpc3.INTERNALNAME.cc at IPA-STAGING.ORGNAME.ORG keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Wed Oct 07 17:29:50.371534 2015] [:error] [pid 3000] ipa: DEBUG: Starting external process [Wed Oct 07 17:29:50.371596 2015] [:error] [pid 3000] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/ freeipa-staging-1.vpc3.INTERNALNAME.cc at IPA-STAGING.ORGNAME.ORG' [Wed Oct 07 17:29:50.415134 2015] [:error] [pid 3000] ipa: DEBUG: Process finished, return code=0 [Wed Oct 07 17:29:50.415223 2015] [:error] [pid 3000] ipa: DEBUG: stdout= [Wed Oct 07 17:29:50.415276 2015] [:error] [pid 3000] ipa: DEBUG: stderr= [Wed Oct 07 17:29:50.415395 2015] [:error] [pid 3000] ipa: DEBUG: Starting external process [Wed Oct 07 17:29:50.415458 2015] [:error] [pid 3000] ipa: DEBUG: args='/usr/bin/kinit' 'admin at IPA-STAGING.ORGNAME.ORG' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Wed Oct 07 17:29:50.486981 2015] [:error] [pid 3000] ipa: DEBUG: Process finished, return code=0 [Wed Oct 07 17:29:50.487072 2015] [:error] [pid 3000] ipa: DEBUG: stdout=Password for admin at IPA-STAGING.ORGNAME.ORG: [Wed Oct 07 17:29:50.487079 2015] [:error] [pid 3000] [Wed Oct 07 17:29:50.487129 2015] [:error] [pid 3000] ipa: DEBUG: stderr= [Wed Oct 07 17:29:50.487228 2015] [:error] [pid 3000] ipa: DEBUG: kinit: principal=admin at IPA-STAGING.ORGNAME.ORG returncode=0, stderr="" [Wed Oct 07 17:29:50.487281 2015] [:error] [pid 3000] ipa: DEBUG: Cleanup the armor ccache [Wed Oct 07 17:29:50.487356 2015] [:error] [pid 3000] ipa: DEBUG: Starting external process [Wed Oct 07 17:29:50.487406 2015] [:error] [pid 3000] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Wed Oct 07 17:29:50.500419 2015] [:error] [pid 3000] ipa: DEBUG: Process finished, return code=0 [Wed Oct 07 17:29:50.500496 2015] [:error] [pid 3000] ipa: DEBUG: stdout= [Wed Oct 07 17:29:50.500547 2015] [:error] [pid 3000] ipa: DEBUG: stderr= [Wed Oct 07 17:29:50.501180 2015] [:error] [pid 3000] ipa: DEBUG: no session cookie found [Wed Oct 07 17:29:50.501501 2015] [:error] [pid 3000] ipa: DEBUG: no session id in request, generating empty session data with id=738fef28e7a985fe8f01e0fc2a1c8e7d [Wed Oct 07 17:29:50.501607 2015] [:error] [pid 3000] ipa: DEBUG: store session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 expiration_timestamp=1970-01-01T00:00:00 [Wed Oct 07 17:29:50.501908 2015] [:error] [pid 3000] ipa: DEBUG: finalize_kerberos_acquisition: login_password ccache_name="FILE:/var/run/ipa_memcached/krbcc_3000" session_id="738fef28e7a985fe8f01e0fc2a1c8e7d" [Wed Oct 07 17:29:50.501978 2015] [:error] [pid 3000] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_3000" [Wed Oct 07 17:29:50.502358 2015] [:error] [pid 3000] ipa: DEBUG: get_credential_times: principal=krbtgt/ IPA-STAGING.ORGNAME.ORG at IPA-STAGING.ORGNAME.ORG, authtime=10/07/15 17:29:50, starttime=10/07/15 17:29:50, endtime=10/08/15 17:29:50, renew_till=01/01/70 00:00:00 [Wed Oct 07 17:29:50.502436 2015] [:error] [pid 3000] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3000 endtime=1444325390 (10/08/15 17:29:50) [Wed Oct 07 17:29:50.502532 2015] [:error] [pid 3000] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1444325090 expiration=1444240190.5 (2015-10-07T17:49:50) [Wed Oct 07 17:29:50.502609 2015] [:error] [pid 3000] ipa: DEBUG: store session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 expiration_timestamp=2015-10-07T17:49:50 [Wed Oct 07 17:29:50.502971 2015] [:error] [pid 3000] ipa: DEBUG: release_ipa_ccache: KRB5CCNAME environment variable not set [Wed Oct 07 17:29:50.612016 2015] [:error] [pid 3001] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Oct 07 17:29:50.612125 2015] [:error] [pid 3001] ipa: DEBUG: WSGI jsonserver_session.__call__: [Wed Oct 07 17:29:50.612684 2015] [:error] [pid 3001] ipa: DEBUG: no session cookie found [Wed Oct 07 17:29:50.613018 2015] [:error] [pid 3001] ipa: DEBUG: no session id in request, generating empty session data with id=f723f440100b47e72675fa0e3cd9e87f [Wed Oct 07 17:29:50.613118 2015] [:error] [pid 3001] ipa: DEBUG: store session: session_id=f723f440100b47e72675fa0e3cd9e87f start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 expiration_timestamp=1970-01-01T00:00:00 [Wed Oct 07 17:29:50.613387 2015] [:error] [pid 3001] ipa: DEBUG: jsonserver_session.__call__: session_id=f723f440100b47e72675fa0e3cd9e87f start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 expiration_timestamp=1970-01-01T00:00:00 [Wed Oct 07 17:29:50.613441 2015] [:error] [pid 3001] ipa: DEBUG: no ccache, need login [Wed Oct 07 17:29:50.613492 2015] [:error] [pid 3001] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login Any ideas? The webUI will normally need to be used by people on systems that are not managed by FreeIPA (this is meant to manage our server infrastructure, not our workstations), but as far as I can tell username/password auth should work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Gronde at fincen.gov Wed Oct 7 17:47:01 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Wed, 7 Oct 2015 17:47:01 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Message-ID: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> I am new to FreeIPA and have inherited two IPA servers not sure if one is a master/slave or how they are different. I will try to give some pertinent outputs below of some of the things I am seeing. I know the Server-Cert is expired but can't figure out how to renew it. There also appears to be Kerberos authentication issues going on as I'm trying to fix it. #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates and requests being tracked: 2. Request ID '20150922143354': status: NEED_TO_SUBMIT stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=.GOV subject: CN=IPA RA,O=.GOV expires: 2013-10-09 11:45:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes #certutil -V -u V -n Server-Cert -d /etc/httpd/alias certutil: certificate is invalid: Peer's Certificate has expired. #certutil -L -d /etc/httpd/alias -n Server-Cert Certificate: Data: Version: 3 (0x2) Serial Number: 166 (0xa6) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=Certificate Authority,O=.GOV" Validity: Not Before: Sun Sep 22 17:46:26 2013 Not After : Wed Sep 23 17:46:26 2015 Subject: "CN=comipa02..gov,O=.GOV" Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: c3:13:4b:16 Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: "http://comipa01..gov:80/ca/ocsp" Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f Fingerprint (SHA-256): DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C Fingerprint (SHA1): 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: User #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? #ipa-getcert list Number of certificates and requests being tracked: 2. Request ID '20151007150853': status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes V/r Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Wed Oct 7 20:30:08 2015 From: janellenicole80 at gmail.com (Janelle) Date: Wed, 7 Oct 2015 13:30:08 -0700 Subject: [Freeipa-users] unindexed searches? Message-ID: <561580D0.5040800@gmail.com> Hello, I hope this is a simply question. I have 1000's of these on my servers and it severely bogs them down. Any ideas on how to get rid of unindexed searches? [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11158 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11160 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11163 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11166 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11168 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11171 RESULT err=0 tag=101 nentries=0 etime=0 notes=U ~Janelle From rcritten at redhat.com Wed Oct 7 20:33:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2015 16:33:06 -0400 Subject: [Freeipa-users] unindexed searches? In-Reply-To: <561580D0.5040800@gmail.com> References: <561580D0.5040800@gmail.com> Message-ID: <56158182.2040405@redhat.com> Janelle wrote: > Hello, > > I hope this is a simply question. I have 1000's of these on my servers > and it severely bogs them down. Any ideas on how to get rid of unindexed > searches? > > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11158 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11160 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11163 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11166 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11168 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11171 RESULT err=0 tag=101 > nentries=0 etime=0 notes=U > > ~Janelle > logconv from 389-ds will give you details on what those searches are. rob From simo at redhat.com Thu Oct 8 01:57:23 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 7 Oct 2015 21:57:23 -0400 Subject: [Freeipa-users] Web login problems In-Reply-To: References: Message-ID: <5615CD83.10901@redhat.com> On 07/10/15 13:36, Pat Gunn wrote: > Hi, > I'm trying to build a cluster of 3 IPA (staging at this point, but > eventually later I'll make a prod version) > systems (that will reside in AWS) that will manage select systems in our > infrastructure (mostly but not entirely in AWS). > The systems will be fronted (like most of our infrastructure) with a > load-balancer that manages pooling and SSL termination; we'd like > freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will > then route that to a specific one of the three servers based on pool > settings). Please read this before you proceed with your LB plan: http://ssimo.org/blog/id_019.html HTH, Simo. > The systems are running CentOS7 and have the RPM-bundled version of FreeIPA > (4.1.0). Our three IPA servers are named > freeipa-staging-[123].vpc3.$INTERNALNAME.cc - the servers that will be > managed by this will have a variety of names and locations (and > $INTERNALNAME differs from $ORGNAME but both are valid DNSnames) > > After running ipa-server-install on the first box (no integrated DNS > enabled, realmname is IPA-STAGING.$ORGNAME.ORG), I modified the > ipa-rewrite.conf to trim it down to this: > RewriteEngine on > RewriteRule ^/$ /ipa/ui [L,NC,R=301] > RewriteRule ^/ipa/ui/js/freeipa/plugins.js$ /ipa/wsgi/plugins.py [PT] > > > After the stack starts, I can kinit and run commands. Everything looks > good. The WebUI isn't working for me though - when I enter admin and the > password, I get "Your session has expired. Please re-login". By contrast, > when I give the wrong password, it tells me it's wrong. > > After enabling debugging in ipa.conf, this is what I get from the httpd > error log: > > [Wed Oct 07 17:29:50.370982 2015] [:error] [pid 3000] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > [Wed Oct 07 17:29:50.371088 2015] [:error] [pid 3000] ipa: DEBUG: WSGI > login_password.__call__: > [Wed Oct 07 17:29:50.371438 2015] [:error] [pid 3000] ipa: DEBUG: Obtaining > armor ccache: principal=HTTP/ > freeipa-staging-1.vpc3.INTERNALNAME.cc at IPA-STAGING.ORGNAME.ORG > keytab=/etc/httpd/conf/ipa.keytab > ccache=/var/run/ipa_memcached/krbcc_A_admin > [Wed Oct 07 17:29:50.371534 2015] [:error] [pid 3000] ipa: DEBUG: Starting > external process > [Wed Oct 07 17:29:50.371596 2015] [:error] [pid 3000] ipa: DEBUG: > args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/ > freeipa-staging-1.vpc3.INTERNALNAME.cc at IPA-STAGING.ORGNAME.ORG' > [Wed Oct 07 17:29:50.415134 2015] [:error] [pid 3000] ipa: DEBUG: Process > finished, return code=0 > [Wed Oct 07 17:29:50.415223 2015] [:error] [pid 3000] ipa: DEBUG: stdout= > [Wed Oct 07 17:29:50.415276 2015] [:error] [pid 3000] ipa: DEBUG: stderr= > [Wed Oct 07 17:29:50.415395 2015] [:error] [pid 3000] ipa: DEBUG: Starting > external process > [Wed Oct 07 17:29:50.415458 2015] [:error] [pid 3000] ipa: DEBUG: > args='/usr/bin/kinit' 'admin at IPA-STAGING.ORGNAME.ORG' '-T' > '/var/run/ipa_memcached/krbcc_A_admin' > [Wed Oct 07 17:29:50.486981 2015] [:error] [pid 3000] ipa: DEBUG: Process > finished, return code=0 > [Wed Oct 07 17:29:50.487072 2015] [:error] [pid 3000] ipa: DEBUG: > stdout=Password for admin at IPA-STAGING.ORGNAME.ORG: > [Wed Oct 07 17:29:50.487079 2015] [:error] [pid 3000] > [Wed Oct 07 17:29:50.487129 2015] [:error] [pid 3000] ipa: DEBUG: stderr= > [Wed Oct 07 17:29:50.487228 2015] [:error] [pid 3000] ipa: DEBUG: kinit: > principal=admin at IPA-STAGING.ORGNAME.ORG returncode=0, stderr="" > [Wed Oct 07 17:29:50.487281 2015] [:error] [pid 3000] ipa: DEBUG: Cleanup > the armor ccache > [Wed Oct 07 17:29:50.487356 2015] [:error] [pid 3000] ipa: DEBUG: Starting > external process > [Wed Oct 07 17:29:50.487406 2015] [:error] [pid 3000] ipa: DEBUG: > args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' > [Wed Oct 07 17:29:50.500419 2015] [:error] [pid 3000] ipa: DEBUG: Process > finished, return code=0 > [Wed Oct 07 17:29:50.500496 2015] [:error] [pid 3000] ipa: DEBUG: stdout= > [Wed Oct 07 17:29:50.500547 2015] [:error] [pid 3000] ipa: DEBUG: stderr= > [Wed Oct 07 17:29:50.501180 2015] [:error] [pid 3000] ipa: DEBUG: no > session cookie found > [Wed Oct 07 17:29:50.501501 2015] [:error] [pid 3000] ipa: DEBUG: no > session id in request, generating empty session data with > id=738fef28e7a985fe8f01e0fc2a1c8e7d > [Wed Oct 07 17:29:50.501607 2015] [:error] [pid 3000] ipa: DEBUG: store > session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d > start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 > expiration_timestamp=1970-01-01T00:00:00 > [Wed Oct 07 17:29:50.501908 2015] [:error] [pid 3000] ipa: DEBUG: > finalize_kerberos_acquisition: login_password > ccache_name="FILE:/var/run/ipa_memcached/krbcc_3000" > session_id="738fef28e7a985fe8f01e0fc2a1c8e7d" > [Wed Oct 07 17:29:50.501978 2015] [:error] [pid 3000] ipa: DEBUG: reading > ccache data from file "/var/run/ipa_memcached/krbcc_3000" > [Wed Oct 07 17:29:50.502358 2015] [:error] [pid 3000] ipa: DEBUG: > get_credential_times: principal=krbtgt/ > IPA-STAGING.ORGNAME.ORG at IPA-STAGING.ORGNAME.ORG, authtime=10/07/15 > 17:29:50, starttime=10/07/15 17:29:50, endtime=10/08/15 17:29:50, > renew_till=01/01/70 00:00:00 > [Wed Oct 07 17:29:50.502436 2015] [:error] [pid 3000] ipa: DEBUG: > KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3000 endtime=1444325390 > (10/08/15 17:29:50) > [Wed Oct 07 17:29:50.502532 2015] [:error] [pid 3000] ipa: DEBUG: > set_session_expiration_time: duration_type=inactivity_timeout duration=1200 > max_age=1444325090 expiration=1444240190.5 (2015-10-07T17:49:50) > [Wed Oct 07 17:29:50.502609 2015] [:error] [pid 3000] ipa: DEBUG: store > session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d > start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 > expiration_timestamp=2015-10-07T17:49:50 > [Wed Oct 07 17:29:50.502971 2015] [:error] [pid 3000] ipa: DEBUG: > release_ipa_ccache: KRB5CCNAME environment variable not set > [Wed Oct 07 17:29:50.612016 2015] [:error] [pid 3001] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > [Wed Oct 07 17:29:50.612125 2015] [:error] [pid 3001] ipa: DEBUG: WSGI > jsonserver_session.__call__: > [Wed Oct 07 17:29:50.612684 2015] [:error] [pid 3001] ipa: DEBUG: no > session cookie found > [Wed Oct 07 17:29:50.613018 2015] [:error] [pid 3001] ipa: DEBUG: no > session id in request, generating empty session data with > id=f723f440100b47e72675fa0e3cd9e87f > [Wed Oct 07 17:29:50.613118 2015] [:error] [pid 3001] ipa: DEBUG: store > session: session_id=f723f440100b47e72675fa0e3cd9e87f > start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 > expiration_timestamp=1970-01-01T00:00:00 > [Wed Oct 07 17:29:50.613387 2015] [:error] [pid 3001] ipa: DEBUG: > jsonserver_session.__call__: session_id=f723f440100b47e72675fa0e3cd9e87f > start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50 > expiration_timestamp=1970-01-01T00:00:00 > [Wed Oct 07 17:29:50.613441 2015] [:error] [pid 3001] ipa: DEBUG: no > ccache, need login > [Wed Oct 07 17:29:50.613492 2015] [:error] [pid 3001] ipa: DEBUG: > jsonserver_session: 401 Unauthorized need login > > Any ideas? The webUI will normally need to be used by people on systems > that are not managed by FreeIPA (this is meant to manage our server > infrastructure, not our workstations), but as far as I can tell > username/password auth should work? > > > -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Oct 8 06:21:35 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Oct 2015 09:21:35 +0300 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> Message-ID: <20151008062135.GE19089@redhat.com> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >I am new to FreeIPA and have inherited two IPA servers not sure if one >is a master/slave or how they are different. I will try to give some >pertinent outputs below of some of the things I am seeing. I know the >Server-Cert is expired but can't figure out how to renew it. There >also appears to be Kerberos authentication issues going on as I'm >trying to fix it. > >#getcert list -d /etc/httpd/alias -n ipaCert >Number of certificates and requests being tracked: 2. >Request ID '20150922143354': > status: NEED_TO_SUBMIT > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' > CA: dogtag-ipa-retrieve-agent-submit > issuer: CN=Certificate Authority,O=.GOV > subject: CN=IPA RA,O=.GOV > expires: 2013-10-09 11:45:01 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > >#certutil -V -u V -n Server-Cert -d /etc/httpd/alias >certutil: certificate is invalid: Peer's Certificate has expired. > > >#certutil -L -d /etc/httpd/alias -n Server-Cert >Certificate: > Data: > Version: 3 (0x2) > Serial Number: 166 (0xa6) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=.GOV" > Validity: > Not Before: Sun Sep 22 17:46:26 2013 > Not After : Wed Sep 23 17:46:26 2015 > Subject: "CN=comipa02..gov,O=.GOV" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: > e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: > ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: > 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: > 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: > 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: > c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: > 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: > ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: > 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: > ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: > 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: > 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: > 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: > a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: > 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Certificate Authority Key Identifier > Key ID: > ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: > c3:13:4b:16 > > Name: Authority Information Access > Method: PKIX Online Certificate Status Protocol > Location: > URI: "http://comipa01..gov:80/ca/ocsp" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: > d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: > 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: > 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: > c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: > b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: > 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: > 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: > ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: > 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: > b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: > 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: > 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: > f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: > 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: > 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f > Fingerprint (SHA-256): > DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C > Fingerprint (SHA1): > 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA > > Certificate Trust Flags: > SSL Flags: > User > Email Flags: > User > Object Signing Flags: > User > >#ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov -k /etc/krb5.keytab >Kerberos User Principal not found. Do you have a valid Credential Cache? So, let's start here. First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >#ipa-getcert list >Number of certificates and requests being tracked: 2. >Request ID '20151007150853': > status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN 'Newly added request needs a PIN to read the key material' > stuck: yes > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt -- / Alexander Bokovoy From guillem.liarte at googlemail.com Wed Oct 7 11:23:06 2015 From: guillem.liarte at googlemail.com (Guillem Liarte) Date: Wed, 7 Oct 2015 13:23:06 +0200 Subject: [Freeipa-users] Slow SSH login for IPA users only In-Reply-To: <20151007103557.GH30474@p.redhat.com> References: <20151007103557.GH30474@p.redhat.com> Message-ID: Sumit, Thanks for you reply. Ues, I have debug enabled: With level 5 I see that here is where it spends most of its time: (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=testuser] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=testuser] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] (0x0200): Got request for [0x3][1][name=testuser] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Wed Oct 7 13:14:18 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success Note that I removed the real domain name, also to make it a short line. After reading in this pots: https://www.centos.org/forums/viewtopic.php?f=47&t=53652 I actually saw that setting selinux_provider = none improved things quite a lot. Still, what is this message: [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null) ? Regards, Guillem On 7 October 2015 at 12:35, Sumit Bose wrote: > On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote: > > All, > > > > I have an IPA 4.1 installation that works perfectly. We just suffer from > > slow logins ( this is also slow in other operations such invoking SUDO ) > > > > IPA user: > > > > 1st. login: 30 seconds > > 2nd login: 8 seconds > > 3rd login: 6.5 seconds > > 4rth login: 20 seconds > > > > Local user: > > > > Consistently under 2 seconds > > > > In SSH have tried: > > > > Setting UseDNS to no > > Setting GSSAPIAuthentication to no > > > > I have tried various things that would work on an slow SSH, with no > effect. > > In fact, local users have no problem. > > > > DNS both forward and reverse works well, works fast and gives consistent > > results. That is no the issue. > > > > While trying to find out more about the issue, I see that after the > client > > has connected, it spends most of the time here: > > > > [...] > > debug2: input_userauth_pk_ok: fp > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > debug3: sign_and_send_pubkey: RSA > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > debug1: Authentication succeeded (publickey). > > [...] > > > > At first I though it might be the key retrival from the IPA service, but > it > > is actually quite fast: > > > > time /usr/bin/sss_ssh_authorizedkeys testuser > > real 0m0.209s > > > > We have all the configration files just as they were after installing the > > ipa-client. The only modification was made to sshd_config as these two > > lines: > > > > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys > > AuthorizedKeysCommandUser nobody > > > > I also tried removing the _srv_ in the ipa server line in sssd.conf, but > > that did not make any difference either. > > > > So, in brief: > > > > - SSH is fast for local users > > - authorized keys get retrieved quickly > > - no DNS issues. > > - IPA users take from 6 to 30 seconds to login (and also to perform sudo > > invocations) > > - While watching ssh logins, for ipa users, it takes a long time to pass > > these two: > > > > - input_userauth_pk_ok > > - sign_and_send_pubkey > > > > Could someone give me an idea of what to try next? > > Please check the SSSD logs especailly the ones for the domain. You might > need to increase the debug_level, please see > https://fedorahosted.org/sssd/wiki/Troubleshooting for details. > > bye, > Sumit > > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Oct 8 13:00:24 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Oct 2015 16:00:24 +0300 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> Message-ID: <20151008130024.GK19089@redhat.com> Hi, On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >Thank you for your response! Do not respond directly, send your emails to the mailing list, please. >Yes "getent passwd admin" does work > ># getent passwd admin >admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash > >The second not returned: > ># ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt >Resubmitting "20151007150853" to "IPA". > >]# ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt >Resubmitting "20151007150853" to "IPA". >[root at comipa02 conf.d]# ipa-getcert list >Number of certificates and requests being tracked: 2. >Request ID '20151007150853': > status: MONITORING > ca-error: Unable to determine principal name for signing request. So it doesn't know whom to map the cert to. When re-submitting the request with ipa-getcert, add -K HTTP/comipa02.itmodev.gov While at it, I've looked at my test setup and I can see that your configuration below lacks restart of httpd after certificate was rotated: -C /usr/lib64/ipa/certmonger/restart_httpd > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=.GOV > subject: CN=comipa02.itmodev.gov,O=.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > >This Cert however still shows expired. What do I need to do to go about renewing it? > ># certutil -V -u V -n Server-Cert -d /etc/httpd/alias >certutil: certificate is invalid: Peer's Certificate has expired. > > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Thursday, October 08, 2015 2:22 AM >To: Gronde, Christopher (Contractor) >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert > >On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>I am new to FreeIPA and have inherited two IPA servers not sure if one >>is a master/slave or how they are different. I will try to give some >>pertinent outputs below of some of the things I am seeing. I know the >>Server-Cert is expired but can't figure out how to renew it. There >>also appears to be Kerberos authentication issues going on as I'm >>trying to fix it. >> >>#getcert list -d /etc/httpd/alias -n ipaCert Number of certificates and >>requests being tracked: 2. >>Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=IPA RA,O=.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >>#certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>certutil: certificate is invalid: Peer's Certificate has expired. >> >> >>#certutil -L -d /etc/httpd/alias -n Server-Cert >>Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 166 (0xa6) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=.GOV" >> Validity: >> Not Before: Sun Sep 22 17:46:26 2013 >> Not After : Wed Sep 23 17:46:26 2015 >> Subject: "CN=comipa02..gov,O=.GOV" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >> Exponent: 65537 (0x10001) >> Signed Extensions: >> Name: Certificate Authority Key Identifier >> Key ID: >> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >> c3:13:4b:16 >> >> Name: Authority Information Access >> Method: PKIX Online Certificate Status Protocol >> Location: >> URI: "http://comipa01..gov:80/ca/ocsp" >> >> Name: Certificate Key Usage >> Critical: True >> Usages: Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> Name: Extended Key Usage >> TLS Web Server Authentication Certificate >> TLS Web Client Authentication Certificate >> >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Signature: >> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >> Fingerprint (SHA-256): >> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >> Fingerprint (SHA1): >> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >> >> Certificate Trust Flags: >> SSL Flags: >> User >> Email Flags: >> User >> Object Signing Flags: >> User >> >>#ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov -k >>/etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >So, let's start here. > >First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. > >Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>#ipa-getcert list >>Number of certificates and requests being tracked: 2. >>Request ID '20151007150853': >> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >'Newly added request needs a PIN to read the key material' > >> stuck: yes >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes > >The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: > >ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt > >-- >/ Alexander Bokovoy > -- / Alexander Bokovoy From Christopher.Gronde at fincen.gov Thu Oct 8 13:06:02 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Thu, 8 Oct 2015 13:06:02 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <20151008130024.GK19089@redhat.com> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> Now I am getting CA_UNREACHABLE # ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C /usr/lib64/ipa/certmonger/restart_httpd Resubmitting "20151007150853" to "IPA". # ipa-getcert list Number of certificates and requests being tracked: 2. Request ID '20151007150853': status: CA_UNREACHABLE ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=.GOV subject: CN=comipa02.itmodev.gov,O=.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes -----Original Message----- From: Alexander Bokovoy [mailto:abokovoy at redhat.com] Sent: Thursday, October 08, 2015 9:00 AM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Hi, On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >Thank you for your response! Do not respond directly, send your emails to the mailing list, please. >Yes "getent passwd admin" does work > ># getent passwd admin >admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash > >The second not returned: > ># ipa-getcert resubmit -i 20151007150853 -p >/etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". > >]# ipa-getcert resubmit -i 20151007150853 -p >/etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >[root at comipa02 conf.d]# ipa-getcert list Number of certificates and >requests being tracked: 2. >Request ID '20151007150853': > status: MONITORING > ca-error: Unable to determine principal name for signing request. So it doesn't know whom to map the cert to. When re-submitting the request with ipa-getcert, add -K HTTP/comipa02.itmodev.gov While at it, I've looked at my test setup and I can see that your configuration below lacks restart of httpd after certificate was rotated: -C /usr/lib64/ipa/certmonger/restart_httpd > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=.GOV > subject: CN=comipa02.itmodev.gov,O=.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > >This Cert however still shows expired. What do I need to do to go about renewing it? > ># certutil -V -u V -n Server-Cert -d /etc/httpd/alias >certutil: certificate is invalid: Peer's Certificate has expired. > > > >-----Original Message----- >From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >Sent: Thursday, October 08, 2015 2:22 AM >To: Gronde, Christopher (Contractor) >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] Certmonger and dogtag not >working....issues manually renewing Server-Cert > >On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>I am new to FreeIPA and have inherited two IPA servers not sure if one >>is a master/slave or how they are different. I will try to give some >>pertinent outputs below of some of the things I am seeing. I know the >>Server-Cert is expired but can't figure out how to renew it. There >>also appears to be Kerberos authentication issues going on as I'm >>trying to fix it. >> >>#getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>and requests being tracked: 2. >>Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=IPA RA,O=.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >>#certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>certutil: certificate is invalid: Peer's Certificate has expired. >> >> >>#certutil -L -d /etc/httpd/alias -n Server-Cert >>Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 166 (0xa6) >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Issuer: "CN=Certificate Authority,O=.GOV" >> Validity: >> Not Before: Sun Sep 22 17:46:26 2013 >> Not After : Wed Sep 23 17:46:26 2015 >> Subject: "CN=comipa02..gov,O=.GOV" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >> Exponent: 65537 (0x10001) >> Signed Extensions: >> Name: Certificate Authority Key Identifier >> Key ID: >> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >> c3:13:4b:16 >> >> Name: Authority Information Access >> Method: PKIX Online Certificate Status Protocol >> Location: >> URI: "http://comipa01..gov:80/ca/ocsp" >> >> Name: Certificate Key Usage >> Critical: True >> Usages: Digital Signature >> Non-Repudiation >> Key Encipherment >> Data Encipherment >> >> Name: Extended Key Usage >> TLS Web Server Authentication Certificate >> TLS Web Client Authentication Certificate >> >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> Signature: >> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >> Fingerprint (SHA-256): >> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >> Fingerprint (SHA1): >> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >> >> Certificate Trust Flags: >> SSL Flags: >> User >> Email Flags: >> User >> Object Signing Flags: >> User >> >>#ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov -k >>/etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >So, let's start here. > >First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. > >Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>#ipa-getcert list >>Number of certificates and requests being tracked: 2. >>Request ID '20151007150853': >> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >'Newly added request needs a PIN to read the key material' > >> stuck: yes >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes > >The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: > >ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt > >-- >/ Alexander Bokovoy > -- / Alexander Bokovoy From alex.williams at brighter-technology.com Thu Oct 8 13:23:51 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Thu, 8 Oct 2015 14:23:51 +0100 Subject: [Freeipa-users] Upgrade of schema has broken permissions and now no one can authenticate if they have certain permissions Message-ID: <56166E67.4030800@brighter-technology.com> Hi folks, this one is becoming a bit of a major issue now. We upgraded one of our IPA3.0.0 servers to use the new dogtag schema over the last few days, then created an IPA4 replica from it successfully, upgraded the schema on a few more of the IPA3.0.0 servers and joined them into the mix and everything appeared to go ok. Unfortunately, the IPA3 replica schemas did not appear to get updated automatically, as the redhat upgrade documentation suggests it will, so we had to do them manually. One last server needed doing this morning and it was manually updated earlier today, a force-sync from one of the other servers was done to ensure it was up to date and Immediately after the sync finished, everyone was then refused authentication for SSH, logging into the web UI for IPA and ultimately, our VPN, which is an OpenVPN server on the IPA realm, using PAM to authenticate users. We've narrowed this down to permission issues by tailing the /var/log/sssd/sssd_OUR_DOMAIN.log, after increasing sssd's debug level. We discovered lines like below on a server we were attempting to ssh into: (Thu Oct 8 13:51:16 2015) [sssd[be[domain-replaced.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=add krbprincipalname to a host+nsuniqueid=1e4b0d05-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com] (Thu Oct 8 14:01:45 2015) [sssd[be[domain-replaced.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=add sudo command+nsuniqueid=1e4b0d0a-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com] If we remove all of a users roles, that user is able to authenticate and the SSH session continues unhindered. Of course a user with no roles, therefore no permissions, is not really able to do anything, so we have to add permissions back in. Unfortunately, there seems to be rather a lot of them that are broken. Any help would be hugely appreciated, as this was a production upgrade, after much planning, which somehow seems to have ended up broken. Kind Regards Alex Williams From mbasti at redhat.com Thu Oct 8 13:29:22 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Oct 2015 15:29:22 +0200 Subject: [Freeipa-users] Upgrade of schema has broken permissions and now no one can authenticate if they have certain permissions In-Reply-To: <56166E67.4030800@brighter-technology.com> References: <56166E67.4030800@brighter-technology.com> Message-ID: <56166FB2.6070006@redhat.com> On 10/08/2015 03:23 PM, Alex Williams wrote: > Hi folks, > > this one is becoming a bit of a major issue now. We upgraded one of > our IPA3.0.0 servers to use the new dogtag schema over the last few > days, then created an IPA4 replica from it successfully, upgraded the > schema on a few more of the IPA3.0.0 servers and joined them into the > mix and everything appeared to go ok. Unfortunately, the IPA3 replica > schemas did not appear to get updated automatically, as the redhat > upgrade documentation suggests it will, so we had to do them manually. > One last server needed doing this morning and it was manually updated > earlier today, a force-sync from one of the other servers was done to > ensure it was up to date and Immediately after the sync finished, > everyone was then refused authentication for SSH, logging into the web > UI for IPA and ultimately, our VPN, which is an OpenVPN server on the > IPA realm, using PAM to authenticate users. We've narrowed this down > to permission issues by tailing the /var/log/sssd/sssd_OUR_DOMAIN.log, > after increasing sssd's debug level. We discovered lines like below on > a server we were attempting to ssh into: > > (Thu Oct 8 13:51:16 2015) [sssd[be[domain-replaced.com]]] > [hbac_eval_user_element] (0x0080): Parse error on [cn=add > krbprincipalname to a > host+nsuniqueid=1e4b0d05-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com] > (Thu Oct 8 14:01:45 2015) [sssd[be[domain-replaced.com]]] > [hbac_eval_user_element] (0x0080): Parse error on [cn=add sudo > command+nsuniqueid=1e4b0d0a-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com] IMHO the entries above have replication conflict Please follow: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html Martin > > If we remove all of a users roles, that user is able to authenticate > and the SSH session continues unhindered. Of course a user with no > roles, therefore no permissions, is not really able to do anything, so > we have to add permissions back in. Unfortunately, there seems to be > rather a lot of them that are broken. > > Any help would be hugely appreciated, as this was a production > upgrade, after much planning, which somehow seems to have ended up > broken. > > Kind Regards > > Alex Williams > From rcritten at redhat.com Thu Oct 8 13:48:45 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2015 09:48:45 -0400 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> Message-ID: <5616743D.8040108@redhat.com> Gronde, Christopher (Contractor) wrote: > Now I am getting CA_UNREACHABLE > > # ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C /usr/lib64/ipa/certmonger/restart_httpd > Resubmitting "20151007150853" to "IPA". > > # ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20151007150853': > status: CA_UNREACHABLE > ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=.GOV > subject: CN=comipa02.itmodev.gov,O=.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. What version of IPA is this? rpm -q ipa-server I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. rob > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Thursday, October 08, 2015 9:00 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert > > Hi, > > On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >> Thank you for your response! > Do not respond directly, send your emails to the mailing list, please. > >> Yes "getent passwd admin" does work >> >> # getent passwd admin >> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >> >> The second not returned: >> >> # ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >> >> ]# ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >> requests being tracked: 2. >> Request ID '20151007150853': >> status: MONITORING >> ca-error: Unable to determine principal name for signing request. > So it doesn't know whom to map the cert to. > > When re-submitting the request with ipa-getcert, add > -K HTTP/comipa02.itmodev.gov > > While at it, I've looked at my test setup and I can see that your configuration below lacks restart of httpd after certificate was > rotated: > -C /usr/lib64/ipa/certmonger/restart_httpd > > >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=comipa02.itmodev.gov,O=.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> This Cert however still shows expired. What do I need to do to go about renewing it? >> >> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >> certutil: certificate is invalid: Peer's Certificate has expired. >> >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Thursday, October 08, 2015 2:22 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>> I am new to FreeIPA and have inherited two IPA servers not sure if one >>> is a master/slave or how they are different. I will try to give some >>> pertinent outputs below of some of the things I am seeing. I know the >>> Server-Cert is expired but can't figure out how to renew it. There >>> also appears to be Kerberos authentication issues going on as I'm >>> trying to fix it. >>> >>> #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>> and requests being tracked: 2. >>> Request ID '20150922143354': >>> status: NEED_TO_SUBMIT >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>> CA: dogtag-ipa-retrieve-agent-submit >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=IPA RA,O=.GOV >>> expires: 2013-10-09 11:45:01 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> track: yes >>> auto-renew: yes >>> >>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>> certutil: certificate is invalid: Peer's Certificate has expired. >>> >>> >>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 166 (0xa6) >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Issuer: "CN=Certificate Authority,O=.GOV" >>> Validity: >>> Not Before: Sun Sep 22 17:46:26 2013 >>> Not After : Wed Sep 23 17:46:26 2015 >>> Subject: "CN=comipa02..gov,O=.GOV" >>> Subject Public Key Info: >>> Public Key Algorithm: PKCS #1 RSA Encryption >>> RSA Public Key: >>> Modulus: >>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>> Exponent: 65537 (0x10001) >>> Signed Extensions: >>> Name: Certificate Authority Key Identifier >>> Key ID: >>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>> c3:13:4b:16 >>> >>> Name: Authority Information Access >>> Method: PKIX Online Certificate Status Protocol >>> Location: >>> URI: "http://comipa01..gov:80/ca/ocsp" >>> >>> Name: Certificate Key Usage >>> Critical: True >>> Usages: Digital Signature >>> Non-Repudiation >>> Key Encipherment >>> Data Encipherment >>> >>> Name: Extended Key Usage >>> TLS Web Server Authentication Certificate >>> TLS Web Client Authentication Certificate >>> >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Signature: >>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>> Fingerprint (SHA-256): >>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>> Fingerprint (SHA1): >>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>> >>> Certificate Trust Flags: >>> SSL Flags: >>> User >>> Email Flags: >>> User >>> Object Signing Flags: >>> User >>> >>> #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov -k >>> /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >> So, let's start here. >> >> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >> >> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>> #ipa-getcert list >>> Number of certificates and requests being tracked: 2. >>> Request ID '20151007150853': >>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >> 'Newly added request needs a PIN to read the key material' >> >>> stuck: yes >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>> CA: IPA >>> issuer: >>> subject: >>> expires: unknown >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >> >> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >> >> ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt >> >> -- >> / Alexander Bokovoy >> > > -- > / Alexander Bokovoy > > From Christopher.Gronde at fincen.gov Thu Oct 8 13:52:57 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Thu, 8 Oct 2015 13:52:57 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <5616743D.8040108@redhat.com> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> Currently running ipa-server-3.0.0-47.el6.x86_64 I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 9:49 AM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > Now I am getting CA_UNREACHABLE > > # ipa-getcert resubmit -i 20151007150853 -p > /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C > /usr/lib64/ipa/certmonger/restart_httpd > Resubmitting "20151007150853" to "IPA". > > # ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20151007150853': > status: CA_UNREACHABLE > ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=.GOV > subject: CN=comipa02.itmodev.gov,O=.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. What version of IPA is this? rpm -q ipa-server I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. rob > > > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Thursday, October 08, 2015 9:00 AM > To: Gronde, Christopher (Contractor) > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Hi, > > On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >> Thank you for your response! > Do not respond directly, send your emails to the mailing list, please. > >> Yes "getent passwd admin" does work >> >> # getent passwd admin >> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >> >> The second not returned: >> >> # ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >> >> ]# ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >> requests being tracked: 2. >> Request ID '20151007150853': >> status: MONITORING >> ca-error: Unable to determine principal name for signing request. > So it doesn't know whom to map the cert to. > > When re-submitting the request with ipa-getcert, add > -K HTTP/comipa02.itmodev.gov > > While at it, I've looked at my test setup and I can see that your > configuration below lacks restart of httpd after certificate was > rotated: > -C /usr/lib64/ipa/certmonger/restart_httpd > > >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=comipa02.itmodev.gov,O=.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> This Cert however still shows expired. What do I need to do to go about renewing it? >> >> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >> certutil: certificate is invalid: Peer's Certificate has expired. >> >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Thursday, October 08, 2015 2:22 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>> I am new to FreeIPA and have inherited two IPA servers not sure if >>> one is a master/slave or how they are different. I will try to give >>> some pertinent outputs below of some of the things I am seeing. I >>> know the Server-Cert is expired but can't figure out how to renew >>> it. There also appears to be Kerberos authentication issues going >>> on as I'm trying to fix it. >>> >>> #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>> and requests being tracked: 2. >>> Request ID '20150922143354': >>> status: NEED_TO_SUBMIT >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>> CA: dogtag-ipa-retrieve-agent-submit >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=IPA RA,O=.GOV >>> expires: 2013-10-09 11:45:01 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> track: yes >>> auto-renew: yes >>> >>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>> certutil: certificate is invalid: Peer's Certificate has expired. >>> >>> >>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>> Certificate: >>> Data: >>> Version: 3 (0x2) >>> Serial Number: 166 (0xa6) >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Issuer: "CN=Certificate Authority,O=.GOV" >>> Validity: >>> Not Before: Sun Sep 22 17:46:26 2013 >>> Not After : Wed Sep 23 17:46:26 2015 >>> Subject: "CN=comipa02..gov,O=.GOV" >>> Subject Public Key Info: >>> Public Key Algorithm: PKCS #1 RSA Encryption >>> RSA Public Key: >>> Modulus: >>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>> Exponent: 65537 (0x10001) >>> Signed Extensions: >>> Name: Certificate Authority Key Identifier >>> Key ID: >>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>> c3:13:4b:16 >>> >>> Name: Authority Information Access >>> Method: PKIX Online Certificate Status Protocol >>> Location: >>> URI: "http://comipa01..gov:80/ca/ocsp" >>> >>> Name: Certificate Key Usage >>> Critical: True >>> Usages: Digital Signature >>> Non-Repudiation >>> Key Encipherment >>> Data Encipherment >>> >>> Name: Extended Key Usage >>> TLS Web Server Authentication Certificate >>> TLS Web Client Authentication Certificate >>> >>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>> Signature: >>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>> Fingerprint (SHA-256): >>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>> Fingerprint (SHA1): >>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>> >>> Certificate Trust Flags: >>> SSL Flags: >>> User >>> Email Flags: >>> User >>> Object Signing Flags: >>> User >>> >>> #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov >>> -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >> So, let's start here. >> >> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >> >> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>> #ipa-getcert list >>> Number of certificates and requests being tracked: 2. >>> Request ID '20151007150853': >>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >> 'Newly added request needs a PIN to read the key material' >> >>> stuck: yes >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>> CA: IPA >>> issuer: >>> subject: >>> expires: unknown >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >> >> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >> >> ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt >> >> -- >> / Alexander Bokovoy >> > > -- > / Alexander Bokovoy > > From karl.forner at gmail.com Thu Oct 8 14:09:33 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 8 Oct 2015 16:09:33 +0200 Subject: [Freeipa-users] sudo rules do not seem to work Message-ID: Sorry I had disabled the emailing, just was your answers in the archives. >> How can I debug this ? >Pavel (CC) has a nice sudo debug howto, maybe it would be helpful? Where is it ? Do you mean the slide "FreeIPA Training Series: Obtaining debugging information" from https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf ? Thanks ! Karl From karl.forner at gmail.com Thu Oct 8 14:26:11 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 8 Oct 2015 16:26:11 +0200 Subject: [Freeipa-users] (no subject) Message-ID: Hi, > you are prompted for password because (ALL) ALL rule is applied because of last-match rule. > > > See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. Ok. I updated the rules to use a sudoorder attribute of 100 for the /usr/bin/less sudo rule. Now, if I type in a terminal: %sudo -l Matching Defaults entries for karl on midgard: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User karl may run the following commands on xxxx: (ALL) ALL (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status (ALL) ALL (ALL) NOPASSWD: /usr/bin/less so my less rule is the last one. So far so good. %sudo -l less /usr/bin/less but if I type in a new terminal: %sudo less .bashrc [sudo] password for karl: I am prompted to type in a password. So there seems to be a problem, right ? Regards, Karl From rcritten at redhat.com Thu Oct 8 14:33:29 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2015 10:33:29 -0400 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> Message-ID: <56167EB9.50407@redhat.com> Gronde, Christopher (Contractor) wrote: > Currently running ipa-server-3.0.0-47.el6.x86_64 > > I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. You should be tracking 8 certificates. The output of `getcert list` should look something like: Number of certificates and requests being tracked: 8. Request ID '20150102143352': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2016-12-22 14:33:08 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143353': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=OCSP Subsystem,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143354': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Subsystem,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143355': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=IPA RA,O=EXAMPLE.COM expires: 2016-12-22 14:33:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20150102143356': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20150102143410': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:34:09 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes Request ID '20150102143452': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:34:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA track: yes auto-renew: yes Request ID '20150102143632': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:36:32 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. rob > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 9:49 AM > To: Gronde, Christopher (Contractor) ; Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> Now I am getting CA_UNREACHABLE >> >> # ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >> /usr/lib64/ipa/certmonger/restart_httpd >> Resubmitting "20151007150853" to "IPA". >> >> # ipa-getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=comipa02.itmodev.gov,O=.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. > > What version of IPA is this? rpm -q ipa-server > > I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. > > rob > >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Thursday, October 08, 2015 9:00 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Hi, >> >> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>> Thank you for your response! >> Do not respond directly, send your emails to the mailing list, please. >> >>> Yes "getent passwd admin" does work >>> >>> # getent passwd admin >>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>> >>> The second not returned: >>> >>> # ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>> >>> ]# ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >>> requests being tracked: 2. >>> Request ID '20151007150853': >>> status: MONITORING >>> ca-error: Unable to determine principal name for signing request. >> So it doesn't know whom to map the cert to. >> >> When re-submitting the request with ipa-getcert, add >> -K HTTP/comipa02.itmodev.gov >> >> While at it, I've looked at my test setup and I can see that your >> configuration below lacks restart of httpd after certificate was >> rotated: >> -C /usr/lib64/ipa/certmonger/restart_httpd >> >> >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=comipa02.itmodev.gov,O=.GOV >>> expires: 2015-09-23 17:46:26 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >>> >>> This Cert however still shows expired. What do I need to do to go about renewing it? >>> >>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>> certutil: certificate is invalid: Peer's Certificate has expired. >>> >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Thursday, October 08, 2015 2:22 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>> I am new to FreeIPA and have inherited two IPA servers not sure if >>>> one is a master/slave or how they are different. I will try to give >>>> some pertinent outputs below of some of the things I am seeing. I >>>> know the Server-Cert is expired but can't figure out how to renew >>>> it. There also appears to be Kerberos authentication issues going >>>> on as I'm trying to fix it. >>>> >>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>>> and requests being tracked: 2. >>>> Request ID '20150922143354': >>>> status: NEED_TO_SUBMIT >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>> CA: dogtag-ipa-retrieve-agent-submit >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=IPA RA,O=.GOV >>>> expires: 2013-10-09 11:45:01 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>>> >>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>> >>>> >>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 166 (0xa6) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>> Validity: >>>> Not Before: Sun Sep 22 17:46:26 2013 >>>> Not After : Wed Sep 23 17:46:26 2015 >>>> Subject: "CN=comipa02..gov,O=.GOV" >>>> Subject Public Key Info: >>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>> RSA Public Key: >>>> Modulus: >>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>> Exponent: 65537 (0x10001) >>>> Signed Extensions: >>>> Name: Certificate Authority Key Identifier >>>> Key ID: >>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>> c3:13:4b:16 >>>> >>>> Name: Authority Information Access >>>> Method: PKIX Online Certificate Status Protocol >>>> Location: >>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>> >>>> Name: Certificate Key Usage >>>> Critical: True >>>> Usages: Digital Signature >>>> Non-Repudiation >>>> Key Encipherment >>>> Data Encipherment >>>> >>>> Name: Extended Key Usage >>>> TLS Web Server Authentication Certificate >>>> TLS Web Client Authentication Certificate >>>> >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Signature: >>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>> Fingerprint (SHA-256): >>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>> Fingerprint (SHA1): >>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>> >>>> Certificate Trust Flags: >>>> SSL Flags: >>>> User >>>> Email Flags: >>>> User >>>> Object Signing Flags: >>>> User >>>> >>>> #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov >>>> -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>> So, let's start here. >>> >>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>> >>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>> #ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>> 'Newly added request needs a PIN to read the key material' >>> >>>> stuck: yes >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>> CA: IPA >>>> issuer: >>>> subject: >>>> expires: unknown >>>> pre-save command: >>>> post-save command: >>>> track: yes >>>> auto-renew: yes >>> >>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>> >>> ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt >>> >>> -- >>> / Alexander Bokovoy >>> >> >> -- >> / Alexander Bokovoy >> >> > > From Christopher.Gronde at fincen.gov Thu Oct 8 14:49:56 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Thu, 8 Oct 2015 14:49:56 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <56167EB9.50407@redhat.com> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> When I ran "getcert list" rather than "ipa-getcert list" I get the following: # getcert list Number of certificates and requests being tracked: 2. Request ID '20150922143354': status: NEED_TO_SUBMIT stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=IPA RA,O=ITMODEV.GOV expires: 2013-10-09 11:45:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20151007150853': status: CA_UNREACHABLE ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 10:33 AM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > Currently running ipa-server-3.0.0-47.el6.x86_64 > > I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. You should be tracking 8 certificates. The output of `getcert list` should look something like: Number of certificates and requests being tracked: 8. Request ID '20150102143352': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2016-12-22 14:33:08 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143353': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=OCSP Subsystem,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143354': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Subsystem,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20150102143355': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=IPA RA,O=EXAMPLE.COM expires: 2016-12-22 14:33:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20150102143356': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2016-12-22 14:33:07 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20150102143410': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:34:09 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes Request ID '20150102143452': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:34:51 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA track: yes auto-renew: yes Request ID '20150102143632': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2017-01-02 14:36:32 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. rob > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 9:49 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> Now I am getting CA_UNREACHABLE >> >> # ipa-getcert resubmit -i 20151007150853 -p >> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >> /usr/lib64/ipa/certmonger/restart_httpd >> Resubmitting "20151007150853" to "IPA". >> >> # ipa-getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=.GOV >> subject: CN=comipa02.itmodev.gov,O=.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. > > What version of IPA is this? rpm -q ipa-server > > I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. > > rob > >> >> >> -----Original Message----- >> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >> Sent: Thursday, October 08, 2015 9:00 AM >> To: Gronde, Christopher (Contractor) >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Hi, >> >> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>> Thank you for your response! >> Do not respond directly, send your emails to the mailing list, please. >> >>> Yes "getent passwd admin" does work >>> >>> # getent passwd admin >>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>> >>> The second not returned: >>> >>> # ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>> >>> ]# ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >>> requests being tracked: 2. >>> Request ID '20151007150853': >>> status: MONITORING >>> ca-error: Unable to determine principal name for signing request. >> So it doesn't know whom to map the cert to. >> >> When re-submitting the request with ipa-getcert, add >> -K HTTP/comipa02.itmodev.gov >> >> While at it, I've looked at my test setup and I can see that your >> configuration below lacks restart of httpd after certificate was >> rotated: >> -C /usr/lib64/ipa/certmonger/restart_httpd >> >> >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=comipa02.itmodev.gov,O=.GOV >>> expires: 2015-09-23 17:46:26 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >>> >>> This Cert however still shows expired. What do I need to do to go about renewing it? >>> >>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>> certutil: certificate is invalid: Peer's Certificate has expired. >>> >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Thursday, October 08, 2015 2:22 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>> I am new to FreeIPA and have inherited two IPA servers not sure if >>>> one is a master/slave or how they are different. I will try to >>>> give some pertinent outputs below of some of the things I am >>>> seeing. I know the Server-Cert is expired but can't figure out how >>>> to renew it. There also appears to be Kerberos authentication >>>> issues going on as I'm trying to fix it. >>>> >>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>>> and requests being tracked: 2. >>>> Request ID '20150922143354': >>>> status: NEED_TO_SUBMIT >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>> CA: dogtag-ipa-retrieve-agent-submit >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=IPA RA,O=.GOV >>>> expires: 2013-10-09 11:45:01 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>>> >>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>> >>>> >>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>> Certificate: >>>> Data: >>>> Version: 3 (0x2) >>>> Serial Number: 166 (0xa6) >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>> Validity: >>>> Not Before: Sun Sep 22 17:46:26 2013 >>>> Not After : Wed Sep 23 17:46:26 2015 >>>> Subject: "CN=comipa02..gov,O=.GOV" >>>> Subject Public Key Info: >>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>> RSA Public Key: >>>> Modulus: >>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>> Exponent: 65537 (0x10001) >>>> Signed Extensions: >>>> Name: Certificate Authority Key Identifier >>>> Key ID: >>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>> c3:13:4b:16 >>>> >>>> Name: Authority Information Access >>>> Method: PKIX Online Certificate Status Protocol >>>> Location: >>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>> >>>> Name: Certificate Key Usage >>>> Critical: True >>>> Usages: Digital Signature >>>> Non-Repudiation >>>> Key Encipherment >>>> Data Encipherment >>>> >>>> Name: Extended Key Usage >>>> TLS Web Server Authentication Certificate >>>> TLS Web Client Authentication Certificate >>>> >>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>> Signature: >>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>> Fingerprint (SHA-256): >>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>> Fingerprint (SHA1): >>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>> >>>> Certificate Trust Flags: >>>> SSL Flags: >>>> User >>>> Email Flags: >>>> User >>>> Object Signing Flags: >>>> User >>>> >>>> #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov >>>> -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>> So, let's start here. >>> >>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>> >>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>> #ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>> 'Newly added request needs a PIN to read the key material' >>> >>>> stuck: yes >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>> CA: IPA >>>> issuer: >>>> subject: >>>> expires: unknown >>>> pre-save command: >>>> post-save command: >>>> track: yes >>>> auto-renew: yes >>> >>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>> >>> ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt >>> >>> -- >>> / Alexander Bokovoy >>> >> >> -- >> / Alexander Bokovoy >> >> > > From pvoborni at redhat.com Thu Oct 8 15:19:01 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 8 Oct 2015 17:19:01 +0200 Subject: [Freeipa-users] Announcing FreeIPA 4.2.2 Message-ID: <56168965.5070307@redhat.com> The FreeIPA team would like to announce FreeIPA v4.2.2 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds are available for Fedora 23 and rawhide. Builds for Fedora 22 are available in the official COPR repository . This announcement is also available at . == Highlights in 4.2.2 == FreeIPA 4.2.0 introduced Key Archival Agent (KRA) support. This release fixes CVE-2015-5284. The CVE affects IPA servers where ipa-kra-install was run. Read manual instructions if your system was affected . === Bug fixes === * CVE-2015-5284: ipa-kra-install included certificate and private key in world readable file. * Firefox configuration steps were adjusted to new extension signing policy. * ipa-restore does not overwrite files with local users/groups * ipa-restore now works with KRA installed * Fixed an integer underflow bug in libotp which prevented from syncing TOTP tokens under certain circumstances. * winsync-migrate properly handles collisions in the names of external group * Fixed regression where installation of CA failed on CA-less server #5288. * Vault operations now works on a replica without KRA installed (assuming that at least one replica has KRA installed). #5302 === Enhancements === * Improved performance of search in Web UI's dialog for adding e.g. users to e.g. sudo rules. * Modified vault access control and added commands for managing vault containers. #5250 * Added support for generating client referrals for trusted domain principals. Note that bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844 has to be fixed in MIT Kerberos packages to allow client referrals from FreeIPA KDC to be processed. == Upgrading == Upgrade instructions are available on upgrade page . == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.2.1 == === Abhijeet Kasurde (1) === * Updated number of legacy permission in ipatests === Alexander Bokovoy (1) === * client referral support for trusted domain principals === Christian Heimes (1) === * Handle timeout error in ipa-httpd-kdcproxy === Gabe Alford (4) === * Add Chromium configuration note to ssbrowser * Standardize minvalue for ipasearchrecordlimit and ipasesarchsizelimit for unlimited minvalue * dnssec option missing in ipa-dns-install man page * Update FreeIPA package description === Jan Cholasta (16) === * config: allow user/host attributes with tagging options * baseldap: make subtree deletion optional in LDAPDelete * vault: set owner to current user on container creation * vault: update access control * vault: add permissions and administrator privilege * install: support KRA update * install: Support overriding knobs in subclasses * install: Add common base class for server and replica install * install: Move unattended option to the general help section * install: create kdcproxy user during server install * platform: add option to create home directory when adding user * install: fix kdcproxy user home directory * install: fix ipa-server-install fail on missing --forwarder * install: fix KRA agent PEM file permissions * install: always export KRA agent PEM file * vault: select a server with KRA for vault operations === Martin Babinsky (5) === * load RA backend plugins during standalone CA install on CA-less IPA master * destroy httpd ccache after stopping the service * ipa-server-install: mark master_password Knob as deprecated * re-kinit after ipa-restore in backup/restore CI tests * do not overwrite files with local users/groups when restoring authconfig === Martin Ba?ti (11) === * FIX vault tests * Server Upgrade: backup CS.cfg when dogtag is turned off * IPA Restore: allows to specify files that should be removed * DNSSEC: improve CI test * DNSSEC CI: test master migration * backup CI: test DNS/DNSSEC after backup and restore * Limit max age of replication changelog * Server Upgrade: addifnew should not create entry * CI: backup and restore with KRA * Replica inst. fix: do not require -r, -a, -p options in unattended mode * Fix import get_reverse_zone_default in tasks === Milan Kub?k (4) === * ipatests: Add Certprofile tracker class implementation * ipatests: Add basic tests for certificate profile plugin * ipatests: configure Network Manager not to manage resolv.conf * Include ipatests/test_xmlrpc/data directory into distribution. === Nathaniel McCallum (1) === * Fix an integer underflow bug in libotp === Oleg Fayans (1) === * Added a proper workaround for dnssec test failures in Beaker environment === Petr Voborn?k (4) === * vault: add vault container commands * webui: use manual Firefox configuration for Firefox >= 40 * webui: improve performance of search in association dialog * Become IPA 4.2.2 === Petr ?pa?ek (1) === * Avoid ipa-dnskeysync-replica & ipa-ods-exporter crashes caused by exceeding LDAP limits === Timo Aaltonen (2) === * paths: Add GENERATE_RNDC_KEY. * httpinstance: Replace a hardcoded path to password.conf with HTTPD_PASSWORD_CONF === Tom?? Babej (4) === * winsync: Add inetUser objectclass to the passsync sysaccount * ipa-backup: Add mechanism to store empty directory structure * winsync-migrate: Convert entity names to posix friendly strings * winsync-migrate: Properly handle collisions in the names of external groups -- Petr Vobornik From pbrezina at redhat.com Thu Oct 8 15:26:38 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Thu, 08 Oct 2015 17:26:38 +0200 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <56168B2E.4070505@redhat.com> On 10/08/2015 04:26 PM, Karl Forner wrote: > Hi, > > >> you are prompted for password because (ALL) ALL rule is applied because of last-match rule. > > > See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. > > Ok. I updated the rules to use a sudoorder attribute of 100 for the > /usr/bin/less sudo rule. > Now, if I type in a terminal: > %sudo -l > Matching Defaults entries for karl on midgard: > env_reset, mail_badpass, > secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin > > User karl may run the following commands on xxxx: > (ALL) ALL > (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status > (ALL) ALL > (ALL) NOPASSWD: /usr/bin/less > > so my less rule is the last one. So far so good. > > %sudo -l less > /usr/bin/less > > but if I type in a new terminal: > %sudo less .bashrc > [sudo] password for karl: > > I am prompted to type in a password. > > So there seems to be a problem, right ? > > Regards, > Karl > Hi, we have a bug in sssd in versions prior 1.13.1: https://fedorahosted.org/sssd/ticket/2682 where sudoOrder attribute is treated the other ways around. Please, try inverting the order. What version of sssd do you use? From pbrezina at redhat.com Thu Oct 8 15:27:21 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Thu, 08 Oct 2015 17:27:21 +0200 Subject: [Freeipa-users] sudo rules do not seem to work In-Reply-To: References: Message-ID: <56168B59.80406@redhat.com> On 10/08/2015 04:09 PM, Karl Forner wrote: > Sorry I had disabled the emailing, just was your answers in the archives. > > >>> How can I debug this ? > >> Pavel (CC) has a nice sudo debug howto, maybe it would be helpful? > > Where is it ? Do you mean the slide > "FreeIPA Training Series: Obtaining debugging information" from > https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > ? > > Thanks ! > Karl > It is not yet publicly available. From rcritten at redhat.com Thu Oct 8 15:36:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2015 11:36:32 -0400 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> Message-ID: <56168D80.3070408@redhat.com> Gronde, Christopher (Contractor) wrote: > When I ran "getcert list" rather than "ipa-getcert list" I get the following: > > # getcert list > Number of certificates and requests being tracked: 2. > Request ID '20150922143354': > status: NEED_TO_SUBMIT > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' > CA: dogtag-ipa-retrieve-agent-submit > issuer: CN=Certificate Authority,O=ITMODEV.GOV > subject: CN=IPA RA,O=ITMODEV.GOV > expires: 2013-10-09 11:45:01 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > Request ID '20151007150853': > status: CA_UNREACHABLE > ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ITMODEV.GOV > subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. NOTE: I haven't tested these commands on a live system but I think it is right. # grep internal= /var/lib/pki-ca/conf/password.conf The series of numbers is the PIN you need next. # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' done The tracking is incorrect for ipaCert so you'll need to try to fix it with: # getcert start-tracking -i 20150922143354 -C /usr/lib64/ipa/certmonger/renew_ra_cert And finally track the 389-ds certs: # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' So now theoretically getcert list will show all 8 certificates as being tracked. Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. # service pki-cad restart Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. If that works run ipactl stop, bring time forward, ipactl start. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 10:33 AM > To: Gronde, Christopher (Contractor) ; Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> Currently running ipa-server-3.0.0-47.el6.x86_64 >> >> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. > > You should be tracking 8 certificates. The output of `getcert list` should look something like: > > Number of certificates and requests being tracked: 8. > Request ID '20150102143352': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Audit,O=EXAMPLE.COM > expires: 2016-12-22 14:33:08 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143353': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=OCSP Subsystem,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143354': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Subsystem,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143355': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=IPA RA,O=EXAMPLE.COM > expires: 2016-12-22 14:33:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20150102143356': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20150102143410': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:34:09 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > EXAMPLE-COM > track: yes > auto-renew: yes > Request ID '20150102143452': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:34:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA > track: yes > auto-renew: yes > Request ID '20150102143632': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:36:32 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. > > rob > >> >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 9:49 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Now I am getting CA_UNREACHABLE >>> >>> # ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>> /usr/lib64/ipa/certmonger/restart_httpd >>> Resubmitting "20151007150853" to "IPA". >>> >>> # ipa-getcert list >>> Number of certificates and requests being tracked: 2. >>> Request ID '20151007150853': >>> status: CA_UNREACHABLE >>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=comipa02.itmodev.gov,O=.GOV >>> expires: 2015-09-23 17:46:26 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> track: yes >>> auto-renew: yes >> >> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >> >> What version of IPA is this? rpm -q ipa-server >> >> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Thursday, October 08, 2015 9:00 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Hi, >>> >>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>> Thank you for your response! >>> Do not respond directly, send your emails to the mailing list, please. >>> >>>> Yes "getent passwd admin" does work >>>> >>>> # getent passwd admin >>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>> >>>> The second not returned: >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>> >>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >>>> requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: MONITORING >>>> ca-error: Unable to determine principal name for signing request. >>> So it doesn't know whom to map the cert to. >>> >>> When re-submitting the request with ipa-getcert, add >>> -K HTTP/comipa02.itmodev.gov >>> >>> While at it, I've looked at my test setup and I can see that your >>> configuration below lacks restart of httpd after certificate was >>> rotated: >>> -C /usr/lib64/ipa/certmonger/restart_httpd >>> >>> >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: >>>> track: yes >>>> auto-renew: yes >>>> >>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>> >>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 2:22 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> I am new to FreeIPA and have inherited two IPA servers not sure if >>>>> one is a master/slave or how they are different. I will try to >>>>> give some pertinent outputs below of some of the things I am >>>>> seeing. I know the Server-Cert is expired but can't figure out how >>>>> to renew it. There also appears to be Kerberos authentication >>>>> issues going on as I'm trying to fix it. >>>>> >>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of certificates >>>>> and requests being tracked: 2. >>>>> Request ID '20150922143354': >>>>> status: NEED_TO_SUBMIT >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=IPA RA,O=.GOV >>>>> expires: 2013-10-09 11:45:01 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>> Certificate: >>>>> Data: >>>>> Version: 3 (0x2) >>>>> Serial Number: 166 (0xa6) >>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>> Validity: >>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>> Subject Public Key Info: >>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>> RSA Public Key: >>>>> Modulus: >>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>> Exponent: 65537 (0x10001) >>>>> Signed Extensions: >>>>> Name: Certificate Authority Key Identifier >>>>> Key ID: >>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>> c3:13:4b:16 >>>>> >>>>> Name: Authority Information Access >>>>> Method: PKIX Online Certificate Status Protocol >>>>> Location: >>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>> >>>>> Name: Certificate Key Usage >>>>> Critical: True >>>>> Usages: Digital Signature >>>>> Non-Repudiation >>>>> Key Encipherment >>>>> Data Encipherment >>>>> >>>>> Name: Extended Key Usage >>>>> TLS Web Server Authentication Certificate >>>>> TLS Web Client Authentication Certificate >>>>> >>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>> Signature: >>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>> Fingerprint (SHA-256): >>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>> Fingerprint (SHA1): >>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>> >>>>> Certificate Trust Flags: >>>>> SSL Flags: >>>>> User >>>>> Email Flags: >>>>> User >>>>> Object Signing Flags: >>>>> User >>>>> >>>>> #ipa-getkeytab -s compia02.itmodev.gov -p host/comipa02.itmodev.gov >>>>> -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>> So, let's start here. >>>> >>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>> >>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>> #ipa-getcert list >>>>> Number of certificates and requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>> 'Newly added request needs a PIN to read the key material' >>>> >>>>> stuck: yes >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>> CA: IPA >>>>> issuer: >>>>> subject: >>>>> expires: unknown >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>> >>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>> >>>> ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> > > From d.korittki at mittwald.de Thu Oct 8 15:47:12 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Thu, 8 Oct 2015 17:47:12 +0200 Subject: [Freeipa-users] Cleanly removing replication agreement Message-ID: <56169000.7060302@mittwald.de> Hello folks, i have two FreeIPA 3.3 Machines running on CentOS7: ipa01.internal and ipa02.internal. Both have a CA installed. Initially ipa02 is a replication from ipa01. Recently ipa01 had some trouble while ipa02 was running fine (see "FreeIPA 3.3 performance issues with many hosts" on this maillinglist). So what i did was to uninstall ipa01 via "ipa-server-install --uninstall" and recreated ipa01 as a replica of ipa02 via "ipa-replica-install --setup-ca". Since then I was having trouble with replication. It seems to be there is still some RUV information about the old ipa01 in the database. Well long story short: I want to completely delete ipa02 from the replication agreement on host ipa01 to be able to re-add ipa02 later. Currently the situation on ipa01 is as follows: root at ipa01:~ > ipa-replica-manage list Directory Manager password: ipa01.internal: master ipa02.internal: master root at ipa01:~ > ipa-replica-manage list-ruv Directory Manager password: ipa01.internal:389: 6 ipa02.internal:389: 5 root at ipa01:~ > ipa-csreplica-manage list Directory Manager password: ipa01.internal: master ipa02.internal: master root at ipa01:~ > ldapsearch -D "cn=directory manager" -W -b "cn=mapping tree,cn=config" 'objectClass=nsDS5ReplicationAgreement' nsds50ruv -LLL Enter LDAP Password: dn: cn=cloneAgreement1-ipa01.internal-pki-tomcat,cn=replica,cn=o\3Dipaca,cn=ma pping tree,cn=config nsds50ruv: {replicageneration} 54748540000000600000 nsds50ruv: {replica 97 ldap://ipa02.internal:389} 54748548000000610000 56139e1 8000200610000 nsds50ruv: {replica 1095 ldap://ipa01.internal:389} 56139e17000004470000 56139 e1e000204470000 nsds50ruv: {replica 96 ldap://ipa01.internal:389} I'm a bit worried about the ldapsearch command. There is a nsds50ruv attribute with value 1035. It appeared after I readded ipa01 into the replication agreement. Do I need to get rid of it and if yes, how? Another question is: ipa02 is not responsible anymore, so the CLEANALLRUV Task started on ipa01 by "ipa-replica-manage del ..." would not be able to connect to ipa02. According to 389ds documentation it would stay active a long time trying to connect to the other host. Is it save to abort the task via "ipa-replica-manage abort-clean-ruv ..." after a while? Thanks in advance! Kind regards, Dominik From Christopher.Gronde at fincen.gov Thu Oct 8 16:19:37 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Thu, 8 Oct 2015 16:19:37 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <56168D80.3070408@redhat.com> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> <56168D80.3070408@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> First commend came back: ]# grep internal= /var/lib/pki-ca/conf/password.conf grep: /var/lib/pki-ca/conf/password.conf: No such file or directory There is no pki-ca dir on this server -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 11:37 AM To: Gronde, Christopher (Contractor) ; Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > When I ran "getcert list" rather than "ipa-getcert list" I get the following: > > # getcert list > Number of certificates and requests being tracked: 2. > Request ID '20150922143354': > status: NEED_TO_SUBMIT > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' > CA: dogtag-ipa-retrieve-agent-submit > issuer: CN=Certificate Authority,O=ITMODEV.GOV > subject: CN=IPA RA,O=ITMODEV.GOV > expires: 2013-10-09 11:45:01 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > Request ID '20151007150853': > status: CA_UNREACHABLE > ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ITMODEV.GOV > subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV > expires: 2015-09-23 17:46:26 UTC > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. NOTE: I haven't tested these commands on a live system but I think it is right. # grep internal= /var/lib/pki-ca/conf/password.conf The series of numbers is the PIN you need next. # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' done The tracking is incorrect for ipaCert so you'll need to try to fix it with: # getcert start-tracking -i 20150922143354 -C /usr/lib64/ipa/certmonger/renew_ra_cert And finally track the 389-ds certs: # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' So now theoretically getcert list will show all 8 certificates as being tracked. Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. # service pki-cad restart Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. If that works run ipactl stop, bring time forward, ipactl start. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 10:33 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> Currently running ipa-server-3.0.0-47.el6.x86_64 >> >> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. > > You should be tracking 8 certificates. The output of `getcert list` should look something like: > > Number of certificates and requests being tracked: 8. > Request ID '20150102143352': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Audit,O=EXAMPLE.COM > expires: 2016-12-22 14:33:08 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143353': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=OCSP Subsystem,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143354': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Subsystem,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20150102143355': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=IPA RA,O=EXAMPLE.COM > expires: 2016-12-22 14:33:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20150102143356': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2016-12-22 14:33:07 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20150102143410': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-C > ert',token='NSS Certificate > DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-C > ert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:34:09 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > EXAMPLE-COM > track: yes > auto-renew: yes > Request ID '20150102143452': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > ,token='NSS Certificate > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' > ,token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:34:51 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA > track: yes > auto-renew: yes > Request ID '20150102143632': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N > SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N > SS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa.example.com,O=EXAMPLE.COM > expires: 2017-01-02 14:36:32 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. > > rob > >> >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 9:49 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Now I am getting CA_UNREACHABLE >>> >>> # ipa-getcert resubmit -i 20151007150853 -p >>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>> /usr/lib64/ipa/certmonger/restart_httpd >>> Resubmitting "20151007150853" to "IPA". >>> >>> # ipa-getcert list >>> Number of certificates and requests being tracked: 2. >>> Request ID '20151007150853': >>> status: CA_UNREACHABLE >>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>> stuck: no >>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=.GOV >>> subject: CN=comipa02.itmodev.gov,O=.GOV >>> expires: 2015-09-23 17:46:26 UTC >>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>> track: yes >>> auto-renew: yes >> >> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >> >> What version of IPA is this? rpm -q ipa-server >> >> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>> Sent: Thursday, October 08, 2015 9:00 AM >>> To: Gronde, Christopher (Contractor) >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Hi, >>> >>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>> Thank you for your response! >>> Do not respond directly, send your emails to the mailing list, please. >>> >>>> Yes "getent passwd admin" does work >>>> >>>> # getent passwd admin >>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>> >>>> The second not returned: >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>> >>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >>>> requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: MONITORING >>>> ca-error: Unable to determine principal name for signing request. >>> So it doesn't know whom to map the cert to. >>> >>> When re-submitting the request with ipa-getcert, add >>> -K HTTP/comipa02.itmodev.gov >>> >>> While at it, I've looked at my test setup and I can see that your >>> configuration below lacks restart of httpd after certificate was >>> rotated: >>> -C /usr/lib64/ipa/certmonger/restart_httpd >>> >>> >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: >>>> track: yes >>>> auto-renew: yes >>>> >>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>> >>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 2:22 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> I am new to FreeIPA and have inherited two IPA servers not sure if >>>>> one is a master/slave or how they are different. I will try to >>>>> give some pertinent outputs below of some of the things I am >>>>> seeing. I know the Server-Cert is expired but can't figure out >>>>> how to renew it. There also appears to be Kerberos authentication >>>>> issues going on as I'm trying to fix it. >>>>> >>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>> certificates and requests being tracked: 2. >>>>> Request ID '20150922143354': >>>>> status: NEED_TO_SUBMIT >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=IPA RA,O=.GOV >>>>> expires: 2013-10-09 11:45:01 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>> Certificate: >>>>> Data: >>>>> Version: 3 (0x2) >>>>> Serial Number: 166 (0xa6) >>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>> Validity: >>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>> Subject Public Key Info: >>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>> RSA Public Key: >>>>> Modulus: >>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>> Exponent: 65537 (0x10001) >>>>> Signed Extensions: >>>>> Name: Certificate Authority Key Identifier >>>>> Key ID: >>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>> c3:13:4b:16 >>>>> >>>>> Name: Authority Information Access >>>>> Method: PKIX Online Certificate Status Protocol >>>>> Location: >>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>> >>>>> Name: Certificate Key Usage >>>>> Critical: True >>>>> Usages: Digital Signature >>>>> Non-Repudiation >>>>> Key Encipherment >>>>> Data Encipherment >>>>> >>>>> Name: Extended Key Usage >>>>> TLS Web Server Authentication Certificate >>>>> TLS Web Client Authentication Certificate >>>>> >>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>> Signature: >>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>> Fingerprint (SHA-256): >>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>> Fingerprint (SHA1): >>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>> >>>>> Certificate Trust Flags: >>>>> SSL Flags: >>>>> User >>>>> Email Flags: >>>>> User >>>>> Object Signing Flags: >>>>> User >>>>> >>>>> #ipa-getkeytab -s compia02.itmodev.gov -p >>>>> host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>> So, let's start here. >>>> >>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>> >>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>> #ipa-getcert list >>>>> Number of certificates and requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>> 'Newly added request needs a PIN to read the key material' >>>> >>>>> stuck: yes >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>> CA: IPA >>>>> issuer: >>>>> subject: >>>>> expires: unknown >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>> >>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>> >>>> ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> > > From rcritten at redhat.com Thu Oct 8 17:51:04 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2015 13:51:04 -0400 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> <56168D80.3070408@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> Message-ID: <5616AD08.4020108@redhat.com> Gronde, Christopher (Contractor) wrote: > First commend came back: > > ]# grep internal= /var/lib/pki-ca/conf/password.conf > grep: /var/lib/pki-ca/conf/password.conf: No such file or directory > > There is no pki-ca dir on this server That simplifies things a bit. The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that it has a CSR and it doesn't. This CA will attempt to fetch an update cert from LDAP. See what is available with: % ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov I'm just assuming your IPA Instance isn't actually running, right? You'll probably need to go back in time to have any chance of this working. Apache would be most vocal about not being able to start with an expired cert and offer a means to workaround it (going back in time is a better solution). This is of course assuming that the other IPA master(s) actually have renewed certificates themselves. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 11:37 AM > To: Gronde, Christopher (Contractor) ; Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> When I ran "getcert list" rather than "ipa-getcert list" I get the following: >> >> # getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=IPA RA,O=ITMODEV.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. > > In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. > > NOTE: I haven't tested these commands on a live system but I think it is right. > > # grep internal= /var/lib/pki-ca/conf/password.conf > > The series of numbers is the PIN you need next. > > # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' > done > > The tracking is incorrect for ipaCert so you'll need to try to fix it with: > > # getcert start-tracking -i 20150922143354 -C /usr/lib64/ipa/certmonger/renew_ra_cert > > And finally track the 389-ds certs: > > # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' > # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' > > So now theoretically getcert list will show all 8 certificates as being tracked. > > Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. > In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. > > # service pki-cad restart > > Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . > > Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. > > If that works run ipactl stop, bring time forward, ipactl start. > > rob > > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 10:33 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Currently running ipa-server-3.0.0-47.el6.x86_64 >>> >>> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. >> >> You should be tracking 8 certificates. The output of `getcert list` should look something like: >> >> Number of certificates and requests being tracked: 8. >> Request ID '20150102143352': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Audit,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:08 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143353': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143354': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143355': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=IPA RA,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> Request ID '20150102143356': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> Request ID '20150102143410': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-C >> ert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-C >> ert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:09 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> track: yes >> auto-renew: yes >> Request ID '20150102143452': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA >> track: yes >> auto-renew: yes >> Request ID '20150102143632': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N >> SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N >> SS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:36:32 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Thursday, October 08, 2015 9:49 AM >>> To: Gronde, Christopher (Contractor) ; >>> Alexander Bokovoy >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Now I am getting CA_UNREACHABLE >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>>> /usr/lib64/ipa/certmonger/restart_httpd >>>> Resubmitting "20151007150853" to "IPA". >>>> >>>> # ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: CA_UNREACHABLE >>>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>> >>> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >>> >>> What version of IPA is this? rpm -q ipa-server >>> >>> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >>> >>> rob >>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 9:00 AM >>>> To: Gronde, Christopher (Contractor) >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> Hi, >>>> >>>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> Thank you for your response! >>>> Do not respond directly, send your emails to the mailing list, please. >>>> >>>>> Yes "getent passwd admin" does work >>>>> >>>>> # getent passwd admin >>>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>>> >>>>> The second not returned: >>>>> >>>>> # ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> >>>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates and >>>>> requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: MONITORING >>>>> ca-error: Unable to determine principal name for signing request. >>>> So it doesn't know whom to map the cert to. >>>> >>>> When re-submitting the request with ipa-getcert, add >>>> -K HTTP/comipa02.itmodev.gov >>>> >>>> While at it, I've looked at my test setup and I can see that your >>>> configuration below lacks restart of httpd after certificate was >>>> rotated: >>>> -C /usr/lib64/ipa/certmonger/restart_httpd >>>> >>>> >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>>> expires: 2015-09-23 17:46:26 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>>> >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Thursday, October 08, 2015 2:22 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>>> working....issues manually renewing Server-Cert >>>>> >>>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>>> I am new to FreeIPA and have inherited two IPA servers not sure if >>>>>> one is a master/slave or how they are different. I will try to >>>>>> give some pertinent outputs below of some of the things I am >>>>>> seeing. I know the Server-Cert is expired but can't figure out >>>>>> how to renew it. There also appears to be Kerberos authentication >>>>>> issues going on as I'm trying to fix it. >>>>>> >>>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>>> certificates and requests being tracked: 2. >>>>>> Request ID '20150922143354': >>>>>> status: NEED_TO_SUBMIT >>>>>> stuck: no >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>>> issuer: CN=Certificate Authority,O=.GOV >>>>>> subject: CN=IPA RA,O=.GOV >>>>>> expires: 2013-10-09 11:45:01 UTC >>>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>>> pre-save command: >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>> track: yes >>>>>> auto-renew: yes >>>>>> >>>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>>> >>>>>> >>>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>>> Certificate: >>>>>> Data: >>>>>> Version: 3 (0x2) >>>>>> Serial Number: 166 (0xa6) >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>>> Validity: >>>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>>> Subject Public Key Info: >>>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>>> RSA Public Key: >>>>>> Modulus: >>>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>>> Exponent: 65537 (0x10001) >>>>>> Signed Extensions: >>>>>> Name: Certificate Authority Key Identifier >>>>>> Key ID: >>>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>>> c3:13:4b:16 >>>>>> >>>>>> Name: Authority Information Access >>>>>> Method: PKIX Online Certificate Status Protocol >>>>>> Location: >>>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>>> >>>>>> Name: Certificate Key Usage >>>>>> Critical: True >>>>>> Usages: Digital Signature >>>>>> Non-Repudiation >>>>>> Key Encipherment >>>>>> Data Encipherment >>>>>> >>>>>> Name: Extended Key Usage >>>>>> TLS Web Server Authentication Certificate >>>>>> TLS Web Client Authentication Certificate >>>>>> >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Signature: >>>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>>> Fingerprint (SHA-256): >>>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>>> Fingerprint (SHA1): >>>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>>> >>>>>> Certificate Trust Flags: >>>>>> SSL Flags: >>>>>> User >>>>>> Email Flags: >>>>>> User >>>>>> Object Signing Flags: >>>>>> User >>>>>> >>>>>> #ipa-getkeytab -s compia02.itmodev.gov -p >>>>>> host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>>> So, let's start here. >>>>> >>>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>>> >>>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>>> #ipa-getcert list >>>>>> Number of certificates and requests being tracked: 2. >>>>>> Request ID '20151007150853': >>>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>>> 'Newly added request needs a PIN to read the key material' >>>>> >>>>>> stuck: yes >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> CA: IPA >>>>>> issuer: >>>>>> subject: >>>>>> expires: unknown >>>>>> pre-save command: >>>>>> post-save command: >>>>>> track: yes >>>>>> auto-renew: yes >>>>> >>>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>>> >>>>> ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >> >> > > From Christopher.Gronde at fincen.gov Thu Oct 8 18:06:29 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Thu, 8 Oct 2015 18:06:29 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <5616AD08.4020108@redhat.com> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> <56168D80.3070408@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> <5616AD08.4020108@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B771826FDF8@hqexdb01.hqfincen.gov> # ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ipa service was not running...I attempted to start it. # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl Ntpd is still stopped but date was back to today so I changed the date back to 9/21 and started ipa services # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [ OK ] ]# service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 1:51 PM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > First commend came back: > > ]# grep internal= /var/lib/pki-ca/conf/password.conf > grep: /var/lib/pki-ca/conf/password.conf: No such file or directory > > There is no pki-ca dir on this server That simplifies things a bit. The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that it has a CSR and it doesn't. This CA will attempt to fetch an update cert from LDAP. See what is available with: % ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov I'm just assuming your IPA Instance isn't actually running, right? You'll probably need to go back in time to have any chance of this working. Apache would be most vocal about not being able to start with an expired cert and offer a means to workaround it (going back in time is a better solution). This is of course assuming that the other IPA master(s) actually have renewed certificates themselves. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 11:37 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> When I ran "getcert list" rather than "ipa-getcert list" I get the following: >> >> # getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=IPA RA,O=ITMODEV.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. > > In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. > > NOTE: I haven't tested these commands on a live system but I think it is right. > > # grep internal= /var/lib/pki-ca/conf/password.conf > > The series of numbers is the PIN you need next. > > # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' > done > > The tracking is incorrect for ipaCert so you'll need to try to fix it with: > > # getcert start-tracking -i 20150922143354 -C > /usr/lib64/ipa/certmonger/renew_ra_cert > > And finally track the 389-ds certs: > > # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' > # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' > > So now theoretically getcert list will show all 8 certificates as being tracked. > > Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. > In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. > > # service pki-cad restart > > Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . > > Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. > > If that works run ipactl stop, bring time forward, ipactl start. > > rob > > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 10:33 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Currently running ipa-server-3.0.0-47.el6.x86_64 >>> >>> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. >> >> You should be tracking 8 certificates. The output of `getcert list` should look something like: >> >> Number of certificates and requests being tracked: 8. >> Request ID '20150102143352': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Audit,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:08 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143353': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143354': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143355': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=IPA RA,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> Request ID '20150102143356': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> Request ID '20150102143410': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:09 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> track: yes >> auto-renew: yes >> Request ID '20150102143452': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA >> track: yes >> auto-renew: yes >> Request ID '20150102143632': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N >> SS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:36:32 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Thursday, October 08, 2015 9:49 AM >>> To: Gronde, Christopher (Contractor) >>> ; Alexander Bokovoy >>> >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Now I am getting CA_UNREACHABLE >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>>> /usr/lib64/ipa/certmonger/restart_httpd >>>> Resubmitting "20151007150853" to "IPA". >>>> >>>> # ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: CA_UNREACHABLE >>>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>> >>> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >>> >>> What version of IPA is this? rpm -q ipa-server >>> >>> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >>> >>> rob >>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 9:00 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> Hi, >>>> >>>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> Thank you for your response! >>>> Do not respond directly, send your emails to the mailing list, please. >>>> >>>>> Yes "getent passwd admin" does work >>>>> >>>>> # getent passwd admin >>>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>>> >>>>> The second not returned: >>>>> >>>>> # ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> >>>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates >>>>> and requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: MONITORING >>>>> ca-error: Unable to determine principal name for signing request. >>>> So it doesn't know whom to map the cert to. >>>> >>>> When re-submitting the request with ipa-getcert, add >>>> -K HTTP/comipa02.itmodev.gov >>>> >>>> While at it, I've looked at my test setup and I can see that your >>>> configuration below lacks restart of httpd after certificate was >>>> rotated: >>>> -C /usr/lib64/ipa/certmonger/restart_httpd >>>> >>>> >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>>> expires: 2015-09-23 17:46:26 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>>> >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Thursday, October 08, 2015 2:22 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>>> working....issues manually renewing Server-Cert >>>>> >>>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>>> I am new to FreeIPA and have inherited two IPA servers not sure >>>>>> if one is a master/slave or how they are different. I will try >>>>>> to give some pertinent outputs below of some of the things I am >>>>>> seeing. I know the Server-Cert is expired but can't figure out >>>>>> how to renew it. There also appears to be Kerberos >>>>>> authentication issues going on as I'm trying to fix it. >>>>>> >>>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>>> certificates and requests being tracked: 2. >>>>>> Request ID '20150922143354': >>>>>> status: NEED_TO_SUBMIT >>>>>> stuck: no >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>>> issuer: CN=Certificate Authority,O=.GOV >>>>>> subject: CN=IPA RA,O=.GOV >>>>>> expires: 2013-10-09 11:45:01 UTC >>>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>>> pre-save command: >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>> track: yes >>>>>> auto-renew: yes >>>>>> >>>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>>> >>>>>> >>>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>>> Certificate: >>>>>> Data: >>>>>> Version: 3 (0x2) >>>>>> Serial Number: 166 (0xa6) >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>>> Validity: >>>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>>> Subject Public Key Info: >>>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>>> RSA Public Key: >>>>>> Modulus: >>>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>>> Exponent: 65537 (0x10001) >>>>>> Signed Extensions: >>>>>> Name: Certificate Authority Key Identifier >>>>>> Key ID: >>>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>>> c3:13:4b:16 >>>>>> >>>>>> Name: Authority Information Access >>>>>> Method: PKIX Online Certificate Status Protocol >>>>>> Location: >>>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>>> >>>>>> Name: Certificate Key Usage >>>>>> Critical: True >>>>>> Usages: Digital Signature >>>>>> Non-Repudiation >>>>>> Key Encipherment >>>>>> Data Encipherment >>>>>> >>>>>> Name: Extended Key Usage >>>>>> TLS Web Server Authentication Certificate >>>>>> TLS Web Client Authentication Certificate >>>>>> >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Signature: >>>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>>> Fingerprint (SHA-256): >>>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>>> Fingerprint (SHA1): >>>>>> >>>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>>> >>>>>> Certificate Trust Flags: >>>>>> SSL Flags: >>>>>> User >>>>>> Email Flags: >>>>>> User >>>>>> Object Signing Flags: >>>>>> User >>>>>> >>>>>> #ipa-getkeytab -s compia02.itmodev.gov -p >>>>>> host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>>> So, let's start here. >>>>> >>>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>>> >>>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>>> #ipa-getcert list >>>>>> Number of certificates and requests being tracked: 2. >>>>>> Request ID '20151007150853': >>>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>>> 'Newly added request needs a PIN to read the key material' >>>>> >>>>>> stuck: yes >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> CA: IPA >>>>>> issuer: >>>>>> subject: >>>>>> expires: unknown >>>>>> pre-save command: >>>>>> post-save command: >>>>>> track: yes >>>>>> auto-renew: yes >>>>> >>>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>>> >>>>> ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >> >> > > From pgunn at mongodb.com Thu Oct 8 21:46:35 2015 From: pgunn at mongodb.com (Pat Gunn) Date: Thu, 08 Oct 2015 21:46:35 +0000 Subject: [Freeipa-users] Web login problems Message-ID: On 7/10/15 21:57, Simo Sorce wrote: >On 07/10/15 13:36, Pat Gunn wrote: Hi, I'm trying to build a cluster of 3 IPA (staging at this point, but eventually later I'll make a prod version) systems (that will reside in AWS) that will manage select systems in our infrastructure (mostly but not entirely in AWS). The systems will be fronted (like most of our infrastructure) with a load-balancer that manages pooling and SSL termination; we'd like freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will then route that to a specific one of the three servers based on pool settings). >Please read this before you proceed with your LB plan: >http://ssimo.org/blog/id_019.html > >HTH, >Simo. Hi, I spoke imprecisely. In our hoped-for design, our LB will front access to the web interface for FreeIPA (to manage accounts when needed), but the systems that will use FreeIPA for auth will be contacting the servers directly (we care much more about the LDAP functionality and the GUI than anything else, FWIW). I think I at least identified the initial problem we're having - when the auth is first posted, it succeeds, and the server sends a Set-Cookie for ipa_session that unfortunately includes "Domain=" equivalent to the hostname. This seems unaffected by the Tomcat convention for specifying a proxy as well as setting the host in Apache. I could tell our LB to rewrite that cookie as it comes out of the pool, but I'm hoping to figure out how to get FreeIPA's WebUI to not set the Domain for that cookie or to set it to a specified value, and to do that for only the WebUI. I'm hoping our desired use case and existing infrastructure style isn't incompatible with what FreeIPA is designed for. Any thoughts on that or advice on getting that cookie sent as we like? -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.zoske at euroimmun.de Fri Oct 9 11:04:15 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Fri, 9 Oct 2015 11:04:15 +0000 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151007080241.GP3048@hendrix> References: <20151007080241.GP3048@hendrix> Message-ID: Hi Jakub, I increased the log level in every SSSD section to 6 and got following output, hope that helps. KRB5_CHILD.LOG: https://s.mit42.de/IR6tu SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl SSSD_IPA-LX.COM: https://s.mit42.de/frBvx Best regards, Fabian -----Urspr?ngliche Nachricht----- Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Jakub Hrozek Gesendet: Mittwoch, 7. Oktober 2015 10:03 An: freeipa-users at redhat.com Betreff: Re: [Freeipa-users] SUDO does not always works on first try On Mon, Oct 05, 2015 at 01:25:09PM +0000, Zoske, Fabian wrote: > Dear Jakub, > > I found only the following entries in the /var/log/auth.log: > > Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation > failed Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could > not identify password for [f.zoske at de.eu.local] Oct 5 11:57:38 > hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; > logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 > ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 > 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user > f.zoske at de.eu.local: 7 (Authentication failure) Oct 5 11:57:38 > hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on host ; > TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; > COMMAND=/bin/cat /etc/sssd/sssd.conf Oct 5 11:57:42 hl-srv10 sudo: > pam_unix(sudo:auth): authentication failure; > logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 > ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 > 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; > logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 > ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 > 11:57:43 hl-srv10 sudo: f.zoske at de.eu.local : user NOT authorized on > host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; > COMMAND=/bin/bash Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): > authentication failure; logname=f.zoske at de.eu.local uid=1948403038 > euid=0 tty=/dev/pts/1 ruser=f.zoske at de.eu.local rhost= > user=f.zoske at de.eu.local Oct 5 11:57:47 hl-srv10 sudo: > pam_sss(sudo:auth): authentication success; > logname=f.zoske at de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 > ruser=f.zoske at de.eu.local rhost= user=f.zoske at de.eu.local Oct 5 > 11:57:47 hl-srv10 sudo: f.zoske at de.eu.local : TTY=pts/1 ; > PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash Oct 5 > 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for > user root by > f.zoske at de.eu.local(uid=0) > > In /var/log/sssd/ no entries were logged. Nothing gets logged in by default, you need to increase debug_level, see: https://fedorahosted.org/sssd/wiki/Troubleshooting I would look into the domain log and krb5_child.log first > > My sssd.conf: > [domain/ipa-lx.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa-lx.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = hl-srv10.ipa-lx.com > chpass_provider = ipa > ipa_server = _srv_, dc01.ipa-lx.com > ldap_tls_cacert = /etc/ipa/ca.crt > ldap_sudo_use_host_filter = false > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > default_domain_suffix = de.eu.local > domains = ei-ag.it > > [nss] > override_shell = /bin/bash > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > > Best regards, > Fabian > -- > 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 From pbrezina at redhat.com Fri Oct 9 11:29:16 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 09 Oct 2015 13:29:16 +0200 Subject: [Freeipa-users] HOWTO: Troubleshooting SUDO Message-ID: <5617A50C.2040801@redhat.com> Hi, I just submitted a sudo troubleshooting guide [1]. If you find anything missing, please, let me know. [1] https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO From karl.forner at gmail.com Fri Oct 9 11:36:06 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 9 Oct 2015 13:36:06 +0200 Subject: [Freeipa-users] (no subject) In-Reply-To: <56168B2E.4070505@redhat.com> References: <56168B2E.4070505@redhat.com> Message-ID: Ok, that was it: sssd Version: 1.12.5-1~trusty1 I inverted the sudoOrders: sudo -l Matching Defaults entries for karl on xxxx: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User karl may run the following commands on xxxx: (ALL) NOPASSWD: /usr/bin/less (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod -R g[+-]* * (ALL) ALL (ALL) ALL and I can use sudo less without password. Thanks a lot. On Thu, Oct 8, 2015 at 5:26 PM, Pavel B?ezina wrote: > On 10/08/2015 04:26 PM, Karl Forner wrote: >> >> Hi, >> >> >>> you are prompted for password because (ALL) ALL rule is applied because >>> of last-match rule. > > > See: >>> http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. >> >> >> Ok. I updated the rules to use a sudoorder attribute of 100 for the >> /usr/bin/less sudo rule. >> Now, if I type in a terminal: >> %sudo -l >> Matching Defaults entries for karl on midgard: >> env_reset, mail_badpass, >> >> secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin >> >> User karl may run the following commands on xxxx: >> (ALL) ALL >> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status >> (ALL) ALL >> (ALL) NOPASSWD: /usr/bin/less >> >> so my less rule is the last one. So far so good. >> >> %sudo -l less >> /usr/bin/less >> >> but if I type in a new terminal: >> %sudo less .bashrc >> [sudo] password for karl: >> >> I am prompted to type in a password. >> >> So there seems to be a problem, right ? >> >> Regards, >> Karl >> > > Hi, > we have a bug in sssd in versions prior 1.13.1: > https://fedorahosted.org/sssd/ticket/2682 > > where sudoOrder attribute is treated the other ways around. Please, try > inverting the order. What version of sssd do you use? > From pbrezina at redhat.com Fri Oct 9 11:38:22 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 09 Oct 2015 13:38:22 +0200 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <56168B2E.4070505@redhat.com> Message-ID: <5617A72E.8060806@redhat.com> On 10/09/2015 01:36 PM, Karl Forner wrote: > Ok, that was it: > sssd Version: 1.12.5-1~trusty1 > > I inverted the sudoOrders: > sudo -l > Matching Defaults entries for karl on xxxx: > env_reset, mail_badpass, > secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin > > User karl may run the following commands on xxxx: > (ALL) NOPASSWD: /usr/bin/less > (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status > (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, > /bin/chmod -R g[+-]* * > (ALL) ALL > (ALL) ALL > > > and I can use sudo less without password. > > Thanks a lot. Thanks. Please, keep in mind that we changed the default to the correct order in sssd 1.13.1. Therefore if you update sssd you will either have to invert the order again or set sudo_inverse_order = true in [sudo] in /etc/sssd/sssd.conf. > > > On Thu, Oct 8, 2015 at 5:26 PM, Pavel B?ezina wrote: >> On 10/08/2015 04:26 PM, Karl Forner wrote: >>> >>> Hi, >>> >>> >>>> you are prompted for password because (ALL) ALL rule is applied because >>>> of last-match rule. > > > See: >>>> http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. >>> >>> >>> Ok. I updated the rules to use a sudoorder attribute of 100 for the >>> /usr/bin/less sudo rule. >>> Now, if I type in a terminal: >>> %sudo -l >>> Matching Defaults entries for karl on midgard: >>> env_reset, mail_badpass, >>> >>> secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin >>> >>> User karl may run the following commands on xxxx: >>> (ALL) ALL >>> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status >>> (ALL) ALL >>> (ALL) NOPASSWD: /usr/bin/less >>> >>> so my less rule is the last one. So far so good. >>> >>> %sudo -l less >>> /usr/bin/less >>> >>> but if I type in a new terminal: >>> %sudo less .bashrc >>> [sudo] password for karl: >>> >>> I am prompted to type in a password. >>> >>> So there seems to be a problem, right ? >>> >>> Regards, >>> Karl >>> >> >> Hi, >> we have a bug in sssd in versions prior 1.13.1: >> https://fedorahosted.org/sssd/ticket/2682 >> >> where sudoOrder attribute is treated the other ways around. Please, try >> inverting the order. What version of sssd do you use? >> From karl.forner at gmail.com Fri Oct 9 11:40:36 2015 From: karl.forner at gmail.com (Karl Forner) Date: Fri, 9 Oct 2015 13:40:36 +0200 Subject: [Freeipa-users] (no subject) In-Reply-To: <5617A72E.8060806@redhat.com> References: <56168B2E.4070505@redhat.com> <5617A72E.8060806@redhat.com> Message-ID: > Thanks. Please, keep in mind that we changed the default to the correct > order in sssd 1.13.1. Therefore if you update sssd you will either have to > invert the order again or set sudo_inverse_order = true in [sudo] in > /etc/sssd/sssd.conf. ok. I don't think there's an easy way to upgrade sssd right now with ubuntu 14.04. Is-it possible to set sudo_inverse_order = true with my current version, i.e. even if it is not yet recognized ? > > >> >> >> On Thu, Oct 8, 2015 at 5:26 PM, Pavel B?ezina wrote: >>> >>> On 10/08/2015 04:26 PM, Karl Forner wrote: >>>> >>>> >>>> Hi, >>>> >>>> >>>>> you are prompted for password because (ALL) ALL rule is applied because >>>>> of last-match rule. > > > See: >>>>> http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. >>>> >>>> >>>> >>>> Ok. I updated the rules to use a sudoorder attribute of 100 for the >>>> /usr/bin/less sudo rule. >>>> Now, if I type in a terminal: >>>> %sudo -l >>>> Matching Defaults entries for karl on midgard: >>>> env_reset, mail_badpass, >>>> >>>> >>>> secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin >>>> >>>> User karl may run the following commands on xxxx: >>>> (ALL) ALL >>>> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status >>>> (ALL) ALL >>>> (ALL) NOPASSWD: /usr/bin/less >>>> >>>> so my less rule is the last one. So far so good. >>>> >>>> %sudo -l less >>>> /usr/bin/less >>>> >>>> but if I type in a new terminal: >>>> %sudo less .bashrc >>>> [sudo] password for karl: >>>> >>>> I am prompted to type in a password. >>>> >>>> So there seems to be a problem, right ? >>>> >>>> Regards, >>>> Karl >>>> >>> >>> Hi, >>> we have a bug in sssd in versions prior 1.13.1: >>> https://fedorahosted.org/sssd/ticket/2682 >>> >>> where sudoOrder attribute is treated the other ways around. Please, try >>> inverting the order. What version of sssd do you use? >>> > From sbose at redhat.com Fri Oct 9 12:06:14 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 9 Oct 2015 14:06:14 +0200 Subject: [Freeipa-users] Slow SSH login for IPA users only In-Reply-To: References: <20151007103557.GH30474@p.redhat.com> Message-ID: <20151009120614.GU30474@p.redhat.com> On Wed, Oct 07, 2015 at 01:23:06PM +0200, Guillem Liarte wrote: > Sumit, > > Thanks for you reply. > > Ues, I have debug enabled: With level 5 I see that here is where it spends > most of its time: > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > (0x0200): Got request for [0x1][1][name=testuser] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > (0x0200): Got request for [0x1][1][name=testuser] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > (0x0200): Got request for [0x3][1][name=testuser] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Wed Oct 7 13:14:18 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > > Note that I removed the real domain name, also to make it a short line. > > > After reading in this pots: > > https://www.centos.org/forums/viewtopic.php?f=47&t=53652 > > I actually saw that setting selinux_provider = none improved things quite a > lot. Which SSSD version are you using, this issue was tracked by https://fedorahosted.org/sssd/ticket/2624 and should be fixed in recent versions of SSSD. > > Still, what is this message: > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null) Those are harmless. If you have trust enabled with with AD we have to figure out if the POSIX UID for a user should be calculated based in the SID or taken from a suitable LDAP attribute from AD. Since this happen in the common code for user lookup it is executed for IPA users as well. But I agree that this message is annoying and created https://fedorahosted.org/sssd/ticket/2830 to suppress it for IPA users. bye, Sumit > > ? > > Regards, > > Guillem > > On 7 October 2015 at 12:35, Sumit Bose wrote: > > > On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote: > > > All, > > > > > > I have an IPA 4.1 installation that works perfectly. We just suffer from > > > slow logins ( this is also slow in other operations such invoking SUDO ) > > > > > > IPA user: > > > > > > 1st. login: 30 seconds > > > 2nd login: 8 seconds > > > 3rd login: 6.5 seconds > > > 4rth login: 20 seconds > > > > > > Local user: > > > > > > Consistently under 2 seconds > > > > > > In SSH have tried: > > > > > > Setting UseDNS to no > > > Setting GSSAPIAuthentication to no > > > > > > I have tried various things that would work on an slow SSH, with no > > effect. > > > In fact, local users have no problem. > > > > > > DNS both forward and reverse works well, works fast and gives consistent > > > results. That is no the issue. > > > > > > While trying to find out more about the issue, I see that after the > > client > > > has connected, it spends most of the time here: > > > > > > [...] > > > debug2: input_userauth_pk_ok: fp > > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > > debug3: sign_and_send_pubkey: RSA > > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > > debug1: Authentication succeeded (publickey). > > > [...] > > > > > > At first I though it might be the key retrival from the IPA service, but > > it > > > is actually quite fast: > > > > > > time /usr/bin/sss_ssh_authorizedkeys testuser > > > real 0m0.209s > > > > > > We have all the configration files just as they were after installing the > > > ipa-client. The only modification was made to sshd_config as these two > > > lines: > > > > > > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys > > > AuthorizedKeysCommandUser nobody > > > > > > I also tried removing the _srv_ in the ipa server line in sssd.conf, but > > > that did not make any difference either. > > > > > > So, in brief: > > > > > > - SSH is fast for local users > > > - authorized keys get retrieved quickly > > > - no DNS issues. > > > - IPA users take from 6 to 30 seconds to login (and also to perform sudo > > > invocations) > > > - While watching ssh logins, for ipa users, it takes a long time to pass > > > these two: > > > > > > - input_userauth_pk_ok > > > - sign_and_send_pubkey > > > > > > Could someone give me an idea of what to try next? > > > > Please check the SSSD logs especailly the ones for the domain. You might > > need to increase the debug_level, please see > > https://fedorahosted.org/sssd/wiki/Troubleshooting for details. > > > > bye, > > Sumit > > > > > > > > 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 > > > > From pbrezina at redhat.com Fri Oct 9 12:27:07 2015 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 09 Oct 2015 14:27:07 +0200 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <56168B2E.4070505@redhat.com> <5617A72E.8060806@redhat.com> Message-ID: <5617B29B.8070809@redhat.com> On 10/09/2015 01:40 PM, Karl Forner wrote: >> Thanks. Please, keep in mind that we changed the default to the correct >> order in sssd 1.13.1. Therefore if you update sssd you will either have to >> invert the order again or set sudo_inverse_order = true in [sudo] in >> /etc/sssd/sssd.conf. > > ok. I don't think there's an easy way to upgrade sssd right now with > ubuntu 14.04. > Is-it possible to set sudo_inverse_order = true with my current > version, i.e. even if it is not yet recognized ? SSSD will run but some tools that touch sssd.conf may have problems (for example I think authconfig will fail). > > > > >> >> >>> >>> >>> On Thu, Oct 8, 2015 at 5:26 PM, Pavel B?ezina wrote: >>>> >>>> On 10/08/2015 04:26 PM, Karl Forner wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>>> you are prompted for password because (ALL) ALL rule is applied because >>>>>> of last-match rule. > > > See: >>>>>> http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder. >>>>> >>>>> >>>>> >>>>> Ok. I updated the rules to use a sudoorder attribute of 100 for the >>>>> /usr/bin/less sudo rule. >>>>> Now, if I type in a terminal: >>>>> %sudo -l >>>>> Matching Defaults entries for karl on midgard: >>>>> env_reset, mail_badpass, >>>>> >>>>> >>>>> secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin >>>>> >>>>> User karl may run the following commands on xxxx: >>>>> (ALL) ALL >>>>> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status >>>>> (ALL) ALL >>>>> (ALL) NOPASSWD: /usr/bin/less >>>>> >>>>> so my less rule is the last one. So far so good. >>>>> >>>>> %sudo -l less >>>>> /usr/bin/less >>>>> >>>>> but if I type in a new terminal: >>>>> %sudo less .bashrc >>>>> [sudo] password for karl: >>>>> >>>>> I am prompted to type in a password. >>>>> >>>>> So there seems to be a problem, right ? >>>>> >>>>> Regards, >>>>> Karl >>>>> >>>> >>>> Hi, >>>> we have a bug in sssd in versions prior 1.13.1: >>>> https://fedorahosted.org/sssd/ticket/2682 >>>> >>>> where sudoOrder attribute is treated the other ways around. Please, try >>>> inverting the order. What version of sssd do you use? >>>> >> From guillem.liarte at googlemail.com Fri Oct 9 13:00:56 2015 From: guillem.liarte at googlemail.com (Guillem Liarte) Date: Fri, 9 Oct 2015 15:00:56 +0200 Subject: [Freeipa-users] Slow SSH login for IPA users only In-Reply-To: <20151009120614.GU30474@p.redhat.com> References: <20151007103557.GH30474@p.redhat.com> <20151009120614.GU30474@p.redhat.com> Message-ID: Thanks Sumit. The version of sssd is 1.12.2-58.el7_1.17 I do not have any AD trusts defined, I suppose I should not see those messages. Thanks again. Guillem On 9 October 2015 at 14:06, Sumit Bose wrote: > On Wed, Oct 07, 2015 at 01:23:06PM +0200, Guillem Liarte wrote: > > Sumit, > > > > Thanks for you reply. > > > > Ues, I have debug enabled: With level 5 I see that here is where it > spends > > most of its time: > > > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > > (0x0200): Got request for [0x1][1][name=testuser] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > > (0x0200): Got request for [0x1][1][name=testuser] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info] > > (0x0200): Got request for [0x3][1][name=testuser] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:17 2015) [sssd[be[#.com]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Wed Oct 7 13:14:18 2015) [sssd[be[#.com]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > > > Note that I removed the real domain name, also to make it a short line. > > > > > > After reading in this pots: > > > > https://www.centos.org/forums/viewtopic.php?f=47&t=53652 > > > > I actually saw that setting selinux_provider = none improved things > quite a > > lot. > > Which SSSD version are you using, this issue was tracked by > https://fedorahosted.org/sssd/ticket/2624 and should be fixed in recent > versions of SSSD. > > > > > Still, what is this message: > > > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null) > > Those are harmless. If you have trust enabled with with AD we have to > figure out if the POSIX UID for a user should be calculated based in the > SID or taken from a suitable LDAP attribute from AD. Since this happen > in the common code for user lookup it is executed for IPA users as well. > But I agree that this message is annoying and created > https://fedorahosted.org/sssd/ticket/2830 to suppress it for IPA users. > > bye, > Sumit > > > > > ? > > > > Regards, > > > > Guillem > > > > On 7 October 2015 at 12:35, Sumit Bose wrote: > > > > > On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote: > > > > All, > > > > > > > > I have an IPA 4.1 installation that works perfectly. We just suffer > from > > > > slow logins ( this is also slow in other operations such invoking > SUDO ) > > > > > > > > IPA user: > > > > > > > > 1st. login: 30 seconds > > > > 2nd login: 8 seconds > > > > 3rd login: 6.5 seconds > > > > 4rth login: 20 seconds > > > > > > > > Local user: > > > > > > > > Consistently under 2 seconds > > > > > > > > In SSH have tried: > > > > > > > > Setting UseDNS to no > > > > Setting GSSAPIAuthentication to no > > > > > > > > I have tried various things that would work on an slow SSH, with no > > > effect. > > > > In fact, local users have no problem. > > > > > > > > DNS both forward and reverse works well, works fast and gives > consistent > > > > results. That is no the issue. > > > > > > > > While trying to find out more about the issue, I see that after the > > > client > > > > has connected, it spends most of the time here: > > > > > > > > [...] > > > > debug2: input_userauth_pk_ok: fp > > > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > > > debug3: sign_and_send_pubkey: RSA > > > > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx > > > > debug1: Authentication succeeded (publickey). > > > > [...] > > > > > > > > At first I though it might be the key retrival from the IPA service, > but > > > it > > > > is actually quite fast: > > > > > > > > time /usr/bin/sss_ssh_authorizedkeys testuser > > > > real 0m0.209s > > > > > > > > We have all the configration files just as they were after > installing the > > > > ipa-client. The only modification was made to sshd_config as these > two > > > > lines: > > > > > > > > AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys > > > > AuthorizedKeysCommandUser nobody > > > > > > > > I also tried removing the _srv_ in the ipa server line in sssd.conf, > but > > > > that did not make any difference either. > > > > > > > > So, in brief: > > > > > > > > - SSH is fast for local users > > > > - authorized keys get retrieved quickly > > > > - no DNS issues. > > > > - IPA users take from 6 to 30 seconds to login (and also to perform > sudo > > > > invocations) > > > > - While watching ssh logins, for ipa users, it takes a long time to > pass > > > > these two: > > > > > > > > - input_userauth_pk_ok > > > > - sign_and_send_pubkey > > > > > > > > Could someone give me an idea of what to try next? > > > > > > Please check the SSSD logs especailly the ones for the domain. You > might > > > need to increase the debug_level, please see > > > https://fedorahosted.org/sssd/wiki/Troubleshooting for details. > > > > > > bye, > > > Sumit > > > > > > > > > > > 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 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobeychris at hotmail.com Sun Oct 11 00:06:02 2015 From: tobeychris at hotmail.com (Chris Tobey) Date: Sat, 10 Oct 2015 20:06:02 -0400 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Message-ID: Hi Everyone, I have a functioning FreeIPA server that manages all my users and I would like to also use it for my FreeNAS CIFS shares to authenticate against. Does anyone know what needs to be run on both servers to get this working? I believe it has something to do with Samba properties on the FreeIPA side. I had tried asking the FreeNAS forums but they were of no help (https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup .37083/). I have seen similar requests and success stories, but no actual steps on how to do it. Info: FreeIPA v3.0.0-42 running on CentOS 6.6. FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working before dealing with certs). Any help is appreciated. Thanks, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranger at opennms.org Sun Oct 11 16:59:30 2015 From: ranger at opennms.org (Benjamin Reed) Date: Sun, 11 Oct 2015 12:59:30 -0400 Subject: [Freeipa-users] import debian (salted SHA-512) password Message-ID: <561A9572.7000809@opennms.org> Is there a way for me to import existing SHA-512 passwords into FreeIPA? I've found this old post that implies I could set the password to {ALG}PASS: https://www.redhat.com/archives/freeipa-users/2013-April/msg00028.html ...but I'm not sure exactly what format to use to import a "$6$salt$hash" style password from an existing debian system. Any ideas? -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From piolet.y at gmail.com Sun Oct 11 22:48:33 2015 From: piolet.y at gmail.com (Youenn PIOLET) Date: Mon, 12 Oct 2015 00:48:33 +0200 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA In-Reply-To: References: Message-ID: Sorry for the double post. I forgot to say that my speech is about newest versions of FreeIPA. Maybe someone here knows something about IPA 3.0 ? I'm not sure it used to work with ipasam module. But I suppose the problem is the same: you need to generate Samba schema values for your IPA users in the directory. Cheers, -- Youenn Piolet piolet.y at gmail.com 2015-10-12 0:41 GMT+02:00 Youenn PIOLET : > Hi Chris, > > First, to be sure were on the same page: > Without IPA, to make CIFS users authenticate against directory in a > classic LDAP implementation, you need to extend your LDAP tree with Samba > schema. The FreeNAS documentation is a bit light on this subjet and > previous FreeNAS versions (stable 9.3 included) used to mess up > rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your > 9.2 version. Wrote some messy stuff about it here: > https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md > > To make CIFS users authenticate or FreeIPA recent versions (I only tried > with 4.1), I suggest you to start by reading some of our investigations in > this thread: > > [Freeipa-users] Ubuntu Samba Server Auth against IPA > https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 > > When we discuss about this in august, I've spend almost a week trying to > make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without > fully understand why it didn't work, and moved our CIFS to a dedicated > Centos server. Matt arrived with a similar situation in Ubuntu. > > To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default > with ldapsam.so module. FreeIPA developpers have built a AD trust exchange > possibility with a custom ipasam module that isn't compiled yet for Ubuntu > or FreeNAS. This module gives the possibility to use IPA AD trust > components (e.g. special schema in IPA's directory managing user/group > NT SID) > > If you can't compile the module for FreeNAS / FreeBSD, you may need to > extend 365directory with Samba schema. > You will need to find a way to generate the new attributes when adding > users or groups in FreeIPA, and a way to store password in a CIFS/NT > understandable way. I don't suggest you to follow this dark path. > > You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) > > Good luck in your experimentations, I hope you will succeed! > > > -- > Youenn Piolet > piolet.y at gmail.com > > > 2015-10-11 2:06 GMT+02:00 Chris Tobey : > >> Hi Everyone, >> >> >> I have a functioning FreeIPA server that manages all my users and I would >> like to also use it for my FreeNAS CIFS shares to authenticate against. >> >> Does anyone know what needs to be run on both servers to get this >> working? I believe it has something to do with Samba properties on the >> FreeIPA side. >> >> >> >> I had tried asking the FreeNAS forums but they were of no help ( >> https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/ >> ). >> >> >> >> I have seen similar requests and success stories, but no actual steps on >> how to do it. >> >> Info: >> FreeIPA v3.0.0-42 running on CentOS 6.6. >> FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working >> before dealing with certs). >> >> >> >> Any help is appreciated. >> >> >> >> Thanks, >> >> -Chris >> >> >> >> >> >> >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From piolet.y at gmail.com Sun Oct 11 22:41:36 2015 From: piolet.y at gmail.com (Youenn PIOLET) Date: Mon, 12 Oct 2015 00:41:36 +0200 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA In-Reply-To: References: Message-ID: Hi Chris, First, to be sure were on the same page: Without IPA, to make CIFS users authenticate against directory in a classic LDAP implementation, you need to extend your LDAP tree with Samba schema. The FreeNAS documentation is a bit light on this subjet and previous FreeNAS versions (stable 9.3 included) used to mess up rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your 9.2 version. Wrote some messy stuff about it here: https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md To make CIFS users authenticate or FreeIPA recent versions (I only tried with 4.1), I suggest you to start by reading some of our investigations in this thread: [Freeipa-users] Ubuntu Samba Server Auth against IPA https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 When we discuss about this in august, I've spend almost a week trying to make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without fully understand why it didn't work, and moved our CIFS to a dedicated Centos server. Matt arrived with a similar situation in Ubuntu. To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default with ldapsam.so module. FreeIPA developpers have built a AD trust exchange possibility with a custom ipasam module that isn't compiled yet for Ubuntu or FreeNAS. This module gives the possibility to use IPA AD trust components (e.g. special schema in IPA's directory managing user/group NT SID) If you can't compile the module for FreeNAS / FreeBSD, you may need to extend 365directory with Samba schema. You will need to find a way to generate the new attributes when adding users or groups in FreeIPA, and a way to store password in a CIFS/NT understandable way. I don't suggest you to follow this dark path. You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) Good luck in your experimentations, I hope you will succeed! -- Youenn Piolet piolet.y at gmail.com 2015-10-11 2:06 GMT+02:00 Chris Tobey : > Hi Everyone, > > > I have a functioning FreeIPA server that manages all my users and I would > like to also use it for my FreeNAS CIFS shares to authenticate against. > > Does anyone know what needs to be run on both servers to get this working? > I believe it has something to do with Samba properties on the FreeIPA side. > > > > I had tried asking the FreeNAS forums but they were of no help ( > https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/ > ). > > > > I have seen similar requests and success stories, but no actual steps on > how to do it. > > Info: > FreeIPA v3.0.0-42 running on CentOS 6.6. > FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working > before dealing with certs). > > > > Any help is appreciated. > > > > Thanks, > > -Chris > > > > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranger at opennms.org Mon Oct 12 01:39:47 2015 From: ranger at opennms.org (Benjamin Reed) Date: Sun, 11 Oct 2015 21:39:47 -0400 Subject: [Freeipa-users] import debian (salted SHA-512) password In-Reply-To: <561A9572.7000809@opennms.org> References: <561A9572.7000809@opennms.org> Message-ID: <561B0F63.3070905@opennms.org> On 10/11/15 12:59 PM, Benjamin Reed wrote: > ...but I'm not sure exactly what format to use to import a > "$6$salt$hash" style password from an existing debian system. Just a note for future folks trying to do this, I was able to do it by enabling adding users with {CRYPT}: ipa config-mod --enable-migration=1 ipa user-add \ --first=John --last=Doe \ --setattr userPassword='{CRYPT}$6$salt$hash' john_doe Now I just need them to ssh in once to initialize kerberos passwords, right? From jhrozek at redhat.com Mon Oct 12 09:47:11 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 12 Oct 2015 11:47:11 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: <20151007080241.GP3048@hendrix> Message-ID: <20151012094711.GU8948@hendrix> On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > I increased the log level in every SSSD section to 6 and got following output, hope that helps. > > KRB5_CHILD.LOG: https://s.mit42.de/IR6tu All is OK here.. > > SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl So the interesting part is that the first try doesn't match any rules for the user: (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=+*)))] (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [f.zoske at de.eu.local] While the second does: (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))] (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for [f.zoske at de.eu.local] It would be interesting to see the dump of the cache from when 0 rules are returned. I suspect the user's membership wouldn't be correct, which might be because of the bug I linked earlier. > > SSSD_IPA-LX.COM: https://s.mit42.de/frBvx There are some failures here: (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=*] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) But I think this is a really minor bug we fixed later where we marked requests as failed if they simply didn't find anything. If this works without issues: $ sss_cache -u f.zoske at de.eu.local $ getent passwd f.zoske at de.eu.local Then you can ignore those.. From APtashnik at cccis.com Mon Oct 12 17:21:24 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 17:21:24 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 Message-ID: Hello IPA Server Team, We have IPA server cluster on RHEL 7.1 and IPA version 4.1.0 and planning to upgrade to 4.2.1. What are correct steps doing so? Wiki (http://www.freeipa.org/page/Upgrade#FreeIPA_4.1.x_or_older )shows: FreeIPA 4.1.x or older # ipa-ldap-updater --upgrade # ipa-upgradeconfig But I have a feeling that there might be some prerequisites that is a common knowledge that was not mentioned and I?m not aware of? Are there any steps that needs to be completed before I execute above commands? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From APtashnik at cccis.com Mon Oct 12 18:17:12 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 18:17:12 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 Message-ID: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> Also I don?t see IPA server 4.2.1 in RHEL repository, is it already available? [root at sever]# yum list ipa-server ipa-server.x86_64 4.1.0-18.el7_1.4 @rhui-REGION-rhel-server-releases [root at server]# Regards, Andrey Ptashnik From: > on behalf of Andrey Ptashnik Date: Monday, October 12, 2015 at 12:21 PM To: "freeipa-users at redhat.com" Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 Hello IPA Server Team, We have IPA server cluster on RHEL 7.1 and IPA version 4.1.0 and planning to upgrade to 4.2.1. What are correct steps doing so? Wiki (http://www.freeipa.org/page/Upgrade#FreeIPA_4.1.x_or_older )shows: FreeIPA 4.1.x or older # ipa-ldap-updater --upgrade # ipa-upgradeconfig But I have a feeling that there might be some prerequisites that is a common knowledge that was not mentioned and I?m not aware of? Are there any steps that needs to be completed before I execute above commands? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Oct 12 18:26:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Oct 2015 21:26:22 +0300 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> Message-ID: <20151012182622.GD5076@redhat.com> On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >Also I don?t see IPA server 4.2.1 in RHEL repository, is it already available? > >[root at sever]# yum list ipa-server >ipa-server.x86_64 4.1.0-18.el7_1.4 @rhui-REGION-rhel-server-releases >[root at server]# It is available already as part of RHEL 7.2 beta: http://red.ht/1i65UND -- / Alexander Bokovoy From APtashnik at cccis.com Mon Oct 12 18:42:27 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 18:42:27 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <20151012182622.GD5076@redhat.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <20151012182622.GD5076@redhat.com> Message-ID: <3F815ACF-6E38-47FA-87AD-8FE6770DC580@cccis.com> I see that RHEL 7.2 relase date is still ?TBA?. Are there any plans to make newer versions of IPA sever sooner than RHEL 7.2? Regards, Andrey Ptashnik On 10/12/15, 1:26 PM, "Alexander Bokovoy" wrote: >On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >>Also I don?t see IPA server 4.2.1 in RHEL repository, is it already available? >> >>[root at sever]# yum list ipa-server >>ipa-server.x86_64 4.1.0-18.el7_1.4 @rhui-REGION-rhel-server-releases >>[root at server]# >It is available already as part of RHEL 7.2 beta: http://red.ht/1i65UND > >-- >/ Alexander Bokovoy From rcritten at redhat.com Mon Oct 12 18:44:20 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2015 14:44:20 -0400 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> Message-ID: <561BFF84.4060408@redhat.com> Andrey Ptashnik wrote: > Also I don?t see IPA server 4.2.1 in RHEL repository, is it already > available? 4.2 (plus patches) is planned for RHEL 7.2. A beta is available today. > > [root at sever]# yum list ipa-server > ipa-server.x86_64 4.1.0-18.el7_1.4 @rhui-REGION-rhel-server-releases > [root at server]# The upgrade is automatic once new packages are installed. rob > > Regards, > > Andrey Ptashnik > > > From: > on behalf of Andrey Ptashnik > Date: Monday, October 12, 2015 at 12:21 PM > To: "freeipa-users at redhat.com " > Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 > > Hello IPA Server Team, > > We have IPA server cluster on RHEL 7.1 and IPA version 4.1.0 and > planning to upgrade to 4.2.1. > > What are correct steps doing so? > > Wiki (http://www.freeipa.org/page/Upgrade#FreeIPA_4.1.x_or_older )shows: > FreeIPA 4.1.x or older > # ipa-ldap-updater --upgrade > # ipa-upgradeconfig > > But I have a feeling that there might be some prerequisites that is a > common knowledge that was not mentioned and I?m not aware of Are there > any steps that needs to be completed before I execute above commands? > > Regards, > > Andrey Ptashnik > > > > From APtashnik at cccis.com Mon Oct 12 19:00:11 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 19:00:11 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <561BFF84.4060408@redhat.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> Message-ID: <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> I we have a production environment, is it a safe move to upgrade to 7.2 Beta? And then still question remains what are correct steps to go from 4.1.0 to 4.2.0? Regards, Andrey Ptashnik On 10/12/15, 1:44 PM, "Rob Crittenden" wrote: >Andrey Ptashnik wrote: >> Also I don?t see IPA server 4.2.1 in RHEL repository, is it already >> available? > >4.2 (plus patches) is planned for RHEL 7.2. A beta is available today. > >> >> [root at sever]# yum list ipa-server >> ipa-server.x86_64 4.1.0-18.el7_1.4 @rhui-REGION-rhel-server-releases >> [root at server]# > >The upgrade is automatic once new packages are installed. > >rob > >> >> Regards, >> >> Andrey Ptashnik >> >> >> From: > > on behalf of Andrey Ptashnik >> Date: Monday, October 12, 2015 at 12:21 PM >> To: "freeipa-users at redhat.com " >> Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 >> >> Hello IPA Server Team, >> >> We have IPA server cluster on RHEL 7.1 and IPA version 4.1.0 and >> planning to upgrade to 4.2.1. >> >> What are correct steps doing so? >> >> Wiki (http://www.freeipa.org/page/Upgrade#FreeIPA_4.1.x_or_older )shows: >> FreeIPA 4.1.x or older >> # ipa-ldap-updater --upgrade >> # ipa-upgradeconfig >> >> But I have a feeling that there might be some prerequisites that is a >> common knowledge that was not mentioned and I?m not aware of? Are there >> any steps that needs to be completed before I execute above commands? >> >> Regards, >> >> Andrey Ptashnik >> >> >> >> > From abokovoy at redhat.com Mon Oct 12 19:10:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Oct 2015 22:10:33 +0300 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> Message-ID: <20151012191033.GE5076@redhat.com> On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >I we have a production environment, is it a safe move to upgrade to 7.2 Beta? Beta is for testing new features, not for production yet. >And then still question remains what are correct steps to go from 4.1.0 to 4.2.0? As Rob said, you do package updates and as part of that process an upgrade will be done. There is no specific upgrade path instructions between 4.1 and 4.2, unlike between 3.0 and 3.3+. -- / Alexander Bokovoy From APtashnik at cccis.com Mon Oct 12 19:43:32 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 19:43:32 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <20151012191033.GE5076@redhat.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com> Message-ID: <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> I see, so your best advice is to wait for official release of 7.2 and upgrade all at once even if I need just a few simple fixes like ?search for non-admin users? and etc?? Are there any approximate timeline for 7.2 release? Regards, Andrey Ptashnik On 10/12/15, 2:10 PM, "Alexander Bokovoy" wrote: >On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >>I we have a production environment, is it a safe move to upgrade to 7.2 Beta? >Beta is for testing new features, not for production yet. > >>And then still question remains what are correct steps to go from 4.1.0 to 4.2.0? >As Rob said, you do package updates and as part of that process an >upgrade will be done. There is no specific upgrade path instructions >between 4.1 and 4.2, unlike between 3.0 and 3.3+. > >-- >/ Alexander Bokovoy From John.Hoffmaster at dish.com Mon Oct 12 19:46:07 2015 From: John.Hoffmaster at dish.com (Hoffmaster, John) Date: Mon, 12 Oct 2015 13:46:07 -0600 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question Message-ID: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> Hi, The company I work for uses AD 2008R2 DC to resolve requests for Unix/Linux servers in various environments, under one domain example.com, with the Realm EXAMPLE.COM ? Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a name server and forwarding all DNS requests to the windows DC's and still keep everything in the example.com domain without creating a child domain like ipa.example.com ? http://www.freeipa.org/page/Active_Directory_trust_setup Add for RedHat 7, use hostnamectl set-hostname ipa.example.com and change the install IPA server command to ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com --realm=example.com --setup-dns --forwarder=AD_ipaddress Thanks, John Hoffmaster Enterprise Systems Unix/Linux Dish Network LLC. From Andy.Thompson at e-tcc.com Mon Oct 12 20:13:29 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Mon, 12 Oct 2015 20:13:29 +0000 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question In-Reply-To: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> References: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> Message-ID: > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Hoffmaster, John > Sent: Monday, October 12, 2015 3:46 PM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question > > Hi, > > The company I work for uses AD 2008R2 DC to resolve requests for > Unix/Linux servers in various environments, under one domain > example.com, with the Realm EXAMPLE.COM ? > > Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a > name server and forwarding all DNS requests to the windows DC's and still > keep everything in the example.com domain without creating a child domain > like ipa.example.com ? > > http://www.freeipa.org/page/Active_Directory_trust_setup > > Add for RedHat 7, use hostnamectl set-hostname ipa.example.com > > and > change the install IPA server command to > > ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - > -realm=example.com --setup-dns --forwarder=AD_ipaddress > > Thanks, > No. The IPA domain has to be different than the AD domain. -andy From abokovoy at redhat.com Mon Oct 12 20:19:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Oct 2015 23:19:06 +0300 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com> <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> Message-ID: <20151012201906.GF5076@redhat.com> On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >I see, so your best advice is to wait for official release of 7.2 and >upgrade all at once even if I need just a few simple fixes like ?search >for non-admin users? and etc?? > >Are there any approximate timeline for 7.2 release? "When it will be ready" would be a typical answer here. If you need any advice on Red Hat Enterprise Linux release timeline from Red Hat, talk to your Red Hat representative. There are also defined processes by Red Hat support on how to request updates, they are beyond of what FreeIPA upstream community mailing list could do. Hope this helps. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Oct 12 20:20:27 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Oct 2015 23:20:27 +0300 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question In-Reply-To: References: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> Message-ID: <20151012202027.GG5076@redhat.com> On Mon, 12 Oct 2015, Andy Thompson wrote: > > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >> bounces at redhat.com] On Behalf Of Hoffmaster, John >> Sent: Monday, October 12, 2015 3:46 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question >> >> Hi, >> >> The company I work for uses AD 2008R2 DC to resolve requests for >> Unix/Linux servers in various environments, under one domain >> example.com, with the Realm EXAMPLE.COM ? >> >> Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a >> name server and forwarding all DNS requests to the windows DC's and still >> keep everything in the example.com domain without creating a child domain >> like ipa.example.com ? >> >> http://www.freeipa.org/page/Active_Directory_trust_setup >> >> Add for RedHat 7, use hostnamectl set-hostname ipa.example.com >> >> and >> change the install IPA server command to >> >> ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - >> -realm=example.com --setup-dns --forwarder=AD_ipaddress >> >> Thanks, >> > >No. The IPA domain has to be different than the AD domain. This is true for any two separate Active Directory forests, and as IPA represents itself as a separate AD forest for the trust relationship, it is forced to follow Active Directory requirements. -- / Alexander Bokovoy From alex.williams at brighter-technology.com Mon Oct 12 20:30:08 2015 From: alex.williams at brighter-technology.com (Alex Williams) Date: Mon, 12 Oct 2015 21:30:08 +0100 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <20151012201906.GF5076@redhat.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com> <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> <20151012201906.GF5076@redhat.com> Message-ID: <561C1850.8090708@brighter-technology.com> On 12/10/15 21:19, Alexander Bokovoy wrote: > On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >> I see, so your best advice is to wait for official release of 7.2 and >> upgrade all at once even if I need just a few simple fixes like ?search >> for non-admin users? and etc?? >> >> Are there any approximate timeline for 7.2 release? > "When it will be ready" would be a typical answer here. > > If you need any advice on Red Hat Enterprise Linux release timeline from > Red Hat, talk to your Red Hat representative. There are also defined > processes by Red Hat support on how to request updates, they are beyond > of what FreeIPA upstream community mailing list could do. > > Hope this helps. Having just asked RedHat this very question, their response is that there are work-around fixes for the admin search bug in the 7.2 release, coming soon and permanent fixes in the 7.3 release which will follow. Essentially, hang tight, log in to the UI as 'admin' for now if you really need to search, or drop to the command line, kinit and search from there and when the 7.2 release comes out of beta, upgrade your servers, so that you can log in to the UI as you and search instead. Hope this helps. From APtashnik at cccis.com Mon Oct 12 21:52:57 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Mon, 12 Oct 2015 21:52:57 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <561C1850.8090708@brighter-technology.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com> <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> <20151012201906.GF5076@redhat.com> <561C1850.8090708@brighter-technology.com> Message-ID: <9B2E4CF6-A278-47E4-A7EE-8AA243BC347C@cccis.com> Alex, Thank you for your answer! I think I?m now clear with the roadmap. Regards, Andrey Ptashnik On 10/12/15, 3:30 PM, "Alex Williams" wrote: >On 12/10/15 21:19, Alexander Bokovoy wrote: >> On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >>> I see, so your best advice is to wait for official release of 7.2 and >>> upgrade all at once even if I need just a few simple fixes like ?search >>> for non-admin users? and etc?? >>> >>> Are there any approximate timeline for 7.2 release? >> "When it will be ready" would be a typical answer here. >> >> If you need any advice on Red Hat Enterprise Linux release timeline from >> Red Hat, talk to your Red Hat representative. There are also defined >> processes by Red Hat support on how to request updates, they are beyond >> of what FreeIPA upstream community mailing list could do. >> >> Hope this helps. >Having just asked RedHat this very question, their response is that >there are work-around fixes for the admin search bug in the 7.2 release, >coming soon and permanent fixes in the 7.3 release which will follow. >Essentially, hang tight, log in to the UI as 'admin' for now if you >really need to search, or drop to the command line, kinit and search >from there and when the 7.2 release comes out of beta, upgrade your >servers, so that you can log in to the UI as you and search instead. > >Hope this helps. From simo at redhat.com Tue Oct 13 00:35:46 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Oct 2015 20:35:46 -0400 Subject: [Freeipa-users] import debian (salted SHA-512) password In-Reply-To: <561B0F63.3070905@opennms.org> References: <561A9572.7000809@opennms.org> <561B0F63.3070905@opennms.org> Message-ID: <561C51E2.6080006@redhat.com> On 11/10/15 21:39, Benjamin Reed wrote: > On 10/11/15 12:59 PM, Benjamin Reed wrote: >> ...but I'm not sure exactly what format to use to import a >> "$6$salt$hash" style password from an existing debian system. > > Just a note for future folks trying to do this, I was able to do it by > enabling adding users with {CRYPT}: > > ipa config-mod --enable-migration=1 > ipa user-add \ > --first=John --last=Doe \ > --setattr userPassword='{CRYPT}$6$salt$hash' john_doe > > Now I just need them to ssh in once to initialize kerberos passwords, right? That's all you need if you are inm migration mode and the server they log in is configured with SSSD. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Oct 13 00:42:18 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 13 Oct 2015 00:42:18 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: References: Message-ID: Hi, You want to move away from the IPA provided by the redhat channel? regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Andrey Ptashnik Sent: Tuesday, 13 October 2015 6:21 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 Hello IPA Server Team, We have IPA server cluster on RHEL 7.1 and IPA version 4.1.0 and planning to upgrade to 4.2.1. What are correct steps doing so? Wiki (http://www.freeipa.org/page/Upgrade#FreeIPA_4.1.x_or_older )shows: [http://www.freeipa.org/images/freeipa/freeipa-logo-small.png] Upgrade - FreeIPA Guidance. When there is a new updated FreeIPA server version you want to upgrade to, in most cases it is possible to simply update the underlying operating system and ... Read more... FreeIPA 4.1.x or older # ipa-ldap-updater --upgrade # ipa-upgradeconfig But I have a feeling that there might be some prerequisites that is a common knowledge that was not mentioned and I'm not aware of... Are there any steps that needs to be completed before I execute above commands? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Oct 13 00:46:01 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 13 Oct 2015 00:46:01 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com>, <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> Message-ID: Hi, IPA is a complex beast, you would be brave/foolish to upgrade it outside of the Redhat support matrix. Also I would / will wait 1~2 months before upgrading to 7.2 so any serious bugs/issues are found by someone else. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Andrey Ptashnik Sent: Tuesday, 13 October 2015 8:43 a.m. To: Alexander Bokovoy Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 I see, so your best advice is to wait for official release of 7.2 and upgrade all at once even if I need just a few simple fixes like ?search for non-admin users? and etc?? Are there any approximate timeline for 7.2 release? Regards, Andrey Ptashnik On 10/12/15, 2:10 PM, "Alexander Bokovoy" wrote: >On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >>I we have a production environment, is it a safe move to upgrade to 7.2 Beta? >Beta is for testing new features, not for production yet. > >>And then still question remains what are correct steps to go from 4.1.0 to 4.2.0? >As Rob said, you do package updates and as part of that process an >upgrade will be done. There is no specific upgrade path instructions >between 4.1 and 4.2, unlike between 3.0 and 3.3+. > >-- >/ 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 From f.zoske at euroimmun.de Tue Oct 13 07:19:20 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Tue, 13 Oct 2015 07:19:20 +0000 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151012094711.GU8948@hendrix> References: <20151007080241.GP3048@hendrix> , <20151012094711.GU8948@hendrix> Message-ID: Hi Jakub, thanks for looking through the data. I can not access the bug you mentioned. I already created an account for Bugzilla, but so far nothing. In the second query there is a group which isn't present in the first one ((sudoUser=%ug_freeipa-administrators_int)). This is the IPA-equivalent of the AD-Group (ug_freeipa-administrators). AD -> IPA_EXT -> IPA_INT The second command you mentioned works and returns the correct passwd entry for my user. The first command ist not found on the client. Best regards, Fabian ________________________________________ From: Jakub Hrozek [jhrozek at redhat.com] Sent: Monday, October 12, 2015 11:47 To: Zoske, Fabian Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] SUDO does not always works on first try On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > I increased the log level in every SSSD section to 6 and got following output, hope that helps. > > KRB5_CHILD.LOG: https://s.mit42.de/IR6tu All is OK here.. > > SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl So the interesting part is that the first try doesn't match any rules for the user: (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=+*)))] (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [f.zoske at de.eu.local] While the second does: (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))] (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for [f.zoske at de.eu.local] It would be interesting to see the dump of the cache from when 0 rules are returned. I suspect the user's membership wouldn't be correct, which might be because of the bug I linked earlier. > > SSSD_IPA-LX.COM: https://s.mit42.de/frBvx There are some failures here: (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=*] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) But I think this is a really minor bug we fixed later where we marked requests as failed if they simply didn't find anything. If this works without issues: $ sss_cache -u f.zoske at de.eu.local $ getent passwd f.zoske at de.eu.local Then you can ignore those.. From jpazdziora at redhat.com Tue Oct 13 07:36:24 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 13 Oct 2015 09:36:24 +0200 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question In-Reply-To: References: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> Message-ID: <20151013073624.GC32648@redhat.com> On Mon, Oct 12, 2015 at 08:13:29PM +0000, Andy Thompson wrote: > > > The company I work for uses AD 2008R2 DC to resolve requests for > > Unix/Linux servers in various environments, under one domain > > example.com, with the Realm EXAMPLE.COM ? > > > > Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a > > name server and forwarding all DNS requests to the windows DC's and still > > keep everything in the example.com domain without creating a child domain > > like ipa.example.com ? > > > > http://www.freeipa.org/page/Active_Directory_trust_setup > > > > Add for RedHat 7, use hostnamectl set-hostname ipa.example.com > > > > and > > change the install IPA server command to > > > > ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - > > -realm=example.com --setup-dns --forwarder=AD_ipaddress > > No. The IPA domain has to be different than the AD domain. However, if the concern is more about users not wanting to see the ipa.example.com in servers' hostnames than the underlying technology, CNAMEs pointing to that IPA-managed domain can be used to present flat structure to users: server.example.com -> server.ipa.example.com -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Tue Oct 13 07:39:53 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Oct 2015 09:39:53 +0200 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question In-Reply-To: <20151012202027.GG5076@redhat.com> References: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> <20151012202027.GG5076@redhat.com> Message-ID: <561CB549.9070603@redhat.com> On 12.10.2015 22:20, Alexander Bokovoy wrote: > On Mon, 12 Oct 2015, Andy Thompson wrote: >> >> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>> bounces at redhat.com] On Behalf Of Hoffmaster, John >>> Sent: Monday, October 12, 2015 3:46 PM >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question >>> >>> Hi, >>> >>> The company I work for uses AD 2008R2 DC to resolve requests for >>> Unix/Linux servers in various environments, under one domain >>> example.com, with the Realm EXAMPLE.COM ? >>> >>> Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a >>> name server and forwarding all DNS requests to the windows DC's and still >>> keep everything in the example.com domain without creating a child domain >>> like ipa.example.com ? >>> >>> http://www.freeipa.org/page/Active_Directory_trust_setup >>> >>> Add for RedHat 7, use hostnamectl set-hostname ipa.example.com >>> >>> and >>> change the install IPA server command to >>> >>> ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - >>> -realm=example.com --setup-dns --forwarder=AD_ipaddress >>> >>> Thanks, >>> >> >> No. The IPA domain has to be different than the AD domain. > This is true for any two separate Active Directory forests, and as IPA > represents itself as a separate AD forest for the trust relationship, it > is forced to follow Active Directory requirements. In other words, IPA itself needs one separate domain for SRV records and other stuff. Client machines may have hostnames in different domains as long as there is 1:1 mapping between domain->REALM (AD/IPA). -- Petr^2 Spacek From abokovoy at redhat.com Tue Oct 13 08:46:13 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Oct 2015 11:46:13 +0300 Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question In-Reply-To: <561CB549.9070603@redhat.com> References: <10D3C1A8634D7D4F976EECC986087A4D0192D14116@MER2-EXCH07P1.echostar.com> <20151012202027.GG5076@redhat.com> <561CB549.9070603@redhat.com> Message-ID: <20151013084613.GN5076@redhat.com> On Tue, 13 Oct 2015, Petr Spacek wrote: >On 12.10.2015 22:20, Alexander Bokovoy wrote: >> On Mon, 12 Oct 2015, Andy Thompson wrote: >>> >>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- >>>> bounces at redhat.com] On Behalf Of Hoffmaster, John >>>> Sent: Monday, October 12, 2015 3:46 PM >>>> To: freeipa-users at redhat.com >>>> Subject: [Freeipa-users] Free IPA to Microsoft AD 2008R2 trust question >>>> >>>> Hi, >>>> >>>> The company I work for uses AD 2008R2 DC to resolve requests for >>>> Unix/Linux servers in various environments, under one domain >>>> example.com, with the Realm EXAMPLE.COM ? >>>> >>>> Is it possible to use Freeipa 4.1.0, with an g AD-Trust with only itself as a >>>> name server and forwarding all DNS requests to the windows DC's and still >>>> keep everything in the example.com domain without creating a child domain >>>> like ipa.example.com ? >>>> >>>> http://www.freeipa.org/page/Active_Directory_trust_setup >>>> >>>> Add for RedHat 7, use hostnamectl set-hostname ipa.example.com >>>> >>>> and >>>> change the install IPA server command to >>>> >>>> ipa-server-install -a mypassword1 -p mypassword2 --domain=example.com - >>>> -realm=example.com --setup-dns --forwarder=AD_ipaddress >>>> >>>> Thanks, >>>> >>> >>> No. The IPA domain has to be different than the AD domain. >> This is true for any two separate Active Directory forests, and as IPA >> represents itself as a separate AD forest for the trust relationship, it >> is forced to follow Active Directory requirements. > >In other words, IPA itself needs one separate domain for SRV records and other >stuff. > >Client machines may have hostnames in different domains as long as there is >1:1 mapping between domain->REALM (AD/IPA). Yep. Let's say explicitly: - IPA machines cannot belong to any domain of AD forest -- in terms of DNS this means they cannot have A/AAAA records in any AD domain's DNS zone; - IPA machines may have CNAMEs in an AD domain's DNS zone that point to A/AAAA records in IPA DNS zones. If you follow these two rules, you'll have single sign-on working between IPA and AD through the cross-forest trust. -- / Alexander Bokovoy From mkosek at redhat.com Tue Oct 13 10:17:04 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Oct 2015 12:17:04 +0200 Subject: [Freeipa-users] import debian (salted SHA-512) password In-Reply-To: <561C51E2.6080006@redhat.com> References: <561A9572.7000809@opennms.org> <561B0F63.3070905@opennms.org> <561C51E2.6080006@redhat.com> Message-ID: <561CDA20.30805@redhat.com> On 10/13/2015 02:35 AM, Simo Sorce wrote: > On 11/10/15 21:39, Benjamin Reed wrote: >> On 10/11/15 12:59 PM, Benjamin Reed wrote: >>> ...but I'm not sure exactly what format to use to import a >>> "$6$salt$hash" style password from an existing debian system. >> >> Just a note for future folks trying to do this, I was able to do it by >> enabling adding users with {CRYPT}: >> >> ipa config-mod --enable-migration=1 >> ipa user-add \ >> --first=John --last=Doe \ >> --setattr userPassword='{CRYPT}$6$salt$hash' john_doe >> >> Now I just need them to ssh in once to initialize kerberos passwords, right? > > That's all you need if you are inm migration mode and the server they log in is > configured with SSSD. > > Simo. ... or use the Web service: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html#webpage-pwd-migr From peljasz at yahoo.co.uk Tue Oct 13 10:23:23 2015 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 13 Oct 2015 11:23:23 +0100 Subject: [Freeipa-users] ipa-server-install fails at last leg? Message-ID: <561CDB9B.2000401@yahoo.co.uk> dear all, my first try at ipa server, I get this when install fails: [15/16]: restarting httpd [error] CalledProcessError: Command ''/bin/systemctl' 'restart' 'httpd.service'' returned non-zero exit status 1 Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command ''/bin/systemctl' 'restart' 'httpd.service'' returned non-zero exit status 1 then I can see that httpd fails to restart for: Starting The Apache HTTP Server... (98)Address already in use: AH00072: make_sock: could not bind to address [::]:8443 (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:8443 no listening sockets available, shutting down and port is bound by: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD pkiuser 5330 1 1 2128224 494604 5 11:00 ? 00:00:16 java -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -DRESTEASY_LIB=/usr/share/java/resteasy-base -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.security.manager -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy org.apache.catalina.startup.Bootstrap start and this is as you can see, the process, the result of the ipa-server-install itself. Any suggestions as what is the problem there? many thanks. From mabarkdoll at gmail.com Tue Oct 13 05:01:42 2015 From: mabarkdoll at gmail.com (Michael Barkdoll) Date: Tue, 13 Oct 2015 00:01:42 -0500 Subject: [Freeipa-users] Looking to test one-way trust Message-ID: Hello, I've successfully setup a two-way trust between FreeIPA and AD. My understanding is that FreeIPA is currently or planning to support Global Cataloging. I'm looking to implement a one-way trust between AD and FreeIPA to remove security concerns with my AD administrators in my organization. My questions are as follows: 1) Is there a guide/post that I can follow for setting up a one-way trust between FreeIPA and AD? 2) What type of trust is being created on the AD side, is it a cross-forest outgoing trust to the FreeIPA server from the AD server? Thanks for your kind time, Michael Barkdoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Oct 13 12:45:15 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Oct 2015 15:45:15 +0300 Subject: [Freeipa-users] Looking to test one-way trust In-Reply-To: References: Message-ID: <20151013124515.GS5076@redhat.com> On Tue, 13 Oct 2015, Michael Barkdoll wrote: >Hello, I've successfully setup a two-way trust between FreeIPA and AD. My >understanding is that FreeIPA is currently or planning to support Global >Cataloging. I'm looking to implement a one-way trust between AD and >FreeIPA to remove security concerns with my AD administrators in my >organization. You didn't specify what FreeIPA version you are talking about. One-way trust is implemented in FreeIPA 4.2 (4.2.2 right now, RHEL 7.2 beta has it under 'ipa-server-4.2.0-*' package). >My questions are as follows: >1) Is there a guide/post that I can follow for setting up a one-way trust >between FreeIPA and AD? In FreeIPA 4.2+ one-way trust is the default. So if you want to establish trust and don't specify --bi-directional flag, you are establishing one-way trust. For earlier-established trust relationship, you need to re-run 'ipa trust-add' again to convert to one-way. >2) What type of trust is being created on the AD side, is it a cross-forest >outgoing trust to the FreeIPA server from the AD server? Yes. Instead of creating both legs of the trust, only one of them is created. -- / Alexander Bokovoy From wirelessben at gmail.com Tue Oct 13 13:15:32 2015 From: wirelessben at gmail.com (Ben Francis) Date: Tue, 13 Oct 2015 09:15:32 -0400 Subject: [Freeipa-users] OAuth2 Message-ID: Is it supported? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Oct 13 14:02:38 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2015 10:02:38 -0400 Subject: [Freeipa-users] OAuth2 In-Reply-To: References: Message-ID: <561D0EFE.5010201@redhat.com> Ben Francis wrote: > Is it supported? No but you should be able to use IPA as an identity backend for an OAuth2 (or other Federation) provider. rob From Christopher.Gronde at fincen.gov Tue Oct 13 14:50:21 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 13 Oct 2015 14:50:21 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> <56168D80.3070408@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> <5616AD08.4020108@redhat.com> Message-ID: <2909CC7109523F4BA968E7A201471B77182711E4@hqexdb01.hqfincen.gov> Still having issues...if I can still have assistance with this getcert list Number of certificates and requests being tracked: 3. Request ID '20150922143354': status: NEED_TO_SUBMIT stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=IPA RA,O=ITMODEV.GOV expires: 2013-10-09 11:45:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20151007150853': status: CA_UNREACHABLE ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm 'ITMODEV.GOV'. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20150921154714': status: NEED_CA stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-ITMODEV-GOV',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-ITMODEV-GOV',nickname='Server-Cert',token='NSS Certificate DB' issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV track: yes auto-renew: yes -----Original Message----- From: Gronde, Christopher (Contractor) Sent: Thursday, October 08, 2015 2:06 PM To: 'Rob Crittenden' Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert # ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ipa service was not running...I attempted to start it. # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl Ntpd is still stopped but date was back to today so I changed the date back to 9/21 and started ipa services # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [ OK ] ]# service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 1:51 PM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > First commend came back: > > ]# grep internal= /var/lib/pki-ca/conf/password.conf > grep: /var/lib/pki-ca/conf/password.conf: No such file or directory > > There is no pki-ca dir on this server That simplifies things a bit. The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that it has a CSR and it doesn't. This CA will attempt to fetch an update cert from LDAP. See what is available with: % ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov I'm just assuming your IPA Instance isn't actually running, right? You'll probably need to go back in time to have any chance of this working. Apache would be most vocal about not being able to start with an expired cert and offer a means to workaround it (going back in time is a better solution). This is of course assuming that the other IPA master(s) actually have renewed certificates themselves. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 11:37 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> When I ran "getcert list" rather than "ipa-getcert list" I get the following: >> >> # getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=IPA RA,O=ITMODEV.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. > > In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. > > NOTE: I haven't tested these commands on a live system but I think it is right. > > # grep internal= /var/lib/pki-ca/conf/password.conf > > The series of numbers is the PIN you need next. > > # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' > done > > The tracking is incorrect for ipaCert so you'll need to try to fix it with: > > # getcert start-tracking -i 20150922143354 -C > /usr/lib64/ipa/certmonger/renew_ra_cert > > And finally track the 389-ds certs: > > # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' > # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' > > So now theoretically getcert list will show all 8 certificates as being tracked. > > Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. > In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. > > # service pki-cad restart > > Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . > > Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. > > If that works run ipactl stop, bring time forward, ipactl start. > > rob > > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 10:33 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Currently running ipa-server-3.0.0-47.el6.x86_64 >>> >>> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. >> >> You should be tracking 8 certificates. The output of `getcert list` should look something like: >> >> Number of certificates and requests being tracked: 8. >> Request ID '20150102143352': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Audit,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:08 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143353': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143354': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143355': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=IPA RA,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> Request ID '20150102143356': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> Request ID '20150102143410': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:09 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> track: yes >> auto-renew: yes >> Request ID '20150102143452': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA >> track: yes >> auto-renew: yes >> Request ID '20150102143632': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N >> SS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:36:32 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Thursday, October 08, 2015 9:49 AM >>> To: Gronde, Christopher (Contractor) >>> ; Alexander Bokovoy >>> >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Now I am getting CA_UNREACHABLE >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>>> /usr/lib64/ipa/certmonger/restart_httpd >>>> Resubmitting "20151007150853" to "IPA". >>>> >>>> # ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: CA_UNREACHABLE >>>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>> >>> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >>> >>> What version of IPA is this? rpm -q ipa-server >>> >>> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >>> >>> rob >>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 9:00 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> Hi, >>>> >>>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> Thank you for your response! >>>> Do not respond directly, send your emails to the mailing list, please. >>>> >>>>> Yes "getent passwd admin" does work >>>>> >>>>> # getent passwd admin >>>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>>> >>>>> The second not returned: >>>>> >>>>> # ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> >>>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates >>>>> and requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: MONITORING >>>>> ca-error: Unable to determine principal name for signing request. >>>> So it doesn't know whom to map the cert to. >>>> >>>> When re-submitting the request with ipa-getcert, add >>>> -K HTTP/comipa02.itmodev.gov >>>> >>>> While at it, I've looked at my test setup and I can see that your >>>> configuration below lacks restart of httpd after certificate was >>>> rotated: >>>> -C /usr/lib64/ipa/certmonger/restart_httpd >>>> >>>> >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>>> expires: 2015-09-23 17:46:26 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>>> >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Thursday, October 08, 2015 2:22 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>>> working....issues manually renewing Server-Cert >>>>> >>>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>>> I am new to FreeIPA and have inherited two IPA servers not sure >>>>>> if one is a master/slave or how they are different. I will try >>>>>> to give some pertinent outputs below of some of the things I am >>>>>> seeing. I know the Server-Cert is expired but can't figure out >>>>>> how to renew it. There also appears to be Kerberos >>>>>> authentication issues going on as I'm trying to fix it. >>>>>> >>>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>>> certificates and requests being tracked: 2. >>>>>> Request ID '20150922143354': >>>>>> status: NEED_TO_SUBMIT >>>>>> stuck: no >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>>> issuer: CN=Certificate Authority,O=.GOV >>>>>> subject: CN=IPA RA,O=.GOV >>>>>> expires: 2013-10-09 11:45:01 UTC >>>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>>> pre-save command: >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>> track: yes >>>>>> auto-renew: yes >>>>>> >>>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>>> >>>>>> >>>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>>> Certificate: >>>>>> Data: >>>>>> Version: 3 (0x2) >>>>>> Serial Number: 166 (0xa6) >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>>> Validity: >>>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>>> Subject Public Key Info: >>>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>>> RSA Public Key: >>>>>> Modulus: >>>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>>> Exponent: 65537 (0x10001) >>>>>> Signed Extensions: >>>>>> Name: Certificate Authority Key Identifier >>>>>> Key ID: >>>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>>> c3:13:4b:16 >>>>>> >>>>>> Name: Authority Information Access >>>>>> Method: PKIX Online Certificate Status Protocol >>>>>> Location: >>>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>>> >>>>>> Name: Certificate Key Usage >>>>>> Critical: True >>>>>> Usages: Digital Signature >>>>>> Non-Repudiation >>>>>> Key Encipherment >>>>>> Data Encipherment >>>>>> >>>>>> Name: Extended Key Usage >>>>>> TLS Web Server Authentication Certificate >>>>>> TLS Web Client Authentication Certificate >>>>>> >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Signature: >>>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>>> Fingerprint (SHA-256): >>>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>>> Fingerprint (SHA1): >>>>>> >>>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>>> >>>>>> Certificate Trust Flags: >>>>>> SSL Flags: >>>>>> User >>>>>> Email Flags: >>>>>> User >>>>>> Object Signing Flags: >>>>>> User >>>>>> >>>>>> #ipa-getkeytab -s compia02.itmodev.gov -p >>>>>> host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>>> So, let's start here. >>>>> >>>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>>> >>>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>>> #ipa-getcert list >>>>>> Number of certificates and requests being tracked: 2. >>>>>> Request ID '20151007150853': >>>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>>> 'Newly added request needs a PIN to read the key material' >>>>> >>>>>> stuck: yes >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> CA: IPA >>>>>> issuer: >>>>>> subject: >>>>>> expires: unknown >>>>>> pre-save command: >>>>>> post-save command: >>>>>> track: yes >>>>>> auto-renew: yes >>>>> >>>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>>> >>>>> ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >> >> > > From APtashnik at cccis.com Tue Oct 13 14:56:14 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Tue, 13 Oct 2015 14:56:14 +0000 Subject: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 In-Reply-To: References: <3FB405D0-3143-44F6-A43C-81769B15E1A7@cccis.com> <561BFF84.4060408@redhat.com> <6364E916-7690-43B1-8C21-BD93933B6E06@cccis.com> <20151012191033.GE5076@redhat.com> <74DE8D62-5BE7-4802-9E5F-FD32ECF7E111@cccis.com> Message-ID: <61677DCE-89CD-4E77-8741-07670BC80966@cccis.com> I usually try not to. On the other side I see that many important fixes are coming with major/minor releases, and trying to figure out my course of actions until fixes and/or release become available. Regards, Andrey Ptashnik On 10/12/15, 7:46 PM, "freeipa-users-bounces at redhat.com on behalf of Steven Jones" wrote: >Hi, > >IPA is a complex beast, you would be brave/foolish to upgrade it outside of the Redhat support matrix. > >Also I would / will wait 1~2 months before upgrading to 7.2 so any serious bugs/issues are found by someone else. > >regards > >Steven > >________________________________________ >From: freeipa-users-bounces at redhat.com on behalf of Andrey Ptashnik >Sent: Tuesday, 13 October 2015 8:43 a.m. >To: Alexander Bokovoy >Cc: freeipa-users at redhat.com >Subject: Re: [Freeipa-users] Correct upgrade steps for IPA server 4.1.0 > >I see, so your best advice is to wait for official release of 7.2 and upgrade all at once even if I need just a few simple fixes like ?search for non-admin users? and etc?? > >Are there any approximate timeline for 7.2 release? > >Regards, > >Andrey Ptashnik > > > > > >On 10/12/15, 2:10 PM, "Alexander Bokovoy" wrote: > >>On Mon, 12 Oct 2015, Andrey Ptashnik wrote: >>>I we have a production environment, is it a safe move to upgrade to 7.2 Beta? >>Beta is for testing new features, not for production yet. >> >>>And then still question remains what are correct steps to go from 4.1.0 to 4.2.0? >>As Rob said, you do package updates and as part of that process an >>upgrade will be done. There is no specific upgrade path instructions >>between 4.1 and 4.2, unlike between 3.0 and 3.3+. >> >>-- >>/ 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 > >-- >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 From Christopher.Gronde at fincen.gov Tue Oct 13 15:30:44 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Tue, 13 Oct 2015 15:30:44 +0000 Subject: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert In-Reply-To: <2909CC7109523F4BA968E7A201471B77182711E4@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B771826FB29@hqexdb01.hqfincen.gov> <20151008062135.GE19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC39@hqexdb01.hqfincen.gov> <20151008130024.GK19089@redhat.com> <2909CC7109523F4BA968E7A201471B771826FC69@hqexdb01.hqfincen.gov> <5616743D.8040108@redhat.com> <2909CC7109523F4BA968E7A201471B771826FCC7@hqexdb01.hqfincen.gov> <56167EB9.50407@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD1A@hqexdb01.hqfincen.gov> <56168D80.3070408@redhat.com> <2909CC7109523F4BA968E7A201471B771826FD98@hqexdb01.hqfincen.gov> <5616AD08.4020108@redhat.com> <2909CC7109523F4BA968E7A201471B77182711E4@hqexdb01.hqfincen.gov> Message-ID: <2909CC7109523F4BA968E7A201471B7718271206@hqexdb01.hqfincen.gov> So over the weekend time on the server changed back to normal so I set the time back again and tried to restart the ipa service and I get the following #service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV... [FAILED] *** Error: 1 instance(s) failed to start Failed to start Directory Service: Command '/sbin/service dirsrv start ' returned non-zero exit status 1 -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Gronde, Christopher (Contractor) Sent: Tuesday, October 13, 2015 10:50 AM To: Rob Crittenden Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Still having issues...if I can still have assistance with this getcert list Number of certificates and requests being tracked: 3. Request ID '20150922143354': status: NEED_TO_SUBMIT stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=IPA RA,O=ITMODEV.GOV expires: 2013-10-09 11:45:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20151007150853': status: CA_UNREACHABLE ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm 'ITMODEV.GOV'. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20150921154714': status: NEED_CA stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-ITMODEV-GOV',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-ITMODEV-GOV',nickname='Server-Cert',token='NSS Certificate DB' issuer: CN=Certificate Authority,O=ITMODEV.GOV subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV expires: 2015-09-23 17:46:26 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV track: yes auto-renew: yes -----Original Message----- From: Gronde, Christopher (Contractor) Sent: Thursday, October 08, 2015 2:06 PM To: 'Rob Crittenden' Cc: freeipa-users at redhat.com Subject: RE: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert # ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ipa service was not running...I attempted to start it. # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl Ntpd is still stopped but date was back to today so I changed the date back to 9/21 and started ipa services # service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [ OK ] ]# service ipa start Starting Directory Service Starting dirsrv: ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Shutting down dirsrv: ITMODEV-GOV... [ OK ] Aborting ipactl -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 08, 2015 1:51 PM To: Gronde, Christopher (Contractor) Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert Gronde, Christopher (Contractor) wrote: > First commend came back: > > ]# grep internal= /var/lib/pki-ca/conf/password.conf > grep: /var/lib/pki-ca/conf/password.conf: No such file or directory > > There is no pki-ca dir on this server That simplifies things a bit. The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that it has a CSR and it doesn't. This CA will attempt to fetch an update cert from LDAP. See what is available with: % ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov I'm just assuming your IPA Instance isn't actually running, right? You'll probably need to go back in time to have any chance of this working. Apache would be most vocal about not being able to start with an expired cert and offer a means to workaround it (going back in time is a better solution). This is of course assuming that the other IPA master(s) actually have renewed certificates themselves. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 08, 2015 11:37 AM > To: Gronde, Christopher (Contractor) ; > Alexander Bokovoy > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Certmonger and dogtag not > working....issues manually renewing Server-Cert > > Gronde, Christopher (Contractor) wrote: >> When I ran "getcert list" rather than "ipa-getcert list" I get the following: >> >> # getcert list >> Number of certificates and requests being tracked: 2. >> Request ID '20150922143354': >> status: NEED_TO_SUBMIT >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=IPA RA,O=ITMODEV.GOV >> expires: 2013-10-09 11:45:01 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> Request ID '20151007150853': >> status: CA_UNREACHABLE >> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates). >> stuck: no >> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=ITMODEV.GOV >> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV >> expires: 2015-09-23 17:46:26 UTC >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes > > I don't know how the certificates became un-tracked but the result is that the expiration date passed and I can only assume that they are all expired now. What is really strange is that someone poked at ipaCert last month, though that cert expired 2 years ago. The Apache cert is equally confusing as it has probably been renewed at least once given the date of ipaCert. > > In any case, the first thing to do is to see what the state of the other certs are. These will enable certmonger tracking of them. > > NOTE: I haven't tested these commands on a live system but I think it is right. > > # grep internal= /var/lib/pki-ca/conf/password.conf > > The series of numbers is the PIN you need next. > > # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"' > done > > The tracking is incorrect for ipaCert so you'll need to try to fix it with: > > # getcert start-tracking -i 20150922143354 -C > /usr/lib64/ipa/certmonger/renew_ra_cert > > And finally track the 389-ds certs: > > # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV' > # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C '/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' > > So now theoretically getcert list will show all 8 certificates as being tracked. > > Start with the 4 CA certificates and see when they expire. Stop ntpd if running, go back to when those are valid and try restarting the CA. You may have to go back *really* far given the expiration date of ipaCert. > In fact, to get things working you might have to go back, renew some of the certs, move forward to when those would expire last month and renew again. > > # service pki-cad restart > > Give it a minute to fully start then try the renewal either by restarting certmonger or for each of the CA subsystem certs run getcert resubmit -i . > > Assuming that worked next try to renew ipaCert. If that gets renewed then do the 3 remaining certs: Apache and the two 389-ds instances. > > If that works run ipactl stop, bring time forward, ipactl start. > > rob > > >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Thursday, October 08, 2015 10:33 AM >> To: Gronde, Christopher (Contractor) ; >> Alexander Bokovoy >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Certmonger and dogtag not >> working....issues manually renewing Server-Cert >> >> Gronde, Christopher (Contractor) wrote: >>> Currently running ipa-server-3.0.0-47.el6.x86_64 >>> >>> I have stopped ntpd and reset the date to Sept 21st. Yes I agree this has been baffling me for days. >> >> You should be tracking 8 certificates. The output of `getcert list` should look something like: >> >> Number of certificates and requests being tracked: 8. >> Request ID '20150102143352': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCer >> t cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Audit,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:08 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143353': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> eku: id-kp-OCSPSigning >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143354': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad >> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20150102143355': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=IPA RA,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert >> track: yes >> auto-renew: yes >> Request ID '20150102143356': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-renew-agent >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2016-12-22 14:33:07 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> Request ID '20150102143410': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:09 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> track: yes >> auto-renew: yes >> Request ID '20150102143452': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' >> ,token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:34:51 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA >> track: yes >> auto-renew: yes >> Request ID '20150102143632': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N >> SS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> subject: CN=ipa.example.com,O=EXAMPLE.COM >> expires: 2017-01-02 14:36:32 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> What is missing are the certs for 389-ds and for the CA itself. I'm guessing those are also expired/expiring. >> >> rob >> >>> >>> >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Thursday, October 08, 2015 9:49 AM >>> To: Gronde, Christopher (Contractor) >>> ; Alexander Bokovoy >>> >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>> working....issues manually renewing Server-Cert >>> >>> Gronde, Christopher (Contractor) wrote: >>>> Now I am getting CA_UNREACHABLE >>>> >>>> # ipa-getcert resubmit -i 20151007150853 -p >>>> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C >>>> /usr/lib64/ipa/certmonger/restart_httpd >>>> Resubmitting "20151007150853" to "IPA". >>>> >>>> # ipa-getcert list >>>> Number of certificates and requests being tracked: 2. >>>> Request ID '20151007150853': >>>> status: CA_UNREACHABLE >>>> ca-error: Error setting up ccache for "host" service on client using default keytab: Cannot contact any KDC for realm '.GOV'. >>>> stuck: no >>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>> CA: IPA >>>> issuer: CN=Certificate Authority,O=.GOV >>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>> expires: 2015-09-23 17:46:26 UTC >>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>> pre-save command: >>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>> track: yes >>>> auto-renew: yes >>> >>> What really baffles me is what happened to the original tracking for these certificates. Based on the original e-mail only 2 of the 8 are being tracked at all. >>> >>> What version of IPA is this? rpm -q ipa-server >>> >>> I'm guessing that the IPA services aren't running due to the expired certificates. You'll need to roll back the time to before Sept 22, at last, to get things up and running. >>> >>> rob >>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>> Sent: Thursday, October 08, 2015 9:00 AM >>>> To: Gronde, Christopher (Contractor) >>>> >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>> working....issues manually renewing Server-Cert >>>> >>>> Hi, >>>> >>>> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>> Thank you for your response! >>>> Do not respond directly, send your emails to the mailing list, please. >>>> >>>>> Yes "getent passwd admin" does work >>>>> >>>>> # getent passwd admin >>>>> admin:*:1278200000:1278200000:Administrator:/home/admin:/bin/bash >>>>> >>>>> The second not returned: >>>>> >>>>> # ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> >>>>> ]# ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA". >>>>> [root at comipa02 conf.d]# ipa-getcert list Number of certificates >>>>> and requests being tracked: 2. >>>>> Request ID '20151007150853': >>>>> status: MONITORING >>>>> ca-error: Unable to determine principal name for signing request. >>>> So it doesn't know whom to map the cert to. >>>> >>>> When re-submitting the request with ipa-getcert, add >>>> -K HTTP/comipa02.itmodev.gov >>>> >>>> While at it, I've looked at my test setup and I can see that your >>>> configuration below lacks restart of httpd after certificate was >>>> rotated: >>>> -C /usr/lib64/ipa/certmonger/restart_httpd >>>> >>>> >>>>> stuck: no >>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' >>>>> CA: IPA >>>>> issuer: CN=Certificate Authority,O=.GOV >>>>> subject: CN=comipa02.itmodev.gov,O=.GOV >>>>> expires: 2015-09-23 17:46:26 UTC >>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>> pre-save command: >>>>> post-save command: >>>>> track: yes >>>>> auto-renew: yes >>>>> >>>>> This Cert however still shows expired. What do I need to do to go about renewing it? >>>>> >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com] >>>>> Sent: Thursday, October 08, 2015 2:22 AM >>>>> To: Gronde, Christopher (Contractor) >>>>> >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] Certmonger and dogtag not >>>>> working....issues manually renewing Server-Cert >>>>> >>>>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote: >>>>>> I am new to FreeIPA and have inherited two IPA servers not sure >>>>>> if one is a master/slave or how they are different. I will try >>>>>> to give some pertinent outputs below of some of the things I am >>>>>> seeing. I know the Server-Cert is expired but can't figure out >>>>>> how to renew it. There also appears to be Kerberos >>>>>> authentication issues going on as I'm trying to fix it. >>>>>> >>>>>> #getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>>> certificates and requests being tracked: 2. >>>>>> Request ID '20150922143354': >>>>>> status: NEED_TO_SUBMIT >>>>>> stuck: no >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' >>>>>> CA: dogtag-ipa-retrieve-agent-submit >>>>>> issuer: CN=Certificate Authority,O=.GOV >>>>>> subject: CN=IPA RA,O=.GOV >>>>>> expires: 2013-10-09 11:45:01 UTC >>>>>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>>>>> eku: id-kp-serverAuth,id-kp-clientAuth >>>>>> pre-save command: >>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd >>>>>> track: yes >>>>>> auto-renew: yes >>>>>> >>>>>> #certutil -V -u V -n Server-Cert -d /etc/httpd/alias >>>>>> certutil: certificate is invalid: Peer's Certificate has expired. >>>>>> >>>>>> >>>>>> #certutil -L -d /etc/httpd/alias -n Server-Cert >>>>>> Certificate: >>>>>> Data: >>>>>> Version: 3 (0x2) >>>>>> Serial Number: 166 (0xa6) >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Issuer: "CN=Certificate Authority,O=.GOV" >>>>>> Validity: >>>>>> Not Before: Sun Sep 22 17:46:26 2013 >>>>>> Not After : Wed Sep 23 17:46:26 2015 >>>>>> Subject: "CN=comipa02..gov,O=.GOV" >>>>>> Subject Public Key Info: >>>>>> Public Key Algorithm: PKCS #1 RSA Encryption >>>>>> RSA Public Key: >>>>>> Modulus: >>>>>> c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9: >>>>>> e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40: >>>>>> ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8: >>>>>> 6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40: >>>>>> 51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d: >>>>>> 14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f: >>>>>> c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44: >>>>>> 9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30: >>>>>> ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81: >>>>>> 0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c: >>>>>> ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc: >>>>>> 5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae: >>>>>> 15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03: >>>>>> 11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51: >>>>>> a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8: >>>>>> 32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb >>>>>> Exponent: 65537 (0x10001) >>>>>> Signed Extensions: >>>>>> Name: Certificate Authority Key Identifier >>>>>> Key ID: >>>>>> ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50: >>>>>> c3:13:4b:16 >>>>>> >>>>>> Name: Authority Information Access >>>>>> Method: PKIX Online Certificate Status Protocol >>>>>> Location: >>>>>> URI: "http://comipa01..gov:80/ca/ocsp" >>>>>> >>>>>> Name: Certificate Key Usage >>>>>> Critical: True >>>>>> Usages: Digital Signature >>>>>> Non-Repudiation >>>>>> Key Encipherment >>>>>> Data Encipherment >>>>>> >>>>>> Name: Extended Key Usage >>>>>> TLS Web Server Authentication Certificate >>>>>> TLS Web Client Authentication Certificate >>>>>> >>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >>>>>> Signature: >>>>>> 2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98: >>>>>> d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5: >>>>>> 44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2: >>>>>> 64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a: >>>>>> c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa: >>>>>> b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07: >>>>>> 6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2: >>>>>> 43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57: >>>>>> ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57: >>>>>> 01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5: >>>>>> b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7: >>>>>> 0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f: >>>>>> 7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38: >>>>>> f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70: >>>>>> 5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0: >>>>>> 7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f >>>>>> Fingerprint (SHA-256): >>>>>> DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C >>>>>> Fingerprint (SHA1): >>>>>> >>>>>> 88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA >>>>>> >>>>>> Certificate Trust Flags: >>>>>> SSL Flags: >>>>>> User >>>>>> Email Flags: >>>>>> User >>>>>> Object Signing Flags: >>>>>> User >>>>>> >>>>>> #ipa-getkeytab -s compia02.itmodev.gov -p >>>>>> host/comipa02.itmodev.gov -k /etc/krb5.keytab Kerberos User Principal not found. Do you have a valid Credential Cache? >>>>> So, let's start here. >>>>> >>>>> First above you have a typo: compia02.itmodev.gov versus comipa02.itmodev.gov. However, as this is your IPA master, I'm not sure why you need to re-retrieve its host keytab. Does user name resolution (getent passwd admin) work on the master? If it does, you *don't* need to change existing keytab. >>>>> >>>>> Second, in the output below we can see that certmonger needs a PIN for the request to proceed: >>>>>> #ipa-getcert list >>>>>> Number of certificates and requests being tracked: 2. >>>>>> Request ID '20151007150853': >>>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN >>>>> 'Newly added request needs a PIN to read the key material' >>>>> >>>>>> stuck: yes >>>>>> key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert' >>>>>> CA: IPA >>>>>> issuer: >>>>>> subject: >>>>>> expires: unknown >>>>>> pre-save command: >>>>>> post-save command: >>>>>> track: yes >>>>>> auto-renew: yes >>>>> >>>>> The PIN is in /etc/httpd/alias/pwdfile.txt, to supply it to certmonger, you need to re-submit the request and specify the pin: >>>>> >>>>> ipa-getcert resubmit -i 20151007150853 -p >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>> >>>> -- >>>> / 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 From CWhite at skytouchtechnology.com Tue Oct 13 22:41:51 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Tue, 13 Oct 2015 22:41:51 +0000 Subject: [Freeipa-users] shared ip space for iDM and AD Message-ID: Our environment is mostly Linux servers but we do have some Windows servers running MSSQL. A co-worker spun up Active Directory Domain Controllers without conferring with me and the Windows boxes are all on one of the VLAN private LAN networks used by FreeIPA. Thus we not only have reverse DNS servers in FreeIPA but also in Active Directory. Is it possible to have Active Directory use the reverse DNS servers on iDM/FreeIPA? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png at 01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 7660 bytes Desc: image001.png URL: From mkosek at redhat.com Wed Oct 14 06:56:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Oct 2015 08:56:16 +0200 Subject: [Freeipa-users] ipa-server-install fails at last leg? In-Reply-To: <561CDB9B.2000401@yahoo.co.uk> References: <561CDB9B.2000401@yahoo.co.uk> Message-ID: <561DFC90.4040607@redhat.com> On 10/13/2015 12:23 PM, lejeczek wrote: > dear all, > > my first try at ipa server, I get this when install fails: Hi lejeczek, Can you please start with specifying your IPA version? http://www.freeipa.org/page/Troubleshooting#Reporting_bugs > [15/16]: restarting httpd > [error] CalledProcessError: Command ''/bin/systemctl' 'restart' > 'httpd.service'' returned non-zero exit status 1 > Unexpected error - see /var/log/ipaserver-install.log for details: > CalledProcessError: Command ''/bin/systemctl' 'restart' 'httpd.service'' > returned non-zero exit status 1 > > then I can see that httpd fails to restart for: > > Starting The Apache HTTP Server... > (98)Address already in use: AH00072: make_sock: could not bind to address > [::]:8443 > (98)Address already in use: AH00072: make_sock: could not bind to address > 0.0.0.0:8443 > no listening sockets available, shutting down > > and port is bound by: > > UID PID PPID C SZ RSS PSR STIME TTY TIME CMD > pkiuser 5330 1 1 2128224 494604 5 11:00 ? 00:00:16 java > -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on > -DRESTEASY_LIB=/usr/share/java/resteasy-base -classpath > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar > -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat > -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp > -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.security.manager > -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy > org.apache.catalina.startup.Bootstrap start > > and this is as you can see, the process, the result of the ipa-server-install > itself. > Any suggestions as what is the problem there? It is expected that Dogtag takes over port 8443. What FreeIPA does is re-configure installed mod_nss (nss.conf) originally listening on 8443 to occupy port 443 instead. So this failure likely means that something else is bound to port 8443, whether it is other Apache module or other program. I would start with # netstat -putna run before the installation to see what's it. Upstream wise, there should be a check since https://fedorahosted.org/freeipa/ticket/4564 From pspacek at redhat.com Wed Oct 14 06:56:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 Oct 2015 08:56:40 +0200 Subject: [Freeipa-users] shared ip space for iDM and AD In-Reply-To: References: Message-ID: <561DFCA8.2090001@redhat.com> On 14.10.2015 00:41, Craig White wrote: > Our environment is mostly Linux servers but we do have some Windows servers running MSSQL. A co-worker spun up Active Directory Domain Controllers without conferring with me and the Windows boxes are all on one of the VLAN private LAN networks used by FreeIPA. Thus we not only have reverse DNS servers in FreeIPA but also in Active Directory. Is it possible to have Active Directory use the reverse DNS servers on iDM/FreeIPA? If you decide to manually configure/add records to reverse zones then yes, it will work :-) If you want to use dynamic updates from IPA and Windows clients, then you need to establish trust between AD and IPA domains and modify DNS update policy on IPA server to accept updates from Windows clients. Please note that I did not test this, but it should work. # this allows updates to A/AAAA/SSHFP records $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE $ ipa dnszone-mod your.domain.example. --update-policy=' grant IPA.REALM.EXAMPLE krb5-self * A; grant IPA.REALM.EXAMPLE krb5-self * AAAA; grant IPA.REALM.EXAMPLE krb5-self * SSHFP; grant AD.REALM.EXAMPLE ms-self * A; grant AD.REALM.EXAMPLE ms-self * AAAA; grant AD.REALM.EXAMPLE ms-self * SSHFP; ' # this instructs IPA server to update PTR records when updating A/AAAA records $ ipa dnszone-mod your.domain.example. --sync-ptr=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE Alternatively, you can allow unauthenticated updates to reverse zones, so SyncPTR feature is not needed for Windows clients (because the clients would do updates themselves): $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --update-policy=' grant * tcp-self * PTR;' Please let me know if it works for you. -- Petr^2 Spacek From d.korittki at mittwald.de Wed Oct 14 08:55:33 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Wed, 14 Oct 2015 10:55:33 +0200 Subject: [Freeipa-users] Cleanly removing replication agreement In-Reply-To: <56169000.7060302@mittwald.de> References: <56169000.7060302@mittwald.de> Message-ID: <561E1885.5000809@mittwald.de> I was able to remove the replication, but when I try to readd ipa02 in replication agreement i get errors in /var/log/dirsrv/slapd-INTERNAL/errors on ipa02: [11/Oct/2015:17:17:48 +0200] - 389-Directory/1.3.1.6 B2014.219.1825 starting up [11/Oct/2015:17:17:48 +0200] - WARNING: userRoot: entry cache size 10485760B is less than db size 86450176B; We recommend to increase the entry cache size nsslapd-cachememsize. [11/Oct/2015:17:17:48 +0200] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=internal [11/Oct/2015:17:17:53 +0200] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa02.internal at INTERNAL] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [11/Oct/2015:17:17:53 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [11/Oct/2015:17:17:53 +0200] - Listening on All Interfaces port 636 for LDAPS requests [11/Oct/2015:17:17:53 +0200] - Listening on /var/run/slapd-INTERNAL.socket for LDAPI requests [11/Oct/2015:17:17:53 +0200] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Success) [11/Oct/2015:17:17:53 +0200] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [11/Oct/2015:17:17:53 +0200] NSMMReplicationPlugin - agmt="cn=meToipa01.internal" (ipa01:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [11/Oct/2015:17:17:56 +0200] NSMMReplicationPlugin - agmt="cn=meToipa01.internal" (ipa01:389): Replication bind with GSSAPI auth resumed Seems like he can't get his tickets from the kdc. This is the krb5kdc.log: Okt 11 17:17:53 ipa02.internal krb5kdc[5766](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: LOOKING_UP_CLIENT: ldap/ipa02.internal at INTERNAL for krbtgt/INTERNAL at INTERNAL, Server error Okt 11 17:17:56 ipa02.internal krb5kdc[5767](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: NEEDED_PREAUTH: ldap/ipa02.internal at INTERNAL for krbtgt/INTERNAL at INTERNAL, Additional pre-authentication required Okt 11 17:17:56 ipa02.internal krb5kdc[5766](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: ISSUE: authtime 1444576676, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.internal at INTERNAL for krbtgt/INTERNAL at INTERNAL Okt 11 17:17:56 ipa02.internal krb5kdc[5767](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: ISSUE: authtime 1444576676, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.internal at INTERNAL for ldap/ipa01.internal at INTERNAL Strangely everything works fine, when trying to manually get the ticket: root at ipa02:~ > kinit ldap/ipa02.internal at INTERNAL -kt /etc/dirsrv/ds.keytab root at ipa02:~ > klist Ticket cache: KEYRING:persistent:0:0 Default principal: ldap/ipa02.internal at INTERNAL Valid starting Expires Service principal 11.10.2015 17:27:43 12.10.2015 17:27:43 krbtgt/INTERNAL at INTERNAL This is the log from the kinit command, everything seems normal: Okt 11 17:27:43 ipa02.internal krb5kdc[5767](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: NEEDED_PREAUTH: ldap/ipa02.internal at INTERNAL for krbtgt/INTERNAL at INTERNAL, Additional pre-authentication required Okt 11 17:27:43 ipa02.internal krb5kdc[5767](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 172.16.0.42: ISSUE: authtime 1444577263, etypes {rep=18 tkt=18 ses=18}, ldap/ipa02.internal at INTERNAL for krbtgt/INTERNAL at INTERNAL Any suggestions on how to resolve this issue? Many thanks! - Dominik Am 08.10.2015 um 17:47 schrieb Dominik Korittki: > Hello folks, > > i have two FreeIPA 3.3 Machines running on CentOS7: ipa01.internal and > ipa02.internal. Both have a CA installed. > Initially ipa02 is a replication from ipa01. Recently ipa01 had some > trouble while ipa02 was running fine (see "FreeIPA 3.3 performance > issues with many hosts" on this maillinglist). > > So what i did was to uninstall ipa01 via "ipa-server-install > --uninstall" and recreated ipa01 as a replica of ipa02 via > "ipa-replica-install --setup-ca". Since then I was having trouble with > replication. It seems to be there is still some RUV information about > the old ipa01 in the database. > > Well long story short: I want to completely delete ipa02 from the > replication agreement on host ipa01 to be able to re-add ipa02 later. > > Currently the situation on ipa01 is as follows: > > root at ipa01:~ > ipa-replica-manage list > Directory Manager password: > > ipa01.internal: master > ipa02.internal: master > > root at ipa01:~ > ipa-replica-manage list-ruv > Directory Manager password: > > ipa01.internal:389: 6 > ipa02.internal:389: 5 > > root at ipa01:~ > ipa-csreplica-manage list > Directory Manager password: > > ipa01.internal: master > ipa02.internal: master > > root at ipa01:~ > ldapsearch -D "cn=directory manager" -W -b "cn=mapping > tree,cn=config" 'objectClass=nsDS5ReplicationAgreement' nsds50ruv -LLL > Enter LDAP Password: > dn: > cn=cloneAgreement1-ipa01.internal-pki-tomcat,cn=replica,cn=o\3Dipaca,cn=ma > pping tree,cn=config > nsds50ruv: {replicageneration} 54748540000000600000 > nsds50ruv: {replica 97 ldap://ipa02.internal:389} 54748548000000610000 > 56139e1 > 8000200610000 > nsds50ruv: {replica 1095 ldap://ipa01.internal:389} 56139e17000004470000 > 56139 > e1e000204470000 > nsds50ruv: {replica 96 ldap://ipa01.internal:389} > > > I'm a bit worried about the ldapsearch command. There is a nsds50ruv > attribute with value 1035. It appeared after I readded ipa01 into the > replication agreement. Do I need to get rid of it and if yes, how? > > Another question is: ipa02 is not responsible anymore, so the > CLEANALLRUV Task started on ipa01 by "ipa-replica-manage del ..." would > not be able to connect to ipa02. According to 389ds documentation it > would stay active a long time trying to connect to the other host. Is > it save to abort the task via "ipa-replica-manage abort-clean-ruv ..." > after a while? > > Thanks in advance! > > > Kind regards, > Dominik > From aebruno2 at buffalo.edu Wed Oct 14 13:09:40 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Wed, 14 Oct 2015 09:09:40 -0400 Subject: [Freeipa-users] nsslapd-dbcachesize and database size Message-ID: <20151014130940.GB31053@dead.ccr.buffalo.edu> The load average on our freeipa replicas started to spike over the last few days and we narrowed it down to a dbcache issue. Following the guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh We saw that the dbcachefree was 2.0% which indicates a lot of page churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of our database and index files was 3.1G: $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ 3.1G Once we increased nsslapd-dbcachesize to 6G load average went back to normal and query response times improved. Interestingly, when we restarted the dirsrv process the database size went down to 1.7G $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ 1.7G When we initially deployed freeipa, the size of our database and indexes was about 400M which is why we set nsslapd-dbcachesize to 2G. A few questions: 1. What causes the increase in size of /var/lib/dirsrv/slapd-[domain]/db/* and should we periodically clean up? 2. How do you tune nsslapd-dbcachesize to account for this growth? The dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem to grow much larger? We're running: - ipa-server-4.1.0-18.el7.centos.4.x86_64 and - 389-ds-base-1.3.3.1-20.el7_1.x86_64 Thanks, --Andrew From xuezhiy at gmail.com Wed Oct 14 13:33:13 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Wed, 14 Oct 2015 21:33:13 +0800 Subject: [Freeipa-users] How to config automembership for IP or subnet Message-ID: The document said we can create automembership rule based by IP or subnet. But there's no any sample about it. Anyone know knows how to create them? I have two subnets and need to create two host groups for them. And all host name were auto generated without any pattern. Thanks all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Wed Oct 14 13:42:24 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Wed, 14 Oct 2015 09:42:24 -0400 Subject: [Freeipa-users] Cleanly removing replication agreement In-Reply-To: <561E1885.5000809@mittwald.de> References: <56169000.7060302@mittwald.de> <561E1885.5000809@mittwald.de> Message-ID: <561E5BC0.2020703@redhat.com> On 10/14/2015 04:55 AM, Dominik Korittki wrote: > [11/Oct/2015:17:17:53 +0200] NSMMReplicationPlugin - > agmt="cn=meToipa01.internal" (ipa01:389): Replication bind with GSSAPI > auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: > GSSAPI Error: Unspecified GSS failure. Minor code may provide more > information (No Kerberos credentials available)) > [11/Oct/2015:17:17:56 +0200] NSMMReplicationPlugin - > agmt="cn=meToipa01.internal" (ipa01:389): *Replication bind with > GSSAPI auth resumed* This last line implies that replication authentication finally did succeed - so replication should be working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuezhiy at gmail.com Wed Oct 14 13:43:02 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Wed, 14 Oct 2015 21:43:02 +0800 Subject: [Freeipa-users] How to install freeIPA client to many VMs? Message-ID: There are lots of VMs created from Openstack in our envrioment. And we need to install IPA client on them. I want to create a base image which have installed IPA client, and generate VM from this image. When the VM first boot will auto register to IPA server. But the VM's host name has no domain(not a FQDN) and failed to register. What's the right approach to install IPA client for VMs which cloned from base image? Thanks, -- Brave -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 14 13:59:23 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Oct 2015 07:59:23 -0600 Subject: [Freeipa-users] nsslapd-dbcachesize and database size In-Reply-To: <20151014130940.GB31053@dead.ccr.buffalo.edu> References: <20151014130940.GB31053@dead.ccr.buffalo.edu> Message-ID: <561E5FBB.1070705@redhat.com> On 10/14/2015 07:09 AM, Andrew E. Bruno wrote: > The load average on our freeipa replicas started to spike over the > last few days and we narrowed it down to a dbcache issue. Following the > guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh > > We saw that the dbcachefree was 2.0% which indicates a lot of page > churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of > our database and index files was 3.1G: > > $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ > 3.1G > > Once we increased nsslapd-dbcachesize to 6G load average went back to > normal and query response times improved. Interestingly, when we > restarted the dirsrv process the database size went down to 1.7G > > $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ > 1.7G > > When we initially deployed freeipa, the size of our database and indexes > was about 400M which is why we set nsslapd-dbcachesize to 2G. What about your cachememsize? > > A few questions: > > 1. What causes the increase in size of > /var/lib/dirsrv/slapd-[domain]/db/* and should we periodically clean up? Replication metadata accounts for some of this. Fragmentation accounts for some of this. You can periodically clean up, but you shouldn't have to. The growth should eventually hit a plateau. > > 2. How do you tune nsslapd-dbcachesize to account for this growth? The > dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem > to grow much larger? 12% is sort of a starting point. There isn't a good way to tell how to account for replication metadata, fragmentation, etc. Just monitor periodically and adjust as needed. > > We're running: > - ipa-server-4.1.0-18.el7.centos.4.x86_64 and > - 389-ds-base-1.3.3.1-20.el7_1.x86_64 > > Thanks, > > --Andrew > From peljasz at yahoo.co.uk Wed Oct 14 14:14:30 2015 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 14 Oct 2015 15:14:30 +0100 Subject: [Freeipa-users] ipa-server-install fails at last leg? In-Reply-To: <561DFC90.4040607@redhat.com> References: <561CDB9B.2000401@yahoo.co.uk> <561DFC90.4040607@redhat.com> Message-ID: <561E6346.1070207@yahoo.co.uk> On 14/10/15 07:56, Martin Kosek wrote: > On 10/13/2015 12:23 PM, lejeczek wrote: >> dear all, >> >> my first try at ipa server, I get this when install fails: > Hi lejeczek, > > Can you please start with specifying your IPA version? > > http://www.freeipa.org/page/Troubleshooting#Reporting_bugs it's: ipa-server-4.1.0-18.sl7_1.4.x86_64 and I did file a report before asking the list, also attached a log there. I'm now trying a plain vanilla virtual system and it succeeded there. Where to start troubleshooting it, it seems like that java process hangs on while installer tries to restart httpd. > >> [15/16]: restarting httpd >> [error] CalledProcessError: Command ''/bin/systemctl' 'restart' >> 'httpd.service'' returned non-zero exit status 1 >> Unexpected error - see /var/log/ipaserver-install.log for details: >> CalledProcessError: Command ''/bin/systemctl' 'restart' 'httpd.service'' >> returned non-zero exit status 1 >> >> then I can see that httpd fails to restart for: >> >> Starting The Apache HTTP Server... >> (98)Address already in use: AH00072: make_sock: could not bind to address >> [::]:8443 >> (98)Address already in use: AH00072: make_sock: could not bind to address >> 0.0.0.0:8443 >> no listening sockets available, shutting down >> >> and port is bound by: >> >> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD >> pkiuser 5330 1 1 2128224 494604 5 11:00 ? 00:00:16 java >> -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on >> -DRESTEASY_LIB=/usr/share/java/resteasy-base -classpath >> /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar >> -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat >> -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp >> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >> -Djava.security.manager >> -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy >> org.apache.catalina.startup.Bootstrap start >> >> and this is as you can see, the process, the result of the ipa-server-install >> itself. >> Any suggestions as what is the problem there? > It is expected that Dogtag takes over port 8443. What FreeIPA does is > re-configure installed mod_nss (nss.conf) originally listening on 8443 to > occupy port 443 instead. > > So this failure likely means that something else is bound to port 8443, whether > it is other Apache module or other program. > > I would start with > # netstat -putna run before the installation to see what's it. > > Upstream wise, there should be a check since > https://fedorahosted.org/freeipa/ticket/4564 > From mkosek at redhat.com Wed Oct 14 14:29:07 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Oct 2015 16:29:07 +0200 Subject: [Freeipa-users] How to config automembership for IP or subnet In-Reply-To: References: Message-ID: <561E66B3.5020509@redhat.com> On 10/14/2015 03:33 PM, zhiyong xue wrote: > The document said Hi, What document you have in mind? > we can create automembership rule based by IP or subnet. > But there's no any sample about it. Anyone know knows how to create them? If the information/attribute is not in the LDAP entry for the Host, Automember has no means of applying the rule and adding the membership. The only idea I have now is that you could create the Host entries before ipa-client-install is run, and manually set some attribute containing the subnet identification to description os Host Class attribute that Automember could consume. > I have two subnets and need to create two host groups for them. And all > host name were auto generated without any pattern. > > Thanks all. > > > From aebruno2 at buffalo.edu Wed Oct 14 14:35:37 2015 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Wed, 14 Oct 2015 10:35:37 -0400 Subject: [Freeipa-users] nsslapd-dbcachesize and database size In-Reply-To: <561E5FBB.1070705@redhat.com> References: <20151014130940.GB31053@dead.ccr.buffalo.edu> <561E5FBB.1070705@redhat.com> Message-ID: <20151014143537.GA32523@dead.ccr.buffalo.edu> On Wed, Oct 14, 2015 at 07:59:23AM -0600, Rich Megginson wrote: > On 10/14/2015 07:09 AM, Andrew E. Bruno wrote: > >The load average on our freeipa replicas started to spike over the > >last few days and we narrowed it down to a dbcache issue. Following the > >guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh > > > >We saw that the dbcachefree was 2.0% which indicates a lot of page > >churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of > >our database and index files was 3.1G: > > > >$ du -sh /var/lib/dirsrv/slapd-[domain]/db/ > >3.1G > > > >Once we increased nsslapd-dbcachesize to 6G load average went back to > >normal and query response times improved. Interestingly, when we > >restarted the dirsrv process the database size went down to 1.7G > > > >$ du -sh /var/lib/dirsrv/slapd-[domain]/db/ > >1.7G > > > >When we initially deployed freeipa, the size of our database and indexes > >was about 400M which is why we set nsslapd-dbcachesize to 2G. > > What about your cachememsize? We have nsslapd-cachememsize set at 2G for the cn=userRoot. According to dbmon.sh it looked OK and we didn't think it needed to be increased: dbcachefree 6123847680 free% 95.055 roevicts 0 hit% 99 pagein 34260 pageout 308661 dbname count free free% size changelog:ent 84 158342 30.9 4210.2 changelog:dn 29716 58 0.0 74.0 userroot:ent 8446 2091021433 97.4 6685.1 userroot:dn 8446 523272268 99.8 120.3 ipaca:ent 100 673516 47.9 7338.6 ipaca:dn 100 1399359 99.4 80.1 The changelog:dn seems to vary so much not sure how to tune that one. Any suggestions? It's almost always 0% free. > > > > >A few questions: > > > >1. What causes the increase in size of > >/var/lib/dirsrv/slapd-[domain]/db/* and should we periodically clean up? > > Replication metadata accounts for some of this. Fragmentation accounts for > some of this. You can periodically clean up, but you shouldn't have to. > The growth should eventually hit a plateau. > > > > >2. How do you tune nsslapd-dbcachesize to account for this growth? The > >dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem > >to grow much larger? > > 12% is sort of a starting point. There isn't a good way to tell how to > account for replication metadata, fragmentation, etc. Just monitor > periodically and adjust as needed. Great, Thanks Rich! From mkosek at redhat.com Wed Oct 14 14:40:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Oct 2015 16:40:31 +0200 Subject: [Freeipa-users] How to install freeIPA client to many VMs? In-Reply-To: References: Message-ID: <561E695F.6010807@redhat.com> On 10/14/2015 03:43 PM, zhiyong xue wrote: > There are lots of VMs created from Openstack in our envrioment. And we > need to install IPA client on them. I want to create a base image which > have installed IPA client, and generate VM from this image. > > When the VM first boot will auto register to IPA server. But the VM's > host name has no domain(not a FQDN) and failed to register. How does the client get the domain then? It is currently needed for the FreeIPA clients, so you need to either postpone Client registration until domain is set, or override the hostname in ipa-client-install with static domain, like # ipa-client-install --hostname `hostname`.mydomain.test > What's the right approach to install IPA client for VMs which cloned > from base image? > > Thanks, > -- Brave > > > From CWhite at skytouchtechnology.com Wed Oct 14 15:42:49 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 14 Oct 2015 15:42:49 +0000 Subject: [Freeipa-users] shared ip space for iDM and AD In-Reply-To: <561DFCA8.2090001@redhat.com> References: <561DFCA8.2090001@redhat.com> Message-ID: -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Tuesday, October 13, 2015 11:57 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] shared ip space for iDM and AD On 14.10.2015 00:41, Craig White wrote: > Our environment is mostly Linux servers but we do have some Windows servers running MSSQL. A co-worker spun up Active Directory Domain Controllers without conferring with me and the Windows boxes are all on one of the VLAN private LAN networks used by FreeIPA. Thus we not only have reverse DNS servers in FreeIPA but also in Active Directory. Is it possible to have Active Directory use the reverse DNS servers on iDM/FreeIPA? If you decide to manually configure/add records to reverse zones then yes, it will work :-) If you want to use dynamic updates from IPA and Windows clients, then you need to establish trust between AD and IPA domains and modify DNS update policy on IPA server to accept updates from Windows clients. Please note that I did not test this, but it should work. # this allows updates to A/AAAA/SSHFP records $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE $ ipa dnszone-mod your.domain.example. --update-policy=' grant IPA.REALM.EXAMPLE krb5-self * A; grant IPA.REALM.EXAMPLE krb5-self * AAAA; grant IPA.REALM.EXAMPLE krb5-self * SSHFP; grant AD.REALM.EXAMPLE ms-self * A; grant AD.REALM.EXAMPLE ms-self * AAAA; grant AD.REALM.EXAMPLE ms-self * SSHFP; ' # this instructs IPA server to update PTR records when updating A/AAAA records $ ipa dnszone-mod your.domain.example. --sync-ptr=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE Alternatively, you can allow unauthenticated updates to reverse zones, so SyncPTR feature is not needed for Windows clients (because the clients would do updates themselves): $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --update-policy=' grant * tcp-self * PTR;' Please let me know if it works for you. ---- Will do. My co-worker wants to be the one to join the domains together but he is procrastinating on it so I don't know when it will be done. Thanks for the great help. Craig From xuezhiy at gmail.com Wed Oct 14 15:51:42 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Wed, 14 Oct 2015 23:51:42 +0800 Subject: [Freeipa-users] How to config automembership for IP or subnet In-Reply-To: <561E66B3.5020509@redhat.com> References: <561E66B3.5020509@redhat.com> Message-ID: Thanks Martin. This is the document link: https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automember.html It says : Dividing hosts based on their IP address or subnet. After I installed ipa-client-install the host would be registered to server automatically. I have many clients in two subnets ,it's impossible to add description manually. 2015-10-14 22:29 GMT+08:00 Martin Kosek : > On 10/14/2015 03:33 PM, zhiyong xue wrote: > > The document said > > Hi, > > What document you have in mind? > > > we can create automembership rule based by IP or subnet. > > But there's no any sample about it. Anyone know knows how to create them? > > If the information/attribute is not in the LDAP entry for the Host, > Automember > has no means of applying the rule and adding the membership. The only idea > I > have now is that you could create the Host entries before > ipa-client-install is > run, and manually set some attribute containing the subnet identification > to > description os Host Class attribute that Automember could consume. > > > I have two subnets and need to create two host groups for them. And all > > host name were auto generated without any pattern. > > > > Thanks all. > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuezhiy at gmail.com Wed Oct 14 15:58:02 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Wed, 14 Oct 2015 23:58:02 +0800 Subject: [Freeipa-users] How to install freeIPA client to many VMs? In-Reply-To: <561E695F.6010807@redhat.com> References: <561E695F.6010807@redhat.com> Message-ID: Yes, that's my problem. These VMs were created by openstack and generated host name without domain at all. Anyway can let the new created VM can join domain automatically? Thanks Martin. 2015-10-14 22:40 GMT+08:00 Martin Kosek : > On 10/14/2015 03:43 PM, zhiyong xue wrote: > > There are lots of VMs created from Openstack in our envrioment. And we > > need to install IPA client on them. I want to create a base image which > > have installed IPA client, and generate VM from this image. > > > > When the VM first boot will auto register to IPA server. But the VM's > > host name has no domain(not a FQDN) and failed to register. > > How does the client get the domain then? It is currently needed for the > FreeIPA > clients, so you need to either postpone Client registration until domain is > set, or override the hostname in ipa-client-install with static domain, > like > > # ipa-client-install --hostname `hostname`.mydomain.test > > > What's the right approach to install IPA client for VMs which cloned > > from base image? > > > > Thanks, > > -- Brave > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 14 16:14:50 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Oct 2015 10:14:50 -0600 Subject: [Freeipa-users] How to install freeIPA client to many VMs? In-Reply-To: References: <561E695F.6010807@redhat.com> Message-ID: <561E7F7A.2010901@redhat.com> On 10/14/2015 09:58 AM, zhiyong xue wrote: > Yes, that's my problem. These VMs were created by openstack and > generated host name without domain at all. Anyway can let the new > created VM can join domain automatically? I am working on such a feature: https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova This is not a product yet, just a PoC. This allows you to: * automatically register VMs created by Nova with IPA * automatically assign DNS A records in IPA when you assign a floating IP address to a VM > > Thanks Martin. > > 2015-10-14 22:40 GMT+08:00 Martin Kosek >: > > On 10/14/2015 03:43 PM, zhiyong xue wrote: > > There are lots of VMs created from Openstack in our > envrioment. And we > > need to install IPA client on them. I want to create a base > image which > > have installed IPA client, and generate VM from this image. > > > > When the VM first boot will auto register to IPA server. But > the VM's > > host name has no domain(not a FQDN) and failed to register. > > How does the client get the domain then? It is currently needed > for the FreeIPA > clients, so you need to either postpone Client registration until > domain is > set, or override the hostname in ipa-client-install with static > domain, like > > # ipa-client-install --hostname `hostname`.mydomain.test > > > What's the right approach to install IPA client for VMs which > cloned > > from base image? > > > > Thanks, > > -- Brave > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 14 16:58:51 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Oct 2015 10:58:51 -0600 Subject: [Freeipa-users] nsslapd-dbcachesize and database size In-Reply-To: <20151014143537.GA32523@dead.ccr.buffalo.edu> References: <20151014130940.GB31053@dead.ccr.buffalo.edu> <561E5FBB.1070705@redhat.com> <20151014143537.GA32523@dead.ccr.buffalo.edu> Message-ID: <561E89CB.5090306@redhat.com> On 10/14/2015 08:35 AM, Andrew E. Bruno wrote: > On Wed, Oct 14, 2015 at 07:59:23AM -0600, Rich Megginson wrote: >> On 10/14/2015 07:09 AM, Andrew E. Bruno wrote: >>> The load average on our freeipa replicas started to spike over the >>> last few days and we narrowed it down to a dbcache issue. Following the >>> guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh >>> >>> We saw that the dbcachefree was 2.0% which indicates a lot of page >>> churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of >>> our database and index files was 3.1G: >>> >>> $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ >>> 3.1G >>> >>> Once we increased nsslapd-dbcachesize to 6G load average went back to >>> normal and query response times improved. Interestingly, when we >>> restarted the dirsrv process the database size went down to 1.7G >>> >>> $ du -sh /var/lib/dirsrv/slapd-[domain]/db/ >>> 1.7G >>> >>> When we initially deployed freeipa, the size of our database and indexes >>> was about 400M which is why we set nsslapd-dbcachesize to 2G. >> What about your cachememsize? > We have nsslapd-cachememsize set at 2G for the cn=userRoot. According to > dbmon.sh it looked OK and we didn't think it needed to be increased: > > dbcachefree 6123847680 free% 95.055 roevicts 0 hit% 99 pagein 34260 pageout 308661 > > dbname count free free% size > changelog:ent 84 158342 30.9 4210.2 > changelog:dn 29716 58 0.0 74.0 > userroot:ent 8446 2091021433 97.4 6685.1 > userroot:dn 8446 523272268 99.8 120.3 > ipaca:ent 100 673516 47.9 7338.6 > ipaca:dn 100 1399359 99.4 80.1 Yes, looks good. > > > The changelog:dn seems to vary so much not sure how to tune that one. Any > suggestions? It's almost always 0% free. I wouldn't worry about it, for now. > >>> A few questions: >>> >>> 1. What causes the increase in size of >>> /var/lib/dirsrv/slapd-[domain]/db/* and should we periodically clean up? >> Replication metadata accounts for some of this. Fragmentation accounts for >> some of this. You can periodically clean up, but you shouldn't have to. >> The growth should eventually hit a plateau. >> >>> 2. How do you tune nsslapd-dbcachesize to account for this growth? The >>> dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem >>> to grow much larger? >> 12% is sort of a starting point. There isn't a good way to tell how to >> account for replication metadata, fragmentation, etc. Just monitor >> periodically and adjust as needed. > Great, Thanks Rich! From natxo.asenjo at gmail.com Wed Oct 14 18:06:37 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 14 Oct 2015 20:06:37 +0200 Subject: [Freeipa-users] substitute local system groups by ipa groups Message-ID: hi, can you do something like this? ipa group-add wheel --gid=10 to substitute the local group wheel? Of course nsswitch.conf indicates local groups get found first ( group: files sss) but, would it work and is it supported? -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Wed Oct 14 18:11:06 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 14 Oct 2015 18:11:06 +0000 Subject: [Freeipa-users] shared ip space for iDM and AD In-Reply-To: <561DFCA8.2090001@redhat.com> References: <561DFCA8.2090001@redhat.com> Message-ID: -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Tuesday, October 13, 2015 11:57 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] shared ip space for iDM and AD On 14.10.2015 00:41, Craig White wrote: > Our environment is mostly Linux servers but we do have some Windows servers running MSSQL. A co-worker spun up Active Directory Domain Controllers without conferring with me and the Windows boxes are all on one of the VLAN private LAN networks used by FreeIPA. Thus we not only have reverse DNS servers in FreeIPA but also in Active Directory. Is it possible to have Active Directory use the reverse DNS servers on iDM/FreeIPA? If you decide to manually configure/add records to reverse zones then yes, it will work :-) If you want to use dynamic updates from IPA and Windows clients, then you need to establish trust between AD and IPA domains and modify DNS update policy on IPA server to accept updates from Windows clients. Please note that I did not test this, but it should work. # this allows updates to A/AAAA/SSHFP records $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE $ ipa dnszone-mod your.domain.example. --update-policy=' grant IPA.REALM.EXAMPLE krb5-self * A; grant IPA.REALM.EXAMPLE krb5-self * AAAA; grant IPA.REALM.EXAMPLE krb5-self * SSHFP; grant AD.REALM.EXAMPLE ms-self * A; grant AD.REALM.EXAMPLE ms-self * AAAA; grant AD.REALM.EXAMPLE ms-self * SSHFP; ' # this instructs IPA server to update PTR records when updating A/AAAA records $ ipa dnszone-mod your.domain.example. --sync-ptr=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE Alternatively, you can allow unauthenticated updates to reverse zones, so SyncPTR feature is not needed for Windows clients (because the clients would do updates themselves): $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --update-policy=' grant * tcp-self * PTR;' Please let me know if it works for you. ---- Nitpicking... $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE s/b $ ipa dnszone-mod your.domain.example. --dynamic-update=TRUE #update not updates ipa dnszone-mod your.domain.example. --sync-ptr=TRUE s/b ipa dnszone-mod your.domain.example. --allow-sync-ptr=TRUE #allow is required Still waiting for AD to be joined to IPA for the first set of mods. You're awesome, thanks. Craig From rcritten at redhat.com Wed Oct 14 18:35:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Oct 2015 14:35:19 -0400 Subject: [Freeipa-users] substitute local system groups by ipa groups In-Reply-To: References: Message-ID: <561EA067.3010205@redhat.com> Natxo Asenjo wrote: > hi, > > can you do something like this? > > ipa group-add wheel --gid=10 > > to substitute the local group wheel? Of course nsswitch.conf indicates > local groups get found first ( group: files sss) but, would it work and > is it supported? What is it you expect or desire to happen in this case? rob From natxo.asenjo at gmail.com Wed Oct 14 18:51:23 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 14 Oct 2015 20:51:23 +0200 Subject: [Freeipa-users] substitute local system groups by ipa groups In-Reply-To: <561EA067.3010205@redhat.com> References: <561EA067.3010205@redhat.com> Message-ID: hi, On Wed, Oct 14, 2015 at 8:35 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > > hi, > > > > can you do something like this? > > > > ipa group-add wheel --gid=10 > > > > to substitute the local group wheel? Of course nsswitch.conf indicates > > local groups get found first ( group: files sss) but, would it work and > > is it supported? > > What is it you expect or desire to happen in this case? > sorry, I thought it was obvious. To create a wheel ipa group. Members of this group are automatically 'root' in sudoers in plenty of distributions ( centos 7, just tested): ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL and in policykit I see this as well: # cat 50-default.rules /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ // DO NOT EDIT THIS FILE, it will be overwritten on update // // Default rules for polkit // // See the polkit(8) man page for more information // about configuring polkit. polkit.addAdminRule(function(action, subject) { return ["unix-group:wheel"]; }); So there is already an existing infrastructure for the wheel group that is waiting to be used ;-) Hopefully this makes it clear. -- regards, natxo -- -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 14 19:08:29 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Oct 2015 15:08:29 -0400 Subject: [Freeipa-users] substitute local system groups by ipa groups In-Reply-To: References: <561EA067.3010205@redhat.com> Message-ID: <561EA82D.3070902@redhat.com> Natxo Asenjo wrote: > hi, > > On Wed, Oct 14, 2015 at 8:35 PM, Rob Crittenden > wrote: > > Natxo Asenjo wrote: > > hi, > > > > can you do something like this? > > > > ipa group-add wheel --gid=10 > > > > to substitute the local group wheel? Of course nsswitch.conf indicates > > local groups get found first ( group: files sss) but, would it work and > > is it supported? > > What is it you expect or desire to happen in this case? > > > sorry, I thought it was obvious. To create a wheel ipa group. Members of > this group are automatically 'root' in sudoers in plenty of > distributions ( centos 7, just tested): > > ## Allows people in group wheel to run all commands > %wheel ALL=(ALL) ALL > > and in policykit I see this as well: > > # cat 50-default.rules > /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ > > // DO NOT EDIT THIS FILE, it will be overwritten on update > // > // Default rules for polkit > // > // See the polkit(8) man page for more information > // about configuring polkit. > > polkit.addAdminRule(function(action, subject) { > return ["unix-group:wheel"]; > }); > > > So there is already an existing infrastructure for the wheel group that > is waiting to be used ;-) > > Hopefully this makes it clear. Ok, that's what I thought, didn't want to assume. It is my understanding that nss returns the first match it finds, in this case the system-local wheel group. There is no merging in SSSD AFAIK. rob From ssorce at redhat.com Wed Oct 14 19:54:08 2015 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Oct 2015 15:54:08 -0400 (EDT) Subject: [Freeipa-users] substitute local system groups by ipa groups In-Reply-To: <561EA82D.3070902@redhat.com> References: <561EA067.3010205@redhat.com> <561EA82D.3070902@redhat.com> Message-ID: <469442017.31564297.1444852448034.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Rob Crittenden" > To: "Natxo Asenjo" , freeipa-users at redhat.com > Sent: Wednesday, October 14, 2015 3:08:29 PM > Subject: Re: [Freeipa-users] substitute local system groups by ipa groups > > Natxo Asenjo wrote: > > hi, > > > > On Wed, Oct 14, 2015 at 8:35 PM, Rob Crittenden > > wrote: > > > > Natxo Asenjo wrote: > > > hi, > > > > > > can you do something like this? > > > > > > ipa group-add wheel --gid=10 > > > > > > to substitute the local group wheel? Of course nsswitch.conf > > > indicates > > > local groups get found first ( group: files sss) but, would it work > > > and > > > is it supported? > > > > What is it you expect or desire to happen in this case? > > > > > > sorry, I thought it was obvious. To create a wheel ipa group. Members of > > this group are automatically 'root' in sudoers in plenty of > > distributions ( centos 7, just tested): > > > > ## Allows people in group wheel to run all commands > > %wheel ALL=(ALL) ALL > > > > and in policykit I see this as well: > > > > # cat 50-default.rules > > /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ > > > > // DO NOT EDIT THIS FILE, it will be overwritten on update > > // > > // Default rules for polkit > > // > > // See the polkit(8) man page for more information > > // about configuring polkit. > > > > polkit.addAdminRule(function(action, subject) { > > return ["unix-group:wheel"]; > > }); > > > > > > So there is already an existing infrastructure for the wheel group that > > is waiting to be used ;-) > > > > Hopefully this makes it clear. > > Ok, that's what I thought, didn't want to assume. It is my understanding > that nss returns the first match it finds, in this case the system-local > wheel group. There is no merging in SSSD AFAIK. FYI: we are working on this problem: https://sourceware.org/glibc/wiki/Proposals/GroupMerging Stephen has patches for glibc, not sure what is th status of the submission yet though. Simo. -- Simo Sorce * Red Hat, Inc. * New York From pspacek at redhat.com Thu Oct 15 07:30:10 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Oct 2015 09:30:10 +0200 Subject: [Freeipa-users] shared ip space for iDM and AD In-Reply-To: References: <561DFCA8.2090001@redhat.com> Message-ID: <561F5602.1080801@redhat.com> On 14.10.2015 20:11, Craig White wrote: > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek > Sent: Tuesday, October 13, 2015 11:57 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] shared ip space for iDM and AD > > On 14.10.2015 00:41, Craig White wrote: >> Our environment is mostly Linux servers but we do have some Windows servers running MSSQL. A co-worker spun up Active Directory Domain Controllers without conferring with me and the Windows boxes are all on one of the VLAN private LAN networks used by FreeIPA. Thus we not only have reverse DNS servers in FreeIPA but also in Active Directory. Is it possible to have Active Directory use the reverse DNS servers on iDM/FreeIPA? > > If you decide to manually configure/add records to reverse zones then yes, it will work :-) > > If you want to use dynamic updates from IPA and Windows clients, then you need to establish trust between AD and IPA domains and modify DNS update policy on IPA server to accept updates from Windows clients. > > Please note that I did not test this, but it should work. > > > # this allows updates to A/AAAA/SSHFP records $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE $ ipa dnszone-mod your.domain.example. --update-policy=' > grant IPA.REALM.EXAMPLE krb5-self * A; > grant IPA.REALM.EXAMPLE krb5-self * AAAA; grant IPA.REALM.EXAMPLE krb5-self * SSHFP; grant AD.REALM.EXAMPLE ms-self * A; grant AD.REALM.EXAMPLE ms-self * AAAA; grant AD.REALM.EXAMPLE ms-self * SSHFP; ' > > # this instructs IPA server to update PTR records when updating A/AAAA records $ ipa dnszone-mod your.domain.example. --sync-ptr=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE > > > Alternatively, you can allow unauthenticated updates to reverse zones, so SyncPTR feature is not needed for Windows clients (because the clients would do updates themselves): > $ ipa dnszone-mod 2.0.192.in-addr.arpa. --dynamic-update=TRUE $ ipa dnszone-mod 2.0.192.in-addr.arpa. --update-policy=' > grant * tcp-self * PTR;' > > > Please let me know if it works for you. > ---- > Nitpicking... > > $ ipa dnszone-mod your.domain.example. --dynamic-updates=TRUE > s/b > $ ipa dnszone-mod your.domain.example. --dynamic-update=TRUE #update not updates > > > ipa dnszone-mod your.domain.example. --sync-ptr=TRUE > s/b > ipa dnszone-mod your.domain.example. --allow-sync-ptr=TRUE #allow is required > > > Still waiting for AD to be joined to IPA for the first set of mods. BTW please be sure to follow http://www.freeipa.org/page/Deployment_Recommendations DNS configuration is especially important when it comes to AD trusts. -- Petr^2 Spacek From mkosek at redhat.com Thu Oct 15 10:50:20 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Oct 2015 12:50:20 +0200 Subject: [Freeipa-users] How to config automembership for IP or subnet In-Reply-To: References: <561E66B3.5020509@redhat.com> Message-ID: <561F84EC.40307@redhat.com> On 10/14/2015 05:51 PM, zhiyong xue wrote: > Thanks Martin. > > This is the document link: > https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automember.html > It says : Dividing hosts based on their IP address or subnet. Ah, I see. This is rather old and deprecated guide (see http://www.freeipa.org/page/Upstream_User_Guide for details), but this information is even in the newest guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automember.html I am not sure how this should be practically achieved actually. Automember can only decide on information that is already in the entry in LDAP ADD, or later when Automembership task is explicitly re-run. I think we should simply change this use case as it is not true. I filed a ticket to fix the docs: https://bugzilla.redhat.com/show_bug.cgi?id=1272043 > After I installed ipa-client-install the host would be registered to server > automatically. I have many clients in two subnets ,it's impossible to add > description manually. I see. I suspect you would have to do some scripting around that, for example a cron job or any other job that would find the IP address of the new hosts, store the subnet or other identificator in FreeIPA host entry and run automembership for this entry. This would add the right membership, based on the rules. > > 2015-10-14 22:29 GMT+08:00 Martin Kosek : > >> On 10/14/2015 03:33 PM, zhiyong xue wrote: >>> The document said >> >> Hi, >> >> What document you have in mind? >> >>> we can create automembership rule based by IP or subnet. >>> But there's no any sample about it. Anyone know knows how to create them? >> >> If the information/attribute is not in the LDAP entry for the Host, >> Automember >> has no means of applying the rule and adding the membership. The only idea >> I >> have now is that you could create the Host entries before >> ipa-client-install is >> run, and manually set some attribute containing the subnet identification >> to >> description os Host Class attribute that Automember could consume. >> >>> I have two subnets and need to create two host groups for them. And all >>> host name were auto generated without any pattern. >>> >>> Thanks all. >>> >>> >>> >> >> > From karl.forner at gmail.com Thu Oct 15 13:53:07 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 15 Oct 2015 15:53:07 +0200 Subject: [Freeipa-users] freeIPA user can not use cron Message-ID: Hi, cron jobs do no work using a freeIPA user account. the cron job: */1 * * * * echo coucou in /var/log/syslog: Oct 15 15:48:02 asgard CRON[9779]: Permission denied in /var/log/auth.log: Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access denied for user qbuser: 6 (Permission denied) in freeIPA I setup an hbac rule for this user and host that allow the services: ftp login sshd gdm-password crond gdm What did I miss ? Thanks. Karl Forner From jhrozek at redhat.com Thu Oct 15 13:56:24 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 15 Oct 2015 15:56:24 +0200 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: Message-ID: <20151015135624.GI30568@hendrix.redhat.com> On Thu, Oct 15, 2015 at 03:53:07PM +0200, Karl Forner wrote: > Hi, > > cron jobs do no work using a freeIPA user account. > > the cron job: > */1 * * * * echo coucou > > in /var/log/syslog: > Oct 15 15:48:02 asgard CRON[9779]: Permission denied > > in /var/log/auth.log: > Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access > denied for user qbuser: 6 (Permission denied) > > in freeIPA I setup an hbac rule for this user and host that allow the services: > ftp > login > sshd > gdm-password > crond > gdm > > What did I miss ? does ipa hbactest say the service should be permitted? From f.zoske at euroimmun.de Thu Oct 15 14:20:34 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Thu, 15 Oct 2015 14:20:34 +0000 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: Message-ID: Hi, we just had the same problem. You need to add a new service "cron" and assign this to the user/group. Best regards, Fabian -----Urspr?ngliche Nachricht----- Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Karl Forner Gesendet: Donnerstag, 15. Oktober 2015 15:53 An: freeipa-users at redhat.com Betreff: [Freeipa-users] freeIPA user can not use cron Hi, cron jobs do no work using a freeIPA user account. the cron job: */1 * * * * echo coucou in /var/log/syslog: Oct 15 15:48:02 asgard CRON[9779]: Permission denied in /var/log/auth.log: Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access denied for user qbuser: 6 (Permission denied) in freeIPA I setup an hbac rule for this user and host that allow the services: ftp login sshd gdm-password crond gdm What did I miss ? Thanks. Karl Forner -- 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 From karl.forner at gmail.com Thu Oct 15 14:21:16 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 15 Oct 2015 16:21:16 +0200 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: Message-ID: %ipa hbactest User name: qbuser Target host: asgard Service: crond -------------------- Access granted: True On Thu, Oct 15, 2015 at 3:53 PM, Karl Forner wrote: > Hi, > > cron jobs do no work using a freeIPA user account. > > the cron job: > */1 * * * * echo coucou > > in /var/log/syslog: > Oct 15 15:48:02 asgard CRON[9779]: Permission denied > > in /var/log/auth.log: > Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access > denied for user qbuser: 6 (Permission denied) > > in freeIPA I setup an hbac rule for this user and host that allow the services: > ftp > login > sshd > gdm-password > crond > gdm > > What did I miss ? > > Thanks. > > Karl Forner From karl.forner at gmail.com Thu Oct 15 14:24:50 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 15 Oct 2015 16:24:50 +0200 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: Message-ID: Yes it works !!! Maybe this should be documented somewhere ? Thanks. On Thu, Oct 15, 2015 at 4:20 PM, Zoske, Fabian wrote: > Hi, > > we just had the same problem. > > You need to add a new service "cron" and assign this to the user/group. > > Best regards, > Fabian > > -----Urspr?ngliche Nachricht----- > Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Karl Forner > Gesendet: Donnerstag, 15. Oktober 2015 15:53 > An: freeipa-users at redhat.com > Betreff: [Freeipa-users] freeIPA user can not use cron > > Hi, > > cron jobs do no work using a freeIPA user account. > > the cron job: > */1 * * * * echo coucou > > in /var/log/syslog: > Oct 15 15:48:02 asgard CRON[9779]: Permission denied > > in /var/log/auth.log: > Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access denied for user qbuser: 6 (Permission denied) > > in freeIPA I setup an hbac rule for this user and host that allow the services: > ftp > login > sshd > gdm-password > crond > gdm > > What did I miss ? > > Thanks. > > Karl Forner > > -- > 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 From f.zoske at euroimmun.de Thu Oct 15 14:26:31 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Thu, 15 Oct 2015 14:26:31 +0000 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: , Message-ID: I think this is related to diferent names on different systems. RHEL and CentOS are using crond Ubuntu and similar are using cron ________________________________________ From: Karl Forner [karl.forner at gmail.com] Sent: Thursday, October 15, 2015 16:24 To: Zoske, Fabian Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] freeIPA user can not use cron Yes it works !!! Maybe this should be documented somewhere ? Thanks. On Thu, Oct 15, 2015 at 4:20 PM, Zoske, Fabian wrote: > Hi, > > we just had the same problem. > > You need to add a new service "cron" and assign this to the user/group. > > Best regards, > Fabian > > -----Urspr?ngliche Nachricht----- > Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Karl Forner > Gesendet: Donnerstag, 15. Oktober 2015 15:53 > An: freeipa-users at redhat.com > Betreff: [Freeipa-users] freeIPA user can not use cron > > Hi, > > cron jobs do no work using a freeIPA user account. > > the cron job: > */1 * * * * echo coucou > > in /var/log/syslog: > Oct 15 15:48:02 asgard CRON[9779]: Permission denied > > in /var/log/auth.log: > Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access denied for user qbuser: 6 (Permission denied) > > in freeIPA I setup an hbac rule for this user and host that allow the services: > ftp > login > sshd > gdm-password > crond > gdm > > What did I miss ? > > Thanks. > > Karl Forner > > -- > 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 From karl.forner at gmail.com Thu Oct 15 14:27:58 2015 From: karl.forner at gmail.com (Karl Forner) Date: Thu, 15 Oct 2015 16:27:58 +0200 Subject: [Freeipa-users] freeIPA user can not use cron In-Reply-To: References: Message-ID: ok, makes sense. And ubuntu users are quite rare... On Thu, Oct 15, 2015 at 4:26 PM, Zoske, Fabian wrote: > I think this is related to diferent names on different systems. > > RHEL and CentOS are using crond > Ubuntu and similar are using cron > > ________________________________________ > From: Karl Forner [karl.forner at gmail.com] > Sent: Thursday, October 15, 2015 16:24 > To: Zoske, Fabian > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] freeIPA user can not use cron > > Yes it works !!! Maybe this should be documented somewhere ? > Thanks. > > On Thu, Oct 15, 2015 at 4:20 PM, Zoske, Fabian wrote: >> Hi, >> >> we just had the same problem. >> >> You need to add a new service "cron" and assign this to the user/group. >> >> Best regards, >> Fabian >> >> -----Urspr?ngliche Nachricht----- >> Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Karl Forner >> Gesendet: Donnerstag, 15. Oktober 2015 15:53 >> An: freeipa-users at redhat.com >> Betreff: [Freeipa-users] freeIPA user can not use cron >> >> Hi, >> >> cron jobs do no work using a freeIPA user account. >> >> the cron job: >> */1 * * * * echo coucou >> >> in /var/log/syslog: >> Oct 15 15:48:02 asgard CRON[9779]: Permission denied >> >> in /var/log/auth.log: >> Oct 15 15:48:02 asgard CRON[9779]: pam_sss(cron:account): Access denied for user qbuser: 6 (Permission denied) >> >> in freeIPA I setup an hbac rule for this user and host that allow the services: >> ftp >> login >> sshd >> gdm-password >> crond >> gdm >> >> What did I miss ? >> >> Thanks. >> >> Karl Forner >> >> -- >> 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 From james.masson at jmips.co.uk Thu Oct 15 15:10:16 2015 From: james.masson at jmips.co.uk (James Masson) Date: Thu, 15 Oct 2015 16:10:16 +0100 Subject: [Freeipa-users] IPA with external CA signed certs Message-ID: <561FC1D8.7040807@jmips.co.uk> Hi list, I successfully have IPA working with CA certs signed by an upstream Dogtag. Now I'm trying to use a CA cert signed by a different type of CA - Vault. Setup fails, using the same 2 step IPA setup process as used with upstream Dogtag. I've also tried the external-ca-type option. Likely, IPA doesn't like the certificate - however, I can't pinpoint why. Errors below. thanks James M ### -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIUTKucjDpTMZ/oPmgnxR1MznVhktkwDQYJKoZIhvcNAQEL BQAwVjEZMBcGA1UEAxMQbXljYS5leGFtcGxlLmNvbTE5MDcGA1UEBRMwNjQ2Mjcx MDAwODA3NTg1NjA0ODA0NzYyODExNzAyMTM0NDk5MDQ1ODM4NjM2OTEwMB4XDTE1 MTAxNTE0MzY1NloXDTE1MTAxNjAwMzY1NlowMDEOMAwGA1UEChMFTE9DQUwxHjAc BgNVBAMTFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBANMByCz97mhj8nG/R7T5K/lUlat4jnfFyo5/xn4eTzhcqDD/ NixixWqT6TPWBg5Mep7Wnn0EBwG9DjB2dq6+9Ai3TGMzFWkeKvMrZuTouLFoS9SR 6s5wybFfbAoTuV5lq0rIZClqi6ELnAyOccQEuV4UA0PBoe1UjycZf20eSU/52eH4 SiMbLYliDOuWbARgYYwtwc7HVPUwangk4toPH6h2FZ9+tTj8oB6Zxf3lK65IzyCT IHj+53gyySB78CDV2FZ67cI5u1KKcpC/CyjkbO4DKHWWxzxuvUM4F0K20l+cMoP6 Kpr7aGYotY3B6uTocMg59Gwlsvgl0gE03LI9Vp0CAwEAAaNjMGEwHQYDVR0OBBYE FLjG7oRluBaMxV5Wi6rBSvgHDzjuMB8GA1UdIwQYMBaAFCw0iwWuCOlUcS6ZIPM8 X50f1nLnMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMA0GCSqGSIb3 DQEBCwUAA4IBAQBVAoAuZgu6RkY0ufVcNDDNORgOwSgNbvyt1rQNC5mxhLw0Ott+ XyxuzgycyEFCdQP1VChG5i0nOfrEixX7eSQVgN3LKaeiRVsGh1H+ucp/YVnhPvc1 lLtAHVwPn+OuvdJR68K3/twtZ4Fh0BtRFeAmuIOk+QomDhxsxt8LgbaPbdS/vuZw Xn27REGErgT8bDWp447YU6pOb+rPj9ZNHdS1TeDG5h1A0ArH5IUVgyASFkM4SEVH pKneAWEDy+Ik67FoYQbHpYyII1L7R5vskZZv1xhYkH8csJ8iTcrRCa+EiBvhtsWg uuHzqst1ryPKdNtxPM+D96vRSJxCYBUFeKqh -----END CERTIFICATE----- ### ### [19/27]: restarting certificate server ipa : CRITICAL Failed to restart the certificate server. See the installation log for details. [20/27]: requesting RA certificate from CA [error] RuntimeError: Unable to submit RA cert request ### ### 2015-10-15T14:44:31Z DEBUG The CA status is: check interrupted 2015-10-15T14:44:31Z DEBUG Waiting for CA to start... 2015-10-15T14:44:32Z DEBUG request 'https://foo.local:8443/ca/admin/ca/getStatus' 2015-10-15T14:44:32Z DEBUG request body '' 2015-10-15T14:44:32Z DEBUG request status 404 2015-10-15T14:44:32Z DEBUG request reason_phrase u'Not Found' 2015-10-15T14:44:32Z DEBUG request headers {'date': 'Thu, 15 Oct 2015 14:44:32 GMT', 'content-length': '993', 'content-type': 'text/html;charset=utf-8', 'content-language': 'en', 'server': 'Apache-Coyote/1.1'} 2015-10-15T14:44:32Z DEBUG request body 'Apache Tomcat/7.0.54 - Error report

HTTP Status 404 - /ca/admin/ca/getStatus

type Status report

message /ca/admin/ca/getStatus

description The requested resource is not availa ble.

Apache Tomcat/7.0.54

' 2015-10-15T14:44:32Z DEBUG The CA status is: check interrupted 2015-10-15T14:44:32Z DEBUG Waiting for CA to start... 2015-10-15T14:44:33Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 840, in __restart_instance self.restart(self.dogtag_constants.PKI_INSTANCE_NAME) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 282, in restart self.service.restart(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 209, in restart self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 197, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) RuntimeError: CA did not start in 300.0s 2015-10-15T14:44:33Z CRITICAL Failed to restart the certificate server. See the installation log for details. 2015-10-15T14:44:33Z DEBUG duration: 303 seconds 2015-10-15T14:44:33Z DEBUG [20/27]: requesting RA certificate from CA 2015-10-15T14:44:33Z DEBUG Starting external process 2015-10-15T14:44:33Z DEBUG args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-f' XXXXXXXX '-R' '-k' 'rsa' '-g' '2048' '-s' 'CN=IPA RA,O=LOCAL' '-z' '/tmp/tmpKsFaxb' '-a' 2015-10-15T14:44:34Z DEBUG Process finished, return code=0 2015-10-15T14:44:34Z DEBUG stdout= Certificate request generated by Netscape certutil Phone: (not specified) Common Name: IPA RA Email: (not specified) Organization: LOCAL State: (not specified) Country: (not specified) -----BEGIN NEW CERTIFICATE REQUEST----- MIICZjCCAU4CAQAwITEOMAwGA1UEChMFTE9DQUwxDzANBgNVBAMTBklQQSBSQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALDlLPK38QR37gUAVj8GSXv/ VdxsPkGpPuGrtvKbOXXH35I2que06JswL2i4Cj29v9ZgNQgN3EACVFvADv/zUumI 9bdF6wrH+pK4HErRSjICPxXjYZZnPoUcprGQ+/vQiDsk4pt4EyWZZfD/kGKj7BV6 7A2kMumYmLGIH/A24s8qNix3Ho/Ttsogjrpgg+n9G4WkntQJefTrrDv3wt1+lmo4 IIXUsmkLUB31iRifEf8umHhUcneL8uaxMCLY1X5uSkXVQmTK97bYqQu/EbrC4XZ/ dFx6LS9FKukEGJnX9GaFF59TvTN8ImLc4aUOvErOutbiAttQrKacfcSPv7uGqpcC AwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAAJ0Hfvk315MKgL2/2e+A5M1NS7EBn Ukqsnoo2onAa/8CXiFjcdUnpJ4fVn/FnH8ECRrMjUxB8mJ/EsZnuOym17+lNI0mp wx5vkwL9kybawSEQSWMT80uefRzhZAze1vN/LgXZ4ysdRW5p2BQ3898M9HFrqE0s 4XzLNTg07v0RbJ3veHt1wSWoy/v0zp3RRy/du3cczYTYwJ1P3GokFIuPT1fSAzBV yovcJnB3FrrLvPyGAKmhKaoW3UejmE0G/8xpCaFp4+4LuVHNyiya79kzJMpkOoQ3 3MxVB6oLfL/QGnY+3025BXNwIhf4zfL4FlKhyaQ4R0pEUZeMoyksgsxb -----END NEW CERTIFICATE REQUEST----- 2015-10-15T14:44:34Z DEBUG stderr= Generating key. This may take a few moments... 2015-10-15T14:44:34Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1156, in __request_ra_certificate raise RuntimeError("Unable to submit RA cert request") RuntimeError: Unable to submit RA cert request 2015-10-15T14:44:34Z DEBUG [error] RuntimeError: Unable to submit RA cert request 2015-10-15T14:44:34Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 1170, in main ca_signing_algorithm=options.ca_signing_algorithm) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 520, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 382, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 372, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1156, in __request_ra_certificate raise RuntimeError("Unable to submit RA cert request") 2015-10-15T14:44:34Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Unable to submit RA cert request ### ### 0.localhost-startStop-1 - [15/Oct/2015:14:39:26 UTC] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] SystemCertsVerification: system certs verification failure 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! ### ### [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=subsystemCert cert-pki-ca] CIMC certificate verification [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=audit_signing [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: verifySystemCertByTag(audit_signing) [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(auditSigningCert cert-pki-ca,ObjectSigner) [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() passed: auditSigningCert cert-pki-ca [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate verification java.lang.Exception: SystemCertsVerification: system certs verification failure at com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) at com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) at com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) at com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1738) at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1185) at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] self tests execution (see selftests.log for details) ##### From wirelessben at gmail.com Thu Oct 15 18:39:39 2015 From: wirelessben at gmail.com (Ben Francis) Date: Thu, 15 Oct 2015 14:39:39 -0400 Subject: [Freeipa-users] IPA Domain vs. AD Message-ID: Hello IPA Warriors, Firstly, some love: I installed ipa-server from the Oracle Linux repos and it worked right out of the box. Woot! Getting that many packages to play nice together is a huge accomplishment. However, I uninstalled it because I feared it would cause problems with our current Active Directory. I'm in a sandbox environment that nevertheless authenticates to AD. So... How do I configure the hostname and domain so as not to interfere with AD? I do want to integrate with AD. The current domain setup: college.edu sandbox.college.edu (real, existing domain name, 'cept for the college part) Would the folowing work? hostname: sandbox.college.edu domain: ipa.college.edu ipa.college.edu does not exist in DNS. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Oct 15 19:21:06 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 15 Oct 2015 21:21:06 +0200 Subject: [Freeipa-users] A security bug in SSSD 1.10 and later (CVE-2015-5292) Message-ID: <20151015192106.GC2924@hendrix> =============== A security bug in SSSD 1.10 and later ============== = = Subject: A memory leak was found in SSSD's PAC processing plugin = = CVE ID#: CVE-2015-5292 = = Summary: When SSSD's PAC responder is configured and a user login = triggers parsing of the PAC blob (typically a GSSAPI = password-less login), a small amount of memory is leaked = in the context of the Kerberized application. This can = eventually lead to memory exhaustion. = = Impact: Low = = Acknowledgements: This bug was found by Thomas Oulevey from CERN = = Affects default = configuration: Only for the IPA provider = = Introduced with: 1.10.0 beta2 = =============================================================== ==== DESCRIPTION ==== When SSSD's PAC responder is configured and a user login triggers parsing of the PAC blob (typically a GSSAPI password-less login), a small amount of memory is leaked in the context of the Kerberized application. This can eventually lead to memory exhaustion. The affected configration would include "pac" in the list of services in the the "[sssd]" section of the /etc/sssd/sssd.conf config file. Please note that SSSD automatically starts the PAC responder in case the provider type is set to IPA. Also note that the most widely deployed application with this configuration is OpenSSH, where the bug is not noticeable because, the leak happens in a short-lived child process, not the long-running deamon. The fix was delivered as part of the 1.13.1 release. However, the security implications of the bug were only determined later. The bug is being tracked in the following Red Hat Bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=1267580 ==== PATCH AVAILABILITY ==== The patch is available at: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=b4c44ebb8997d3debb33607c123ccfd9926e0cba From pspacek at redhat.com Fri Oct 16 07:49:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Oct 2015 09:49:26 +0200 Subject: [Freeipa-users] IPA Domain vs. AD In-Reply-To: References: Message-ID: <5620AC06.3060107@redhat.com> On 15.10.2015 20:39, Ben Francis wrote: > Hello IPA Warriors, > > Firstly, some love: I installed ipa-server from the Oracle Linux repos and > it worked right out of the box. Woot! Getting that many packages to play > nice together is a huge accomplishment. > > However, I uninstalled it because I feared it would cause problems with our > current Active Directory. > > I'm in a sandbox environment that nevertheless authenticates to AD. > > So... How do I configure the hostname and domain so as not to interfere > with AD? > > I do want to integrate with AD. > > The current domain setup: > > college.edu > > sandbox.college.edu (real, existing domain name, 'cept for the college part) > > Would the folowing work? > > hostname: sandbox.college.edu > domain: ipa.college.edu > > ipa.college.edu does not exist in DNS. That should work, if you actually create the domain ipa.college.edu and delegate it properly to IPA DNS server or if you fill it in with DNS records. Please see http://www.freeipa.org/page/Deployment_Recommendations#DNS -- Petr^2 Spacek From xuezhiy at gmail.com Fri Oct 16 08:30:26 2015 From: xuezhiy at gmail.com (zhiyong xue) Date: Fri, 16 Oct 2015 16:30:26 +0800 Subject: [Freeipa-users] How to install freeIPA client to many VMs? In-Reply-To: <561E7F7A.2010901@redhat.com> References: <561E695F.6010807@redhat.com> <561E7F7A.2010901@redhat.com> Message-ID: Thanks Rich, The VMs created by Nova include the domain name or you set static name by "ipa-client-install --hostname `hostname`.mydomain.test" ? 2015-10-15 0:14 GMT+08:00 Rich Megginson : > On 10/14/2015 09:58 AM, zhiyong xue wrote: > > Yes, that's my problem. These VMs were created by openstack and generated > host name without domain at all. Anyway can let the new created VM can > join domain automatically? > > > I am working on such a feature: > https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova > > This is not a product yet, just a PoC. > > This allows you to: > * automatically register VMs created by Nova with IPA > * automatically assign DNS A records in IPA when you assign a floating IP > address to a VM > > > Thanks Martin. > > 2015-10-14 22:40 GMT+08:00 Martin Kosek : > >> On 10/14/2015 03:43 PM, zhiyong xue wrote: >> > There are lots of VMs created from Openstack in our envrioment. And we >> > need to install IPA client on them. I want to create a base image which >> > have installed IPA client, and generate VM from this image. >> > >> > When the VM first boot will auto register to IPA server. But the VM's >> > host name has no domain(not a FQDN) and failed to register. >> >> How does the client get the domain then? It is currently needed for the >> FreeIPA >> clients, so you need to either postpone Client registration until domain >> is >> set, or override the hostname in ipa-client-install with static domain, >> like >> >> # ipa-client-install --hostname `hostname`.mydomain.test >> >> > What's the right approach to install IPA client for VMs which cloned >> > from base image? >> > >> > Thanks, >> > -- Brave >> > >> > >> > >> >> > > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Oct 16 08:32:14 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 16 Oct 2015 10:32:14 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> Message-ID: <20151016083214.GJ14465@hendrix.arn.redhat.com> On Tue, Oct 13, 2015 at 07:19:20AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > thanks for looking through the data. Sorry for late reply. > > I can not access the bug you mentioned. I already created an account for Bugzilla, but so far nothing. Ah, it's probably marked as private b/c it contains some private customer information.. > > In the second query there is a group which isn't present in the first one ((sudoUser=%ug_freeipa-administrators_int)). This is the IPA-equivalent of the AD-Group (ug_freeipa-administrators). > AD -> IPA_EXT -> IPA_INT Then it sounds like the bug we solved lately, can you try installing these packages on the IPA server (yes, server, not client): https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.1-external-group/ > > The second command you mentioned works and returns the correct passwd entry for my user. The first command ist not found on the client. > > Best regards, > Fabian > ________________________________________ > From: Jakub Hrozek [jhrozek at redhat.com] > Sent: Monday, October 12, 2015 11:47 > To: Zoske, Fabian > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] SUDO does not always works on first try > > On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote: > > Hi Jakub, > > > > I increased the log level in every SSSD section to 6 and got following output, hope that helps. > > > > KRB5_CHILD.LOG: https://s.mit42.de/IR6tu > > All is OK here.. > > > > > SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl > > So the interesting part is that the first try doesn't match any rules > for the user: > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid] > (0x0400): No such entry > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=+*)))] > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for > [f.zoske at de.eu.local] > > While the second does: > (Fri Oct 9 12:24:14 2015) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))] > (Fri Oct 9 12:24:14 2015) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for > [f.zoske at de.eu.local] > > It would be interesting to see the dump of the cache from when 0 rules > are returned. I suspect the user's membership wouldn't be correct, which > might be because of the bug I linked earlier. > > > > > SSSD_IPA-LX.COM: https://s.mit42.de/frBvx > > There are some failures here: > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] > (0x0400): Executing extended operation > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] > (0x0400): ldap_extended_operation result: No such object(32), (null) > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] > [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback] > (0x0100): Request processed. Returned 3,1432158221,Account info lookup > failed > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_get_account_info] > (0x0100): Got request for [4097][1][name=*] > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_req_set_domain] > (0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local] > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] > (0x0400): Executing extended operation > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] > (0x0400): ldap_extended_operation result: No such object(32), (null) > > But I think this is a really minor bug we fixed later where we marked > requests as failed if they simply didn't find anything. If this works > without issues: > $ sss_cache -u f.zoske at de.eu.local > $ getent passwd f.zoske at de.eu.local > > Then you can ignore those.. From piolet.y at gmail.com Fri Oct 16 12:03:47 2015 From: piolet.y at gmail.com (Youenn PIOLET) Date: Fri, 16 Oct 2015 14:03:47 +0200 Subject: [Freeipa-users] FreeIPA Deployment and resiliency Message-ID: Hi there. I'd like to integrate FreeIPA in a multi-location production environment. We got servers in US/Europe/South America/Pacific Ocean with some high latency links. The parc I manage is a mixed linux environment with less than 1000 servers. I also plan to use FreeIPA as backend for Radius authentication on various network equipments. I plan to deploy a replica architecture similar to the recommandation article in official Documentation: http://www.freeipa.org/page/Deployment_Recommendations with two replicas per region and at least one replica per DC. FreeIPA will become my DNS for internal resolution. FreeIPA servers will run on latest CentOS. I've got two questions: 1) Version: Should I wait for IPA 4.2 or is IPA 4.1.4 a good / stable / trust-full solution for authentication, upgrade, maintainability, resilience ? Will 4.2.X be too young and unstable for a massive implementation ? I'm quite interested about 4.2 but don't want to wait too long for a release on Centos. How easy would be an upgrade of all replicas from 4.1.4 to 4.2 in an IPA replication topology? 2) Resiliency: How to make FreeIPA service resilient? Is there an official / easy and secure way to converge to an other IPA server (with DNS?) when a replica is down? I've got the chance to work on an MPLS network with the Anycast possibility. Is it something workable with FreeIPA/Kerberos ? Thanks by advance for your suggestions -- Youenn Piolet piolet.y at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From canepa.n at mmfg.it Fri Oct 16 13:01:19 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Fri, 16 Oct 2015 15:01:19 +0200 Subject: [Freeipa-users] FreeIPA and DHCP Message-ID: <5620F51F.8060606@mmfg.it> Hello. Is there a suggested way to have DHCP IP/MAC associations managed through the IPA web interface? Thank you for any pointer. Nicola -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. From fujisan43 at gmail.com Fri Oct 16 13:26:15 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 16 Oct 2015 15:26:15 +0200 Subject: [Freeipa-users] Why are some user's information not stored in the LDAP database? Message-ID: Hello, When I enter the email address, the phone number or the mailing address of ipa user 'smith' in the web ui "Identity/Users/smith", it does not appears in the output of ldapsearch. Sendmail can look into the ldap database and get the email address of a user and send mail to that user. Is it possible to add those info especially the email address in the ldap database? Regards, Fuji. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.korittki at mittwald.de Fri Oct 16 13:43:19 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Fri, 16 Oct 2015 15:43:19 +0200 Subject: [Freeipa-users] Cleanly removing replication agreement In-Reply-To: <561E5BC0.2020703@redhat.com> References: <56169000.7060302@mittwald.de> <561E1885.5000809@mittwald.de> <561E5BC0.2020703@redhat.com> Message-ID: <5620FEF7.2050305@mittwald.de> Oh yes, you are right. Makes sense to me as dirsrv is trying to get a kerberos ticket for replication but Kerberos can't read it's database from dirsrv yet, as dirsrv is still starting. I've read that in the rhel documentation. Feeling kind of dump but I guess I have never looked that critical in the logs to notice this messages. Thanks for your answer, have a nice weekend. - Dominik Am 14.10.2015 um 15:42 schrieb Mark Reynolds: > > > On 10/14/2015 04:55 AM, Dominik Korittki wrote: >> [11/Oct/2015:17:17:53 +0200] NSMMReplicationPlugin - >> agmt="cn=meToipa01.internal" (ipa01:389): Replication bind with GSSAPI >> auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >> information (No Kerberos credentials available)) >> [11/Oct/2015:17:17:56 +0200] NSMMReplicationPlugin - >> agmt="cn=meToipa01.internal" (ipa01:389): *Replication bind with >> GSSAPI auth resumed* > This last line implies that replication authentication finally did > succeed - so replication should be working. > From dkupka at redhat.com Fri Oct 16 13:52:20 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 16 Oct 2015 15:52:20 +0200 Subject: [Freeipa-users] Why are some user's information not stored in the LDAP database? In-Reply-To: References: Message-ID: <56210114.8040300@redhat.com> On 16/10/15 15:26, Fujisan wrote: > Hello, > > When I enter the email address, the phone number or the mailing address of > ipa user 'smith' in the web ui "Identity/Users/smith", it does not appears > in the output of ldapsearch. > Sendmail can look into the ldap database and get the email address of a > user and send mail to that user. > > Is it possible to add those info especially the email address in the ldap > database? > > Regards, > Fuji. > > > Hello, I just tried and it worked as expected. Could you post your ldapsearch and its result? $ ldapsearch -D"cn=Directory Manager" -w Secret123 -h localhost -b cn=users,cn=accounts,dc=example,dc=test uid=tuser1 # extended LDIF # # LDAPv3 # base with scope subtree # filter: uid=tuser1 # requesting: ALL # # tuser1, users, accounts, example.test dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=test displayName: Test User uid: tuser1 objectClass: ipaobject objectClass: person objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: organizationalperson objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh initials: TU gecos: Test User sn: User homeDirectory: /home/tuser1 mail: tuser1 at example.test krbPrincipalName: tuser1 at EXAMPLE.TEST givenName: Test cn: Test User ipaUniqueID: 0c246a30-740c-11e5-986e-001a4a231292 uidNumber: 383200003 gidNumber: 383200003 mepManagedEntry: cn=tuser1,cn=groups,cn=accounts,dc=example,dc=test memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- David Kupka From fujisan43 at gmail.com Fri Oct 16 14:01:08 2015 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 16 Oct 2015 16:01:08 +0200 Subject: [Freeipa-users] Why are some user's information not stored in the LDAP database? In-Reply-To: <56210114.8040300@redhat.com> References: <56210114.8040300@redhat.com> Message-ID: Yes, sorry, you're right. It works. I was using the wrong command: $ ldapsearch -x -h localhost uid=smith instead of $ ldapsearch -x -h localhost -D cn=directory\ manager -W -b cn=users,cn=accounts,dc=example,dc=test uid=smith On Fri, Oct 16, 2015 at 3:52 PM, David Kupka wrote: > On 16/10/15 15:26, Fujisan wrote: > >> Hello, >> >> When I enter the email address, the phone number or the mailing address of >> ipa user 'smith' in the web ui "Identity/Users/smith", it does not appears >> in the output of ldapsearch. >> Sendmail can look into the ldap database and get the email address of a >> user and send mail to that user. >> >> Is it possible to add those info especially the email address in the ldap >> database? >> >> Regards, >> Fuji. >> >> >> >> > Hello, > I just tried and it worked as expected. Could you post your ldapsearch and > its result? > > $ ldapsearch -D"cn=Directory Manager" -w Secret123 -h localhost -b > cn=users,cn=accounts,dc=example,dc=test uid=tuser1 > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: uid=tuser1 > # requesting: ALL > # > > # tuser1, users, accounts, example.test > dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=test > displayName: Test User > uid: tuser1 > objectClass: ipaobject > objectClass: person > objectClass: top > objectClass: ipasshuser > objectClass: inetorgperson > objectClass: organizationalperson > objectClass: krbticketpolicyaux > objectClass: krbprincipalaux > objectClass: inetuser > objectClass: posixaccount > objectClass: ipaSshGroupOfPubKeys > objectClass: mepOriginEntry > loginShell: /bin/sh > initials: TU > gecos: Test User > sn: User > homeDirectory: /home/tuser1 > mail: tuser1 at example.test > krbPrincipalName: tuser1 at EXAMPLE.TEST > givenName: Test > cn: Test User > ipaUniqueID: 0c246a30-740c-11e5-986e-001a4a231292 > uidNumber: 383200003 > gidNumber: 383200003 > mepManagedEntry: cn=tuser1,cn=groups,cn=accounts,dc=example,dc=test > memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Fri Oct 16 12:56:02 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 16 Oct 2015 07:56:02 -0500 Subject: [Freeipa-users] FreeIPA Deployment and resiliency In-Reply-To: References: Message-ID: With a multi master setup FreeIPA could be considered "resilient" however this is dependant on some other architectural considerations. For our customers we deploy two per location and put both servers as entries in /etc/resolv.conf. As FreeIPA service discovery is done with SRV records this approach seems to just work?. Using freeipa for DNS can be a bit of a double edged sword because it does not yet support some of the DNS features essential in complex environments such as split horizon. For vanilla installations it seems DNS is essential to FreeIPA's resilience. Trying to do IP failover or other tricks seems to cause havoc with Kerberos but we never really tried. On 16 October 2015 at 07:03, Youenn PIOLET wrote: > Hi there. > > I'd like to integrate FreeIPA in a multi-location production environment. > We got servers in US/Europe/South America/Pacific Ocean with some high > latency links. The parc I manage is a mixed linux environment with less > than 1000 servers. I also plan to use FreeIPA as backend for Radius > authentication on various network equipments. > > I plan to deploy a replica architecture similar to the recommandation > article in official Documentation: > http://www.freeipa.org/page/Deployment_Recommendations with two replicas > per region and at least one replica per DC. FreeIPA will become my DNS for > internal resolution. > > FreeIPA servers will run on latest CentOS. > > I've got two questions: > > 1) Version: > Should I wait for IPA 4.2 or is IPA 4.1.4 a good / stable / trust-full > solution for authentication, upgrade, maintainability, resilience ? Will > 4.2.X be too young and unstable for a massive implementation ? I'm quite > interested about 4.2 but don't want to wait too long for a release on > Centos. How easy would be an upgrade of all replicas from 4.1.4 to 4.2 in > an IPA replication topology? > > 2) Resiliency: > How to make FreeIPA service resilient? Is there an official / easy and > secure way to converge to an other IPA server (with DNS?) when a replica is > down? I've got the chance to work on an MPLS network with the Anycast > possibility. Is it something workable with FreeIPA/Kerberos ? > > Thanks by advance for your suggestions > -- > Youenn Piolet > piolet.y at gmail.com > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Oct 16 14:40:33 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 16 Oct 2015 16:40:33 +0200 Subject: [Freeipa-users] Why are some user's information not stored in the LDAP database? In-Reply-To: References: <56210114.8040300@redhat.com> Message-ID: <20151016144033.GX3753@p.redhat.com> On Fri, Oct 16, 2015 at 04:01:08PM +0200, Fujisan wrote: > Yes, sorry, you're right. It works. I was using the wrong command: > > $ ldapsearch -x -h localhost uid=smith > > instead of > > $ ldapsearch -x -h localhost -D cn=directory\ manager -W -b > cn=users,cn=accounts,dc=example,dc=test uid=smith > Fuji, David, please keep in mind that the Directory Manager account really can read everything in the LDAP tree and should be used with great care. While it is ok to use it to check if a specific attribute is set or not, it should not be used in the configuration of other applications to access the directory server. The mail attribute it protected by an ACI which allows access for "ldap:///all", i.e. all authenticated users. So you do not have to use the Directory Manager to read the attribute but any other account will work as well, e.g. $ ldapsearch -x -h localhost uid=smith -D uid=smith,cn=users,cn=accounts,dc=example,dc=test -W should display the mail attribute as well after entering the password for smith. HTH bye, Sumit > > > > On Fri, Oct 16, 2015 at 3:52 PM, David Kupka wrote: > > > On 16/10/15 15:26, Fujisan wrote: > > > >> Hello, > >> > >> When I enter the email address, the phone number or the mailing address of > >> ipa user 'smith' in the web ui "Identity/Users/smith", it does not appears > >> in the output of ldapsearch. > >> Sendmail can look into the ldap database and get the email address of a > >> user and send mail to that user. > >> > >> Is it possible to add those info especially the email address in the ldap > >> database? > >> > >> Regards, > >> Fuji. > >> > >> > >> > >> > > Hello, > > I just tried and it worked as expected. Could you post your ldapsearch and > > its result? > > > > $ ldapsearch -D"cn=Directory Manager" -w Secret123 -h localhost -b > > cn=users,cn=accounts,dc=example,dc=test uid=tuser1 > > # extended LDIF > > # > > # LDAPv3 > > # base with scope subtree > > # filter: uid=tuser1 > > # requesting: ALL > > # > > > > # tuser1, users, accounts, example.test > > dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=test > > displayName: Test User > > uid: tuser1 > > objectClass: ipaobject > > objectClass: person > > objectClass: top > > objectClass: ipasshuser > > objectClass: inetorgperson > > objectClass: organizationalperson > > objectClass: krbticketpolicyaux > > objectClass: krbprincipalaux > > objectClass: inetuser > > objectClass: posixaccount > > objectClass: ipaSshGroupOfPubKeys > > objectClass: mepOriginEntry > > loginShell: /bin/sh > > initials: TU > > gecos: Test User > > sn: User > > homeDirectory: /home/tuser1 > > mail: tuser1 at example.test > > krbPrincipalName: tuser1 at EXAMPLE.TEST > > givenName: Test > > cn: Test User > > ipaUniqueID: 0c246a30-740c-11e5-986e-001a4a231292 > > uidNumber: 383200003 > > gidNumber: 383200003 > > mepManagedEntry: cn=tuser1,cn=groups,cn=accounts,dc=example,dc=test > > memberOf: cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test > > > > # search result > > search: 2 > > result: 0 Success > > > > # numResponses: 2 > > # numEntries: 1 > > > > -- > > David Kupka > > > -- > 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 From tobeychris at hotmail.com Sat Oct 17 14:47:27 2015 From: tobeychris at hotmail.com (Chris Tobey) Date: Sat, 17 Oct 2015 10:47:27 -0400 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA In-Reply-To: <0a3801d10480$2d152320$873f6960$@gmail.com> References: <0a3801d10480$2d152320$873f6960$@gmail.com> Message-ID: Hi Youenn, Thank you for the response. I am sure the issue is related to the samba attributes not existing, but I am not fully clear on how to fix it. I was trying to find out the correct steps on a CentOS system, and I think it is something like: >yum remove samba-common >yum install samba4 >yum install ipa-server-trust-ad >ipa-adtrust-install I thought the ipa-adtrust-install was supposed to add the samba attributes, but for some reason it still does not work. Does anyone have any insight in what steps I might have missed? Thanks, -Chris From: Youenn PIOLET [mailto:piolet.y at gmail.com] Sent: October-11-15 6:49 PM To: Chris Tobey Cc: freeipa-users at redhat.com; Matt . Subject: Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Sorry for the double post. I forgot to say that my speech is about newest versions of FreeIPA. Maybe someone here knows something about IPA 3.0 ? I'm not sure it used to work with ipasam module. But I suppose the problem is the same: you need to generate Samba schema values for your IPA users in the directory. Cheers, -- Youenn Piolet piolet.y at gmail.com 2015-10-12 0:41 GMT+02:00 Youenn PIOLET : Hi Chris, First, to be sure were on the same page: Without IPA, to make CIFS users authenticate against directory in a classic LDAP implementation, you need to extend your LDAP tree with Samba schema. The FreeNAS documentation is a bit light on this subjet and previous FreeNAS versions (stable 9.3 included) used to mess up rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your 9.2 version. Wrote some messy stuff about it here: https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md To make CIFS users authenticate or FreeIPA recent versions (I only tried with 4.1), I suggest you to start by reading some of our investigations in this thread: [Freeipa-users] Ubuntu Samba Server Auth against IPA https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 When we discuss about this in august, I've spend almost a week trying to make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without fully understand why it didn't work, and moved our CIFS to a dedicated Centos server. Matt arrived with a similar situation in Ubuntu. To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default with ldapsam.so module. FreeIPA developpers have built a AD trust exchange possibility with a custom ipasam module that isn't compiled yet for Ubuntu or FreeNAS. This module gives the possibility to use IPA AD trust components (e.g. special schema in IPA's directory managing user/group NT SID) If you can't compile the module for FreeNAS / FreeBSD, you may need to extend 365directory with Samba schema. You will need to find a way to generate the new attributes when adding users or groups in FreeIPA, and a way to store password in a CIFS/NT understandable way. I don't suggest you to follow this dark path. You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) Good luck in your experimentations, I hope you will succeed! -- Youenn Piolet piolet.y at gmail.com 2015-10-11 2:06 GMT+02:00 Chris Tobey : Hi Everyone, I have a functioning FreeIPA server that manages all my users and I would like to also use it for my FreeNAS CIFS shares to authenticate against. Does anyone know what needs to be run on both servers to get this working? I believe it has something to do with Samba properties on the FreeIPA side. I had tried asking the FreeNAS forums but they were of no help (https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/). I have seen similar requests and success stories, but no actual steps on how to do it. Info: FreeIPA v3.0.0-42 running on CentOS 6.6. FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working before dealing with certs). Any help is appreciated. Thanks, -Chris -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wibrown at redhat.com Sun Oct 18 22:05:45 2015 From: wibrown at redhat.com (William Brown) Date: Mon, 19 Oct 2015 08:05:45 +1000 Subject: [Freeipa-users] FreeIPA and DHCP In-Reply-To: <5620F51F.8060606@mmfg.it> References: <5620F51F.8060606@mmfg.it> Message-ID: <1445205945.12828.31.camel@redhat.com> On Fri, 2015-10-16 at 15:01 +0200, Nicola Canepa wrote: > Hello. > Is there a suggested way to have DHCP IP/MAC associations managed > through the IPA web interface? > > Thank you for any pointer. Hi, There is currently no way to manage DHCP with FreeIPA. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ftweedal at redhat.com Sun Oct 18 22:35:42 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 19 Oct 2015 08:35:42 +1000 Subject: [Freeipa-users] FreeIPA and DHCP In-Reply-To: <5620F51F.8060606@mmfg.it> References: <5620F51F.8060606@mmfg.it> Message-ID: <20151018223542.GQ11271@dhcp-40-8.bne.redhat.com> On Fri, Oct 16, 2015 at 03:01:19PM +0200, Nicola Canepa wrote: > Hello. > Is there a suggested way to have DHCP IP/MAC associations managed through > the IPA web interface? > > Thank you for any pointer. > > Nicola > Hi Nicola, There was an old design proposal[1] but it was not implemented. The discussion was revived in recent weeks but again the feeling is that there is not a great need. [1] http://www.freeipa.org/page/DHCP_Integration_Design Let us know more about your use case and expectations - more real-world requirements will help inform the discussion! Cheers, Fraser > -- > > Nicola Canepa > Tel: +39-0522-399-3474 > canepa.n at mmfg.it > --- > Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. > > The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. > > -- > 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 From simon.williams at thehelpfulcat.com Sun Oct 18 22:35:58 2015 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Sun, 18 Oct 2015 22:35:58 +0000 Subject: [Freeipa-users] FreeIPA and DHCP In-Reply-To: <1445205945.12828.31.camel@redhat.com> References: <5620F51F.8060606@mmfg.it> <1445205945.12828.31.camel@redhat.com> Message-ID: Well, that's true, but I do do it indirectly. I assign fixed addresses for servers by MAC address and host name in DHCP and manage the IP address of that host through FreeIPA DNS. If you tell DHCP that a particular MAC address is a particular host name, when that host requests a DHCP allocated address, the DHCP server does a DNS lookup on the host name and gives the machine a lease on the address. I have no idea if that is intended behaviour or if it is something that isn't a good idea for some reason, I discovered that it worked by accident! It has simplified my small setup however as DNS and therefore FreeIPA control the fixed IP addresses of the servers. I do have to remember to set up each fixed address's MAC address and host name in the DHCP configuration when I create it, but it makes reconfiguring fixed IP addresses a breeze. It ought to be possible to script synchronisation of the DHCP configuration with the host information in FreeIPA, but I only deal with a handful of machines, so I've never bothered. On Sun, 18 Oct 2015 23:12 William Brown wrote: > On Fri, 2015-10-16 at 15:01 +0200, Nicola Canepa wrote: > > Hello. > > Is there a suggested way to have DHCP IP/MAC associations managed > > through the IPA web interface? > > > > Thank you for any pointer. > > Hi, > > There is currently no way to manage DHCP with FreeIPA. > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Brisbane > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From canepa.n at mmfg.it Mon Oct 19 07:05:14 2015 From: canepa.n at mmfg.it (Nicola Canepa) Date: Mon, 19 Oct 2015 09:05:14 +0200 Subject: [Freeipa-users] FreeIPA and DHCP In-Reply-To: <20151018223542.GQ11271@dhcp-40-8.bne.redhat.com> References: <5620F51F.8060606@mmfg.it> <20151018223542.GQ11271@dhcp-40-8.bne.redhat.com> Message-ID: <5624962A.1000000@mmfg.it> I have a RADIUS which authenticates WPA2 via FreeIPA (LDAP) associating the MAC address to the client (by improperly using the "l" field), and I would delegate also DHCP IP management (which has to be fixed through the MAC address) via the same interface. If it is not possible, I will have to configure another LDAP server, and to find a management GUI. Nicola Il 19/10/15 00:35, Fraser Tweedale ha scritto: > On Fri, Oct 16, 2015 at 03:01:19PM +0200, Nicola Canepa wrote: >> Hello. >> Is there a suggested way to have DHCP IP/MAC associations managed through >> the IPA web interface? >> >> Thank you for any pointer. >> >> Nicola >> > Hi Nicola, > > There was an old design proposal[1] but it was not implemented. The > discussion was revived in recent weeks but again the feeling is that > there is not a great need. > > [1] http://www.freeipa.org/page/DHCP_Integration_Design > > Let us know more about your use case and expectations - more > real-world requirements will help inform the discussion! > > Cheers, > Fraser > >> -- >> >> Nicola Canepa >> Tel: +39-0522-399-3474 >> canepa.n at mmfg.it >> --- >> Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. >> >> The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. >> >> -- >> 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 -- Nicola Canepa Tel: +39-0522-399-3474 canepa.n at mmfg.it --- Il contenuto della presente comunicazione ? riservato e destinato esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona diversa dal destinatario sono proibite la diffusione, la distribuzione e la copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati contenuti. La presente comunicazione (comprensiva dei documenti allegati) non avr? valore di proposta contrattuale e/o accettazione di proposte provenienti dal destinatario, n? rinuncia o riconoscimento di diritti, debiti e/o crediti, n? sar? impegnativa, qualora non sia sottoscritto successivo accordo da chi pu? validamente obbligarci. Non deriver? alcuna responsabilit? precontrattuale a ns. carico, se la presente non sia seguita da contratto sottoscritto dalle parti. The content of the above communication is strictly confidential and reserved solely for the referred addressees. In the event of receipt by persons different from the addressee, copying, alteration and distribution are forbidden. If received by mistake we ask you to inform us and to destroy and/or delete from your computer without using the data herein contained. The present message (eventual annexes inclusive) shall not be considered a contractual proposal and/or acceptance of offer from the addressee, nor waiver recognizance of rights, debts and/or credits, nor shall it be binding when not executed as a subsequent agreement by persons who could lawfully represent us. No pre-contractual liability shall apply to us when the present communication is not followed by any binding agreement between the parties. From f.zoske at euroimmun.de Mon Oct 19 08:39:30 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Mon, 19 Oct 2015 08:39:30 +0000 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151016083214.GJ14465@hendrix.arn.redhat.com> References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> Message-ID: Hi Jakub, I think there is a package missing. When I try to install the packages you provided, yum exits with an error. " Requires: python-sssdconfig = 1.12.2-58.el7_1.18 " Can you provide me this package or tell me where to find it? Best regards, Fabian -----Urspr?ngliche Nachricht----- Von: Jakub Hrozek [mailto:jhrozek at redhat.com] Gesendet: Freitag, 16. Oktober 2015 10:32 An: Zoske, Fabian Cc: freeipa-users at redhat.com Betreff: Re: [Freeipa-users] SUDO does not always works on first try On Tue, Oct 13, 2015 at 07:19:20AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > thanks for looking through the data. Sorry for late reply. > > I can not access the bug you mentioned. I already created an account for Bugzilla, but so far nothing. Ah, it's probably marked as private b/c it contains some private customer information.. > > In the second query there is a group which isn't present in the first one ((sudoUser=%ug_freeipa-administrators_int)). This is the IPA-equivalent of the AD-Group (ug_freeipa-administrators). > AD -> IPA_EXT -> IPA_INT Then it sounds like the bug we solved lately, can you try installing these packages on the IPA server (yes, server, not client): https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.1-external-group/ > > The second command you mentioned works and returns the correct passwd entry for my user. The first command ist not found on the client. > > Best regards, > Fabian > ________________________________________ > From: Jakub Hrozek [jhrozek at redhat.com] > Sent: Monday, October 12, 2015 11:47 > To: Zoske, Fabian > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] SUDO does not always works on first try > > On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote: > > Hi Jakub, > > > > I increased the log level in every SSSD section to 6 and got following output, hope that helps. > > > > KRB5_CHILD.LOG: https://s.mit42.de/IR6tu > > All is OK here.. > > > > > SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl > > So the interesting part is that the first try doesn't match any rules > for the user: > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid] > (0x0400): No such entry > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=+*)))] > (Fri Oct 9 12:24:09 2015) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for > [f.zoske at de.eu.local] > > While the second does: > (Fri Oct 9 12:24:14 2015) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%dom?nen-benutzer at de.eu.local)(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))] > (Fri Oct 9 12:24:14 2015) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for > [f.zoske at de.eu.local] > > It would be interesting to see the dump of the cache from when 0 rules > are returned. I suspect the user's membership wouldn't be correct, > which might be because of the bug I linked earlier. > > > > > SSSD_IPA-LX.COM: https://s.mit42.de/frBvx > > There are some failures here: > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] > (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) > [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] > (0x0400): ldap_extended_operation result: No such object(32), (null) > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] > [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback] > (0x0100): Request processed. Returned 3,1432158221,Account info lookup > failed (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] > [be_get_account_info] > (0x0100): Got request for [4097][1][name=*] (Fri Oct 9 12:24:19 2015) > [sssd[be[ipa-lx.com]]] [be_req_set_domain] > (0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local] > (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] > (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) > [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] > (0x0400): ldap_extended_operation result: No such object(32), (null) > > But I think this is a really minor bug we fixed later where we marked > requests as failed if they simply didn't find anything. If this works > without issues: > $ sss_cache -u f.zoske at de.eu.local > $ getent passwd f.zoske at de.eu.local > > Then you can ignore those.. From lslebodn at redhat.com Mon Oct 19 08:51:51 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 19 Oct 2015 10:51:51 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> Message-ID: <20151019085150.GB27762@mail.corp.redhat.com> On (19/10/15 08:39), Zoske, Fabian wrote: >Hi Jakub, > >I think there is a package missing. >When I try to install the packages you provided, yum exits with an error. >" Requires: python-sssdconfig = 1.12.2-58.el7_1.18 " > python-sssdconfig is noarch package which is missing in https://jhrozek.fedorapeople.org/sssd-test-builds/ I hope Jakub will upload it. >Can you provide me this package or tell me where to find it? > Alternatively, you can test backported version from fedora 21. It is the latest 1.12 release + few bugfixes. https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/ LS From jhrozek at redhat.com Mon Oct 19 11:23:31 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 19 Oct 2015 13:23:31 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151019085150.GB27762@mail.corp.redhat.com> References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> <20151019085150.GB27762@mail.corp.redhat.com> Message-ID: <20151019112331.GA1668@hendrix.redhat.com> On Mon, Oct 19, 2015 at 10:51:51AM +0200, Lukas Slebodnik wrote: > On (19/10/15 08:39), Zoske, Fabian wrote: > >Hi Jakub, > > > >I think there is a package missing. > >When I try to install the packages you provided, yum exits with an error. > >" Requires: python-sssdconfig = 1.12.2-58.el7_1.18 " > > > python-sssdconfig is noarch package which is missing in > https://jhrozek.fedorapeople.org/sssd-test-builds/ > I hope Jakub will upload it. Yes, sorry, I keep forgetting the package since it's noarch and it shows in a different part of the buildsystem page. Uploaded now. From piolet.y at gmail.com Mon Oct 19 12:33:34 2015 From: piolet.y at gmail.com (Youenn PIOLET) Date: Mon, 19 Oct 2015 14:33:34 +0200 Subject: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA In-Reply-To: References: <0a3801d10480$2d152320$873f6960$@gmail.com> Message-ID: Hi Chris, This may come from the ipa attributes added by adtrust on user/group classes. For example in 4.1.4: FreeIPA will add on each user the attribute (for ipasam.so usage): ipaNTSecurityIdentifier: S-1-5-**-******* when standard samba attributes known by samba with ldapsam.so are: sambaSID: S-1-5-**-******* I guess as the OID must be different, your CIFS will not recognise the attribute and won't be able to use it. I also guess it is the same for the password hash that may not be using the right algorithm. You can check this directly in your IPA 365directory tree, and with dirsrv logfiles. I suppose you would see FreeNAS trying to search for specific attributes in user objects that don't exist. These informations are based on deduction but I'm not confident enough to assure you this is a fact :) -- Youenn Piolet piolet.y at gmail.com 2015-10-17 16:47 GMT+02:00 Chris Tobey : > Hi Youenn, > > > > Thank you for the response. > > > > I am sure the issue is related to the samba attributes not existing, but I > am not fully clear on how to fix it. > > > > I was trying to find out the correct steps on a CentOS system, and I think > it is something like: > > >yum remove samba-common > > >yum install samba4 > > >yum install ipa-server-trust-ad > > >ipa-adtrust-install > > > > I thought the ipa-adtrust-install was supposed to add the samba > attributes, but for some reason it still does not work. > > > > Does anyone have any insight in what steps I might have missed? > > > > Thanks, > > -Chris > > > > *From:* Youenn PIOLET [mailto:piolet.y at gmail.com] > *Sent:* October-11-15 6:49 PM > *To:* Chris Tobey > *Cc:* freeipa-users at redhat.com; Matt . > *Subject:* Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA > > > > Sorry for the double post. > > > > I forgot to say that my speech is about newest versions of FreeIPA. > > Maybe someone here knows something about IPA 3.0 ? > > I'm not sure it used to work with ipasam module. But I suppose the problem > is the same: you need to generate Samba schema values for your IPA users in > the directory. > > > > Cheers, > > > -- > > Youenn Piolet > > piolet.y at gmail.com > > > > > > 2015-10-12 0:41 GMT+02:00 Youenn PIOLET : > > Hi Chris, > > > > First, to be sure were on the same page: > > Without IPA, to make CIFS users authenticate against directory in a > classic LDAP implementation, you need to extend your LDAP tree with Samba > schema. The FreeNAS documentation is a bit light on this subjet and > previous FreeNAS versions (stable 9.3 included) used to mess up > rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your > 9.2 version. Wrote some messy stuff about it here: > https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md > > > > To make CIFS users authenticate or FreeIPA recent versions (I only tried > with 4.1), I suggest you to start by reading some of our investigations in > this thread: > > > > [Freeipa-users] Ubuntu Samba Server Auth against IPA > > https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 > > > > When we discuss about this in august, I've spend almost a week trying to > make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without > fully understand why it didn't work, and moved our CIFS to a dedicated > Centos server. Matt arrived with a similar situation in Ubuntu. > > > > To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default > with ldapsam.so module. FreeIPA developpers have built a AD trust exchange > possibility with a custom ipasam module that isn't compiled yet for Ubuntu > or FreeNAS. This module gives the possibility to use IPA AD trust > components (e.g. special schema in IPA's directory managing user/group > NT SID) > > > > If you can't compile the module for FreeNAS / FreeBSD, you may need to > extend 365directory with Samba schema. > > You will need to find a way to generate the new attributes when adding > users or groups in FreeIPA, and a way to store password in a CIFS/NT > understandable way. I don't suggest you to follow this dark path. > > > > You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) > > > > Good luck in your experimentations, I hope you will succeed! > > > > > -- > > Youenn Piolet > > piolet.y at gmail.com > > > > > > 2015-10-11 2:06 GMT+02:00 Chris Tobey : > > Hi Everyone, > > > I have a functioning FreeIPA server that manages all my users and I would > like to also use it for my FreeNAS CIFS shares to authenticate against. > > Does anyone know what needs to be run on both servers to get this working? > I believe it has something to do with Samba properties on the FreeIPA side. > > > > I had tried asking the FreeNAS forums but they were of no help ( > https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/ > ). > > > > I have seen similar requests and success stories, but no actual steps on > how to do it. > > Info: > FreeIPA v3.0.0-42 running on CentOS 6.6. > FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working > before dealing with certs). > > > > Any help is appreciated. > > > > Thanks, > > -Chris > > > > > > > > > > -- > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Mon Oct 19 14:14:37 2015 From: jochen at jochen.org (Jochen Hein) Date: Mon, 19 Oct 2015 16:14:37 +0200 Subject: [Freeipa-users] FreeIPA and DHCP In-Reply-To: <1445205945.12828.31.camel@redhat.com> (William Brown's message of "Mon, 19 Oct 2015 08:05:45 +1000") References: <5620F51F.8060606@mmfg.it> <1445205945.12828.31.camel@redhat.com> Message-ID: <836123q71u.fsf@echidna.jochen.org> William Brown writes: > On Fri, 2015-10-16 at 15:01 +0200, Nicola Canepa wrote: >> Hello. >> Is there a suggested way to have DHCP IP/MAC associations managed >> through the IPA web interface? > > There is currently no way to manage DHCP with FreeIPA. Freeipa hosts do have MAC values as a field and there is an IP address assigned. I've found a script to extract the info for isc DHCP at http://lesloueizeh.com/jdieter/freeipa-dhcpd/generate_dhcp.py I've implemented a script for using with dnsmasq: -------------- cut here ------------------------- #!/bin/bash out=/etc/dnsmasq.d/dynamic-hosts.conf #out=/tmp/xxx tmp=/etc/dnsmasq.d/dynamic-hosts.conf.tmp KRBPRINC='host/echidna.jochen.org at JOCHEN.ORG' kinit -k $KRBPRINC cat > $tmp <> $tmp if cmp -s $out $tmp; then rm -f $tmp else mv $tmp $out systemctl restart dnsmasq.service fi kdestroy -------------- cut here ------------------------- Jochen -- The only problem with troubleshooting is that the trouble shoots back. From rcritten at redhat.com Mon Oct 19 20:06:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Oct 2015 16:06:17 -0400 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <561FC1D8.7040807@jmips.co.uk> References: <561FC1D8.7040807@jmips.co.uk> Message-ID: <56254D39.3000303@redhat.com> James Masson wrote: > > Hi list, > > I successfully have IPA working with CA certs signed by an upstream Dogtag. > > Now I'm trying to use a CA cert signed by a different type of CA - Vault. > > Setup fails, using the same 2 step IPA setup process as used with > upstream Dogtag. I've also tried the external-ca-type option. > > Likely, IPA doesn't like the certificate - however, I can't pinpoint why. I'm guessing you don't include the entire CA certchain of Vault. Dogtag is failing to startup because it can't verify its own cert chain: 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] CAPresence: CA is present 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] SystemCertsVerification: system certs verification failure 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! rob > > Errors below. > > thanks > > James M > > ### > -----BEGIN CERTIFICATE----- > MIIDdzCCAl+gAwIBAgIUTKucjDpTMZ/oPmgnxR1MznVhktkwDQYJKoZIhvcNAQEL > BQAwVjEZMBcGA1UEAxMQbXljYS5leGFtcGxlLmNvbTE5MDcGA1UEBRMwNjQ2Mjcx > MDAwODA3NTg1NjA0ODA0NzYyODExNzAyMTM0NDk5MDQ1ODM4NjM2OTEwMB4XDTE1 > MTAxNTE0MzY1NloXDTE1MTAxNjAwMzY1NlowMDEOMAwGA1UEChMFTE9DQUwxHjAc > BgNVBAMTFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQAD > ggEPADCCAQoCggEBANMByCz97mhj8nG/R7T5K/lUlat4jnfFyo5/xn4eTzhcqDD/ > NixixWqT6TPWBg5Mep7Wnn0EBwG9DjB2dq6+9Ai3TGMzFWkeKvMrZuTouLFoS9SR > 6s5wybFfbAoTuV5lq0rIZClqi6ELnAyOccQEuV4UA0PBoe1UjycZf20eSU/52eH4 > SiMbLYliDOuWbARgYYwtwc7HVPUwangk4toPH6h2FZ9+tTj8oB6Zxf3lK65IzyCT > IHj+53gyySB78CDV2FZ67cI5u1KKcpC/CyjkbO4DKHWWxzxuvUM4F0K20l+cMoP6 > Kpr7aGYotY3B6uTocMg59Gwlsvgl0gE03LI9Vp0CAwEAAaNjMGEwHQYDVR0OBBYE > FLjG7oRluBaMxV5Wi6rBSvgHDzjuMB8GA1UdIwQYMBaAFCw0iwWuCOlUcS6ZIPM8 > X50f1nLnMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgHGMA0GCSqGSIb3 > DQEBCwUAA4IBAQBVAoAuZgu6RkY0ufVcNDDNORgOwSgNbvyt1rQNC5mxhLw0Ott+ > XyxuzgycyEFCdQP1VChG5i0nOfrEixX7eSQVgN3LKaeiRVsGh1H+ucp/YVnhPvc1 > lLtAHVwPn+OuvdJR68K3/twtZ4Fh0BtRFeAmuIOk+QomDhxsxt8LgbaPbdS/vuZw > Xn27REGErgT8bDWp447YU6pOb+rPj9ZNHdS1TeDG5h1A0ArH5IUVgyASFkM4SEVH > pKneAWEDy+Ik67FoYQbHpYyII1L7R5vskZZv1xhYkH8csJ8iTcrRCa+EiBvhtsWg > uuHzqst1ryPKdNtxPM+D96vRSJxCYBUFeKqh > -----END CERTIFICATE----- > ### > > ### > [19/27]: restarting certificate server > ipa : CRITICAL Failed to restart the certificate server. See the > installation log for details. > [20/27]: requesting RA certificate from CA > [error] RuntimeError: Unable to submit RA cert request > ### > > > ### > 2015-10-15T14:44:31Z DEBUG The CA status is: check interrupted > 2015-10-15T14:44:31Z DEBUG Waiting for CA to start... > 2015-10-15T14:44:32Z DEBUG request > 'https://foo.local:8443/ca/admin/ca/getStatus' > 2015-10-15T14:44:32Z DEBUG request body '' > 2015-10-15T14:44:32Z DEBUG request status 404 > 2015-10-15T14:44:32Z DEBUG request reason_phrase u'Not Found' > 2015-10-15T14:44:32Z DEBUG request headers {'date': 'Thu, 15 Oct 2015 > 14:44:32 GMT', 'content-length': '993', 'content-type': > 'text/html;charset=utf-8', 'content-language': 'en', 'server': > 'Apache-Coyote/1.1'} > 2015-10-15T14:44:32Z DEBUG request body 'Apache > Tomcat/7.0.54 - Error report >

HTTP Status 404 - /ca/admin/ca/getStatus

size="1" noshade="noshade">

type Status > report

message > /ca/admin/ca/getStatus

description The requested > resource is not availa > ble.

Apache > Tomcat/7.0.54

' > 2015-10-15T14:44:32Z DEBUG The CA status is: check interrupted > 2015-10-15T14:44:32Z DEBUG Waiting for CA to start... > 2015-10-15T14:44:33Z DEBUG Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 840, in __restart_instance > self.restart(self.dogtag_constants.PKI_INSTANCE_NAME) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 282, in restart > self.service.restart(instance_name, capture_output=capture_output, > wait=wait) > File > "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 209, in restart > self.wait_until_running() > File > "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 197, in wait_until_running > raise RuntimeError('CA did not start in %ss' % timeout) > RuntimeError: CA did not start in 300.0s > > 2015-10-15T14:44:33Z CRITICAL Failed to restart the certificate server. > See the installation log for details. > 2015-10-15T14:44:33Z DEBUG duration: 303 seconds > 2015-10-15T14:44:33Z DEBUG [20/27]: requesting RA certificate from CA > 2015-10-15T14:44:33Z DEBUG Starting external process > 2015-10-15T14:44:33Z DEBUG args='/usr/bin/certutil' '-d' > '/etc/httpd/alias' '-f' XXXXXXXX '-R' '-k' 'rsa' '-g' '2048' '-s' > 'CN=IPA RA,O=LOCAL' '-z' '/tmp/tmpKsFaxb' '-a' > 2015-10-15T14:44:34Z DEBUG Process finished, return code=0 > 2015-10-15T14:44:34Z DEBUG stdout= > Certificate request generated by Netscape certutil > Phone: (not specified) > > Common Name: IPA RA > Email: (not specified) > Organization: LOCAL > State: (not specified) > Country: (not specified) > > > -----BEGIN NEW CERTIFICATE REQUEST----- > MIICZjCCAU4CAQAwITEOMAwGA1UEChMFTE9DQUwxDzANBgNVBAMTBklQQSBSQTCC > ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALDlLPK38QR37gUAVj8GSXv/ > VdxsPkGpPuGrtvKbOXXH35I2que06JswL2i4Cj29v9ZgNQgN3EACVFvADv/zUumI > 9bdF6wrH+pK4HErRSjICPxXjYZZnPoUcprGQ+/vQiDsk4pt4EyWZZfD/kGKj7BV6 > 7A2kMumYmLGIH/A24s8qNix3Ho/Ttsogjrpgg+n9G4WkntQJefTrrDv3wt1+lmo4 > IIXUsmkLUB31iRifEf8umHhUcneL8uaxMCLY1X5uSkXVQmTK97bYqQu/EbrC4XZ/ > dFx6LS9FKukEGJnX9GaFF59TvTN8ImLc4aUOvErOutbiAttQrKacfcSPv7uGqpcC > AwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAAJ0Hfvk315MKgL2/2e+A5M1NS7EBn > Ukqsnoo2onAa/8CXiFjcdUnpJ4fVn/FnH8ECRrMjUxB8mJ/EsZnuOym17+lNI0mp > wx5vkwL9kybawSEQSWMT80uefRzhZAze1vN/LgXZ4ysdRW5p2BQ3898M9HFrqE0s > 4XzLNTg07v0RbJ3veHt1wSWoy/v0zp3RRy/du3cczYTYwJ1P3GokFIuPT1fSAzBV > yovcJnB3FrrLvPyGAKmhKaoW3UejmE0G/8xpCaFp4+4LuVHNyiya79kzJMpkOoQ3 > 3MxVB6oLfL/QGnY+3025BXNwIhf4zfL4FlKhyaQ4R0pEUZeMoyksgsxb > -----END NEW CERTIFICATE REQUEST----- > > 2015-10-15T14:44:34Z DEBUG stderr= > > Generating key. This may take a few moments... > > > 2015-10-15T14:44:34Z DEBUG Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 382, in start_creation > run_step(full_msg, method) > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 372, in run_step > method() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1156, in __request_ra_certificate > raise RuntimeError("Unable to submit RA cert request") > RuntimeError: Unable to submit RA cert request > > 2015-10-15T14:44:34Z DEBUG [error] RuntimeError: Unable to submit RA > cert request > 2015-10-15T14:44:34Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 646, in run_script > return_value = main_function() > > File "/sbin/ipa-server-install", line 1170, in main > ca_signing_algorithm=options.ca_signing_algorithm) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 520, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 382, in start_creation > run_step(full_msg, method) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 372, in run_step > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1156, in __request_ra_certificate > raise RuntimeError("Unable to submit RA cert request") > > 2015-10-15T14:44:34Z DEBUG The ipa-server-install command failed, > exception: RuntimeError: Unable to submit RA cert request > ### > > > ### > 0.localhost-startStop-1 - [15/Oct/2015:14:39:26 UTC] [20] [1] > SelfTestSubsystem: Self test plugins have been successfully loaded! > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > SelfTestSubsystem: Running self test plugins specified to be executed at > startup: > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > CAPresence: CA is present > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > SystemCertsVerification: system certs verification failure > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > SelfTestSubsystem: The CRITICAL self test plugin called > selftests.container.instance.SystemCertsVerification running at startup > FAILED! > ### > > ### > [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=subsystemCert > cert-pki-ca] CIMC certificate verification > > [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=audit_signing > [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: > verifySystemCertByTag(audit_signing) > [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(auditSigningCert cert-pki-ca,ObjectSigner) > [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [15/Oct/2015:14:39:27][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() passed: auditSigningCert cert-pki-ca > [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Success][CertNickName=auditSigningCert > cert-pki-ca] CIMC certificate verification > > java.lang.Exception: SystemCertsVerification: system certs verification > failure > at > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > at > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > at > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > at > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1738) > at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1185) > at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > at > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > at javax.servlet.GenericServlet.init(GenericServlet.java:158) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > at > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > at > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > at > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > at > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > at > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > at > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > at > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > at > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > at > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > at > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > at java.lang.Thread.run(Thread.java:745) > [15/Oct/2015:14:39:27][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > self tests execution (see selftests.log for details) > ##### > From martin at stefany.eu Tue Oct 20 21:25:56 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Tue, 20 Oct 2015 23:25:56 +0200 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users Message-ID: <1445376356.31026.15.camel@stefany.eu> Hello, did anybody manage to get FreeIPA admin user (member of admins group, full sudo access, etc.) to be also Cockpit user with administrative privileges? I've already figured out that it's closely related to Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... I was not able to get a working configuration. Some version / configuration details: $ cat /etc/centos-release CentOS Linux release 7.1.1503 (Core) $ rpm -q ipa-client ipa-client-4.1.0-18.el7.centos.4.x86_64 $ rpm -q cockpit # from sgallagh's COPR repository cockpit-0.80-1.el7.centos.x86_64 $ rpm -q polkit polkit-0.112-5.el7.x86_64 $ sudo ls /etc/polkit-1/rules.d/ 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules polkit.addAdminRule(function(action, subject) { return ["unix-group:admins", "unix-group:wheel"]; }); $ sudo ls /etc/polkit-1/localauthority.conf.d/ 40-custom.conf $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf [Configuration] AdminIdentities=unix-group:admins;unix-group:wheel $ ipa user-show martin | grep groups Member of groups: trust admins, ipausers, admins, ... Cockpit logs me in automatically using Kerberos (GSSAPI), but I can't perform administrative tasks, cannot see journald, etc. One thing that I thought to cause the issue is that pkexec is asking me select user first, instead of asking/not asking for password: $ pkexec cockpit-bridge ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/usr/bin/cockpit-bridge' as the super user Multiple identities can be used for authentication: 1. Martin ?tefany (martin) 2. ... 3. ... Choose identity to authenticate as (1-3): 1 Password: ==== AUTHENTICATION COMPLETE === cockpit-bridge: no option specified and documentation claims that sudo / pkexec should not ask for password for particular user, but 1. I don't like that idea; 2. I have regular 1000:1000 user in wheel group for whom everything works just fine - sudo and pkexec ask for password as expected, and still in cockpit admin stuff works as expected. Thank you! Regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5715 bytes Desc: not available URL: From jhrozek at redhat.com Wed Oct 21 07:32:53 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 21 Oct 2015 09:32:53 +0200 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <1445376356.31026.15.camel@stefany.eu> References: <1445376356.31026.15.camel@stefany.eu> Message-ID: <20151021073253.GH3084@hendrix.redhat.com> On Tue, Oct 20, 2015 at 11:25:56PM +0200, Martin ?tefany wrote: > Hello, > > did anybody manage to get FreeIPA admin user (member of admins group, > full sudo access, etc.) to be also Cockpit user with administrative > privileges? I've already figured out that it's closely related to > Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... I > was not able to get a working configuration. > > Some version / configuration details: > $ cat /etc/centos-release > CentOS Linux release 7.1.1503 (Core) > > $ rpm -q ipa-client > ipa-client-4.1.0-18.el7.centos.4.x86_64 > > $ rpm -q cockpit # from sgallagh's COPR repository > cockpit-0.80-1.el7.centos.x86_64 > > $ rpm -q polkit > polkit-0.112-5.el7.x86_64 > > $ sudo ls /etc/polkit-1/rules.d/ > 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules > > $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules > polkit.addAdminRule(function(action, subject) { > return ["unix-group:admins", "unix-group:wheel"]; > }); > > $ sudo ls /etc/polkit-1/localauthority.conf.d/ > 40-custom.conf > > $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf > [Configuration] > AdminIdentities=unix-group:admins;unix-group:wheel > > $ ipa user-show martin | grep groups > Member of groups: trust admins, ipausers, admins, ... > > Cockpit logs me in automatically using Kerberos (GSSAPI), but I can't > perform administrative tasks, cannot see journald, etc. > > One thing that I thought to cause the issue is that pkexec is asking me > select user first, instead of asking/not asking for password: > $ pkexec cockpit-bridge > ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === > Authentication is needed to run `/usr/bin/cockpit-bridge' as the super > user > Multiple identities can be used for authentication: > 1. Martin ?tefany (martin) > 2. ... > 3. ... > Choose identity to authenticate as (1-3): 1 > Password: > ==== AUTHENTICATION COMPLETE === > cockpit-bridge: no option specified > > and documentation claims that sudo / pkexec should not ask for password > for particular user, but 1. I don't like that idea; 2. I have regular > 1000:1000 user in wheel group for whom everything works just fine - sudo > and pkexec ask for password as expected, and still in cockpit admin > stuff works as expected. Can you add the admin user to the wheel group on the Cockpit machine? But in general I think you're looking for: https://sourceware.org/glibc/wiki/Proposals/GroupMerging first round of patches is ready, although it still needs to go through upstream review (IIRC). From d.korittki at mittwald.de Wed Oct 21 13:56:10 2015 From: d.korittki at mittwald.de (Dominik Korittki) Date: Wed, 21 Oct 2015 15:56:10 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <56153A7F.1080103@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> <5614E389.4010001@redhat.com> <56151D5E.2040102@redhat.com> <56153451.2030308@mittwald.de> <56153A7F.1080103@redhat.com> Message-ID: <5627997A.4030907@mittwald.de> Am 07.10.2015 um 17:30 schrieb thierry bordaz: > On 10/07/2015 05:03 PM, Dominik Korittki wrote: >> >> >> Am 07.10.2015 um 15:25 schrieb thierry bordaz: >>> On 10/07/2015 11:19 AM, Martin Kosek wrote: >>>> On 10/05/2015 02:13 PM, Dominik Korittki wrote: >>>>> >>>>> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >>>>>> Dominik Korittki wrote: >>>>>>> Hello folks, >>>>>>> >>>>>>> I am running two FreeIPA Servers with around 100 users and around >>>>>>> 15.000 >>>>>>> hosts, which are used by users to login via ssh. The FreeIPA servers >>>>>>> (which are Centos 7.0) ran good for a while, but as more and more >>>>>>> hosts >>>>>>> got migrated to serve as FreeIPA hosts, it started to get slow and >>>>>>> unstable. >>>>>>> >>>>>>> For example, its hard to maintain hostgroups, which have more than >>>>>>> 1.000 >>>>>>> hosts. The ipa host-* commands are getting slower as the hostgroup >>>>>>> grows. Is this normal? >>>>>> You mean the ipa hostgroup-* commands? Whenever the entry is >>>>>> displayed >>>>>> (show and add) it needs to dereference all members so yes, it is >>>>>> understandable that it gets somewhat slower with more members. How >>>>>> slow >>>>>> are we talking about? >>>>>> >>>>>>> We also experience random dirsrv segfaults. Here's a dmesg line >>>>>>> from the >>>>>>> latest: >>>>>>> >>>>>>> [690787.647261] traps: ns-slapd[5217] general protection >>>>>>> ip:7f8d6b6d6bc1 >>>>>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >>>>>> You probably want to start here: >>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >>>>> A stacktrace from the latest crash is attached to this email. After >>>>> restarting >>>>> the service, this is what I get in >>>>> /var/log/dirsrv/slapd-INTERNAL/errors >>>>> (hostname is ipa01.internal): >>>> Ludwig or Thierry, can you please take a look at the stack and file >>>> 389-DS >>>> ticket if appropriate? >>> >>> Hello Dominik, >>> >>> DS is crashing during a BIND and from the arguments values we can guess >>> it was due to a heap corruption that corrupted it operation pblock. >>> This bind operation was likely victim of the heap corruption more than >>> responsible of it. >>> >>> Using valgrind is the best way to track such problem but as you already >>> suffer from bad performance I doubt it would be acceptable. >>> How frequently does it crash ? did you identify a kind of test case ? >> >> At first the crashes happenend at a daily basis. Simply restarting the >> dirsrv daemon resolved the issue for another day but later on the >> daemon did not survive more than 15 minutes most of the time. There >> were exceptions though. Sometimes the daemon ran for several hours >> until it chrashed. >> I did not really identify a testcase. However, I supposed it could >> have something to do with replication, as I have seen replication >> related errors in dirsrv error log (mentioned in an earlier mail in >> this topic). > heap corruption are usually dynamic and if the server became more and > more slow, it could change the dynamic in favor of heap corruption. >> >> So did the following: >> ipa01 has a replication agreement with ipa02. ipa01 was the one with >> segfaults. I removed ipa01 from the replication agreement >> (ipa-replica-manage del), did an ipa-server-install --uninstall on >> ipa01 and created ipa01 as a replica of ipa02. Since then I did not >> experience any crashes (for now). >> Instead i'm having trouble rebuilding a clean replication agreement >> (old RUV stuff still in database), but thats another story I will >> eventually post on the mailinglist as a new topic. >> >> As for valgrind: Never used it before. Is there a handy explanation of >> how to use it in combination with 389ds? If I still experience those >> crashes and I get it managed to use I could try it out. > You may follow this procedure > http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind > (but remove --leak-check=yes because this is not a leak issue) > > thanks > thierry I experienced segmentation faults again on host ipa01, even after I rebuild the replication topology as described in previous mail. I followed your advice and ran valgrind last evening. Sadly I forgot to remove --leak-check=yes, but I hope the information is still useful to you. If not, I'll do it again without --leak-check=yes. Running under valgrind, the ns-slapd process needed quiet some time until it openened its ports. You can see this by watching the error logs: [20/Oct/2015:22:27:41 +0200] - 389-Directory/1.3.1.6 B2014.219.1825 starting up [20/Oct/2015:22:27:42 +0200] - WARNING: userRoot: entry cache size 10485760B is less than db size 142483456B; We recommend to increase the entry cache size nsslapd-cachememsize. [20/Oct/2015:22:27:44 +0200] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=internal [20/Oct/2015:23:09:16 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [20/Oct/2015:23:09:16 +0200] - Listening on All Interfaces port 636 for LDAPS requests [20/Oct/2015:23:09:16 +0200] - Listening on /var/run/slapd-INTERNAL.socket for LDAPI requests I guess that's normal, since running the process through valgrind has a huge performance loss? The daemon crashed about ~ 25 seconds after it has opened it's ports. Here is the valgrind log: http://pastebin.com/8t9RtB6p Do you see any suspicious things? Many thanks for your help! - Dominik >> >> >> Kind regards, >> Dominik Korittki >> >>> >>> thanks >>> thierry >>>>> [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All >>>>> Interfaces port >>>>> 389 for LDAP requests >>>>> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 >>>>> for LDAPS >>>>> requests >>>>> [05/Oct/2015:13:51:30 +0200] - Listening on >>>>> /var/run/slapd-INTERNAL.socket for >>>>> LDAPI requests >>>>> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - >>>>> Error: could >>>>> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 >>>>> (Local >>>>> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS >>>>> failure. >>>>> Minor code may provide more information (No Kerberos credentials >>>>> available)) >>>>> errno 0 (Success) >>>>> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not >>>>> perform >>>>> interactive bind for id [] authentication mechanism [GSSAPI]: error >>>>> -2 (Local >>>>> error) >>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>>> GSSAPI auth >>>>> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>>> GSSAPI Error: >>>>> Unspecified GSS failure. Minor code may provide more information (No >>>>> Kerberos >>>>> credentials available)) >>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog >>>>> program - >>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN >>>>> 54bea480000000600000 not found, we aren't as up to date, or we purged >>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>>> Data required >>>>> to update replica has been purged. The replica must be reinitialized. >>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>>> Incremental >>>>> update failed and requires administrator action >>>>> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - >>>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>>> GSSAPI auth >>>>> resumed >>>>> >>>>> >>>>> These lines are present since a replayed a ldif dump from ipa02 to >>>>> ipa01, but i >>>>> didn't think that it related to the segfault problem (therefore i >>>>> said there >>>>> are no related problems in the logfile). >>>>> >>>>> But I am starting to believe that these errors could be in relation >>>>> to each other. >>>>> >>>>> >>>>> Kind regards, >>>>> Dominik Korittki >>>>> >>>>> >>>>>> >>>>>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates >>>>>>> to the >>>>>>> problem. >>>>> Not sure about that anymore. >>>>> >>>>>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does >>>>>>> that >>>>>>> solve my problems? >>>>>>> >>>>>>> FreeIPA server version is 3.3.3-28.el7.centos >>>>>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> Dominik Korittki >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >>> >> > > > > From lkrispen at redhat.com Wed Oct 21 15:03:25 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 21 Oct 2015 17:03:25 +0200 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <5627997A.4030907@mittwald.de> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5612696B.7050601@mittwald.de> <5614E389.4010001@redhat.com> <56151D5E.2040102@redhat.com> <56153451.2030308@mittwald.de> <56153A7F.1080103@redhat.com> <5627997A.4030907@mittwald.de> Message-ID: <5627A93D.7070703@redhat.com> On 10/21/2015 03:56 PM, Dominik Korittki wrote: > > > Am 07.10.2015 um 17:30 schrieb thierry bordaz: >> On 10/07/2015 05:03 PM, Dominik Korittki wrote: >>> >>> >>> Am 07.10.2015 um 15:25 schrieb thierry bordaz: >>>> On 10/07/2015 11:19 AM, Martin Kosek wrote: >>>>> On 10/05/2015 02:13 PM, Dominik Korittki wrote: >>>>>> >>>>>> Am 01.10.2015 um 21:52 schrieb Rob Crittenden: >>>>>>> Dominik Korittki wrote: >>>>>>>> Hello folks, >>>>>>>> >>>>>>>> I am running two FreeIPA Servers with around 100 users and around >>>>>>>> 15.000 >>>>>>>> hosts, which are used by users to login via ssh. The FreeIPA >>>>>>>> servers >>>>>>>> (which are Centos 7.0) ran good for a while, but as more and more >>>>>>>> hosts >>>>>>>> got migrated to serve as FreeIPA hosts, it started to get slow and >>>>>>>> unstable. >>>>>>>> >>>>>>>> For example, its hard to maintain hostgroups, which have more than >>>>>>>> 1.000 >>>>>>>> hosts. The ipa host-* commands are getting slower as the hostgroup >>>>>>>> grows. Is this normal? >>>>>>> You mean the ipa hostgroup-* commands? Whenever the entry is >>>>>>> displayed >>>>>>> (show and add) it needs to dereference all members so yes, it is >>>>>>> understandable that it gets somewhat slower with more members. How >>>>>>> slow >>>>>>> are we talking about? >>>>>>> >>>>>>>> We also experience random dirsrv segfaults. Here's a dmesg line >>>>>>>> from the >>>>>>>> latest: >>>>>>>> >>>>>>>> [690787.647261] traps: ns-slapd[5217] general protection >>>>>>>> ip:7f8d6b6d6bc1 >>>>>>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b650000+1b6000] >>>>>>> You probably want to start here: >>>>>>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes >>>>>> A stacktrace from the latest crash is attached to this email. After >>>>>> restarting >>>>>> the service, this is what I get in >>>>>> /var/log/dirsrv/slapd-INTERNAL/errors >>>>>> (hostname is ipa01.internal): >>>>> Ludwig or Thierry, can you please take a look at the stack and file >>>>> 389-DS >>>>> ticket if appropriate? >>>> >>>> Hello Dominik, >>>> >>>> DS is crashing during a BIND and from the arguments values we can >>>> guess >>>> it was due to a heap corruption that corrupted it operation pblock. >>>> This bind operation was likely victim of the heap corruption more than >>>> responsible of it. >>>> >>>> Using valgrind is the best way to track such problem but as you >>>> already >>>> suffer from bad performance I doubt it would be acceptable. >>>> How frequently does it crash ? did you identify a kind of test case ? >>> >>> At first the crashes happenend at a daily basis. Simply restarting the >>> dirsrv daemon resolved the issue for another day but later on the >>> daemon did not survive more than 15 minutes most of the time. There >>> were exceptions though. Sometimes the daemon ran for several hours >>> until it chrashed. >>> I did not really identify a testcase. However, I supposed it could >>> have something to do with replication, as I have seen replication >>> related errors in dirsrv error log (mentioned in an earlier mail in >>> this topic). >> heap corruption are usually dynamic and if the server became more and >> more slow, it could change the dynamic in favor of heap corruption. >>> >>> So did the following: >>> ipa01 has a replication agreement with ipa02. ipa01 was the one with >>> segfaults. I removed ipa01 from the replication agreement >>> (ipa-replica-manage del), did an ipa-server-install --uninstall on >>> ipa01 and created ipa01 as a replica of ipa02. Since then I did not >>> experience any crashes (for now). >>> Instead i'm having trouble rebuilding a clean replication agreement >>> (old RUV stuff still in database), but thats another story I will >>> eventually post on the mailinglist as a new topic. >>> >>> As for valgrind: Never used it before. Is there a handy explanation of >>> how to use it in combination with 389ds? If I still experience those >>> crashes and I get it managed to use I could try it out. >> You may follow this procedure >> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind >> >> (but remove --leak-check=yes because this is not a leak issue) >> >> thanks >> thierry > > I experienced segmentation faults again on host ipa01, even after I > rebuild the replication topology as described in previous mail. > I followed your advice and ran valgrind last evening. Sadly I forgot > to remove --leak-check=yes, but I hope the information is still useful > to you. If not, I'll do it again without --leak-check=yes. > > Running under valgrind, the ns-slapd process needed quiet some time > until it openened its ports. You can see this by watching the error logs: > > [20/Oct/2015:22:27:41 +0200] - 389-Directory/1.3.1.6 B2014.219.1825 > starting up > [20/Oct/2015:22:27:42 +0200] - WARNING: userRoot: entry cache size > 10485760B is less than db size 142483456B; We recommend to increase > the entry cache size nsslapd-cachememsize. > [20/Oct/2015:22:27:44 +0200] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=internal > [20/Oct/2015:23:09:16 +0200] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [20/Oct/2015:23:09:16 +0200] - Listening on All Interfaces port 636 > for LDAPS requests > [20/Oct/2015:23:09:16 +0200] - Listening on > /var/run/slapd-INTERNAL.socket for LDAPI requests > > I guess that's normal, since running the process through valgrind has > a huge performance loss? The daemon crashed about ~ 25 seconds after > it has opened it's ports. Here is the valgrind log: > http://pastebin.com/8t9RtB6p > > Do you see any suspicious things? It looks like it is accessing memory, which was freed in a pre-bind plugin, this could be the issue tracked in https://fedorahosted.org/389/ticket/48188 > Many thanks for your help! > > > - Dominik > >>> >>> >>> Kind regards, >>> Dominik Korittki >>> >>>> >>>> thanks >>>> thierry >>>>>> [05/Oct/2015:13:51:30 +0200] - slapd started. Listening on All >>>>>> Interfaces port >>>>>> 389 for LDAP requests >>>>>> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 >>>>>> for LDAPS >>>>>> requests >>>>>> [05/Oct/2015:13:51:30 +0200] - Listening on >>>>>> /var/run/slapd-INTERNAL.socket for >>>>>> LDAPI requests >>>>>> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - >>>>>> Error: could >>>>>> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 >>>>>> (Local >>>>>> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS >>>>>> failure. >>>>>> Minor code may provide more information (No Kerberos credentials >>>>>> available)) >>>>>> errno 0 (Success) >>>>>> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not >>>>>> perform >>>>>> interactive bind for id [] authentication mechanism [GSSAPI]: error >>>>>> -2 (Local >>>>>> error) >>>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>>>> GSSAPI auth >>>>>> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: >>>>>> GSSAPI Error: >>>>>> Unspecified GSS failure. Minor code may provide more information >>>>>> (No >>>>>> Kerberos >>>>>> credentials available)) >>>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog >>>>>> program - >>>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>>>> CSN >>>>>> 54bea480000000600000 not found, we aren't as up to date, or we >>>>>> purged >>>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>>>> Data required >>>>>> to update replica has been purged. The replica must be >>>>>> reinitialized. >>>>>> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - >>>>>> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): >>>>>> Incremental >>>>>> update failed and requires administrator action >>>>>> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin - >>>>>> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with >>>>>> GSSAPI auth >>>>>> resumed >>>>>> >>>>>> >>>>>> These lines are present since a replayed a ldif dump from ipa02 to >>>>>> ipa01, but i >>>>>> didn't think that it related to the segfault problem (therefore i >>>>>> said there >>>>>> are no related problems in the logfile). >>>>>> >>>>>> But I am starting to believe that these errors could be in relation >>>>>> to each other. >>>>>> >>>>>> >>>>>> Kind regards, >>>>>> Dominik Korittki >>>>>> >>>>>> >>>>>>> >>>>>>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates >>>>>>>> to the >>>>>>>> problem. >>>>>> Not sure about that anymore. >>>>>> >>>>>>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but >>>>>>>> does >>>>>>>> that >>>>>>>> solve my problems? >>>>>>>> >>>>>>>> FreeIPA server version is 3.3.3-28.el7.centos >>>>>>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Dominik Korittki >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >>>> >>> >> >> >> >> From APtashnik at cccis.com Wed Oct 21 21:11:44 2015 From: APtashnik at cccis.com (Andrey Ptashnik) Date: Wed, 21 Oct 2015 21:11:44 +0000 Subject: [Freeipa-users] Steps to rebuild a master node in IPA cluster Message-ID: <8EB36B14-D1BF-461A-9384-DAACD2409A79@cccis.com> Hello IPA Team, In one location we have IPA cluster based on CentOS 7.1 with IPA 4.1.0. One master and another replica. We noticed that Master node potentially has a corrupted database, some records cannot be deleted and IPA services crush one in a while. Second member (aka replica) is stable. We wanted to rebuild the Master node. What are the correct steps to move master functions to the replica, retire the old master and rebuild it? Regards, Andrey Ptashnik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlambert at letsevenup.com Wed Oct 21 20:43:04 2015 From: jlambert at letsevenup.com (Justin Lambert) Date: Wed, 21 Oct 2015 14:43:04 -0600 Subject: [Freeipa-users] Unable to enroll new client in DNS Message-ID: I have been trying to register a new node in my FreeIPA server and it isn?t adding DNS records. The host itself gets registered, but DNS updates during the ipa-client-install script fails. The servers and the client are both CentOS 7.1 running version 4.1.0-18. Below is the output showing the IPA server showing the host is registered, the zone allowing dynamic updates, and an attempted DNS update from the new host. I am able to get a host ticket which seems to validate that the host is properly registered. What am I missing or any other thoughts? Thanks jl >From the IPA server: $ ipa dnszone-show domain.com --all --rights dn: idnsname=domain.com.,cn=dns,dc=domain,dc=com Zone name: domain.com. Active zone: TRUE Authoritative nameserver: ipa1.domain.com. Administrator e-mail address: hostmaster.domain.com. SOA serial: 1445289950 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant DOMAIN.COM krb5-self * A; grant DOMAIN.COM krb5-self * AAAA; grant DOMAIN.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; Allow PTR sync: TRUE attributelevelrights: {u'sshfprecord': u'rscwo', u'cn': u'rscwo', u'kxrecord': u'rscwo', u'nsec3paramrecord': u'rscwo', u'idnsallowtransfer': u'rscwo', u'mxrecord': u'rscwo', u'idnsforwarders': u'rscwo', u'idnssoarefresh': u'rscwo', u'idnsallowsyncptr': u'rscwo', u'nsaccountlock': u'rscwo', u'idnsallowdynupdate': u'rscwo', u'mdrecord': u'rscwo', u'arecord': u'rscwo', u'dlvrecord': u'rscwo', u'idnsforwardpolicy': u'rscwo', u'ptrrecord': u'rscwo', u'idnssoaretry': u'rscwo', u'nxtrecord': u'rscwo', u'idnsupdatepolicy': u'rscwo', u'idnsallowquery': u'rscwo', u'idnsname': u'rscwo', u'afsdbrecord': u'rscwo', u'idnssoamname': u'rscwo', u'dnsttl': u'rscwo', u'idnszoneactive': u'rscwo', u'nsrecord': u'rscwo', u'locrecord': u'rscwo', u'sigrecord': u'rscwo', u'idnssoaminimum': u'rscwo', u'dnsclass': u'rscwo', u'aaaarecord': u'rscwo', u'rrsigrecord': u'rscwo', u'tlsarecord': u'rscwo', u'hinforecord': u'rscwo', u'idnssoaexpire': u'rscwo', u'idnssecinlinesigning': u'rscwo', u'cnamerecord': u'rscwo', u'dnamerecord': u'rscwo', u'objectclass': u'rscwo', u'aci': u'rscwo', u'certrecord': u'rscwo', u'srvrecord': u'rscwo', u'keyrecord': u'rscwo', u'idnssoaserial': u'rscwo', u'dsrecord': u'rscwo', u'txtrecord': u'rscwo', u'nsecrecord': u'rscwo', u'a6record': u'rscwo', u'naptrrecord': u'rscwo', u'idnssoarname': u'rscwo', u'minforecord': u'rscwo'} mxrecord: 10 mail1.domain.com., 10 mail02.domain.com. nsrecord: ipa1.domain.com., ipa2.domain.com. objectclass: idnszone, top, idnsrecord $ ipa host-show newhost Host name: newhost.domain.com Principal name: host/newhost.domain.com at DOMAIN.COM Password: False Member of host-groups: test Indirect Member of HBAC rule: test Keytab: True Managed by: newhost.domain.com SSH public key fingerprint: 35:31:77:48:F1:59:48:03:9F:63:80:D5:3B:3C:03:7F (ssh-rsa), BE:3B:A5:CB:00:11:76:DD:C4:B7:D8:C4:87:3F:CA:1E (ecdsa-sha2-nistp256), D2:29:FE:7D:22:6A:8C:DF:E7:AA:D4:F8:07:65:6D:4B (ssh-ed25519) ---------------------------------------------------------------------------------------- On the new client: $ cat dns_update.txt debug zone domain.com. update delete newhost.domain.com. IN A show send update add newhost.domain.com. 1200 IN A 172.123.123.123 show send $ /usr/bin/kinit -k -t /etc/krb5.keytab host/`hostname`@DOMAIN.COM $ nsupdate -g /etc/ipa/dns_update.txt Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; ZONE SECTION: ;domain.com. IN SOA ;; UPDATE SECTION: newhost.domain.com. 0 ANY A Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269 ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;domain.com. IN SOA ;; ANSWER SECTION: domain.com. 86400 IN SOA ipa1.domain.com. hostmaster.domain.com. 1445289950 3600 900 1209600 3600 ;; AUTHORITY SECTION: domain.com. 86400 IN NS ipa1.domain.com. domain.com. 86400 IN NS ipa2.domain.com. ;; ADDITIONAL SECTION: ipa1.domain.com. 1200 IN A 172.123.123.120 ipa2.domain.com. 1200 IN A 172.123.123.121 Found zone name: domain.com The master is: ipa1.domain.com start_gssrequest Found realm from ticket: DOMAIN.COM send_gssrequest Outgoing update query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16484 ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;2667812275.sig-ipa1.domain.com. ANY TKEY ;; ADDITIONAL SECTION: 2667812275.sig-ipa1.domain.com. 0 ANY TKEY gss-tsig. 1445445558 1445445558 3 NOERROR 631 YIICcwYJKoZIhvcSAQICAQBuggJiMIICXqADAgEFoQMCAQ6iBwMFACAA AACjggFmYYIBYjCCAV6gAwIBBaEJGwdJTkVVLlVToiQwIqADAgEBoRsw GRsDRE5TGxJ1ZTFhLWlwYTAxLmluZXUudXOjggEkMIIBIKADAgESoQMC AQKiggESBIIBDlqpCYbm7lCR05AcWuviLHSrYDD6LEwfhILsssYZAu/m pBLrA8UK7JGBEu7MjkSrUHQnvAZF1uY0Ts9B8WXFAQtSoutV0YX95Syy vWV8WuQqXdblmJrUHBewC9PsDfBMEMMFLRNnpw8XFnKVPg81m3UGo6RA jdKOExJWOu5kY5+8oK4s0ZVNXolOs39poK70hDs8lrCrGPZwzAO0GnAt yEejzh4ajyh8n2wLPdRVWkFP0pLZDv5KvTPy+Vm8FHjLZm0evLa7lZhu lrjq5KU2kaLfuQwTCJQIfVnXwDm/+jzVstHQVmzKjgJyY3xm7FFdrmv9 160uh6qxpzlux3Te5Tnil0J3yK7FTtt61q8Pq6SB3jCB26ADAgESooHT BIHQKjcpMj4qJ8bK157Oqv7iOBsIUQ2pPCKfDYqvFlmC0u8LreIoEmFf SzABdQzsY09mQUoXB7CWoX8DSkwMBfQ13YsPIOdcjTxNRLAOeMxOLVE8 zxQV0RTbBRj9cgrF1fs68w2QmdIQuUAZ1YyCsWfG4nqSbrkr3agg1Wdz PIoo5CO7npU4tVgAN7a5zvrSBHVdTp5zrxe3KFDw0cEkFJ6Jf1XtNUt0 UuSQRFi7NQBmrBgoCnxEkmBzwBogQ4cxjGj14xvzjJxNe7vISylb32t6 GQ== 0 recvmsg reply from GSS-TSIG query ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16484 ;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;2667812275.sig-ipa1.domain.com. ANY TKEY ;; ANSWER SECTION: 2667812275.sig-ipa1.domain.com. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0 0 dns_tkey_negotiategss: TKEY is unacceptable -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.zoske at euroimmun.de Thu Oct 22 06:14:01 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Thu, 22 Oct 2015 06:14:01 +0000 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151019085150.GB27762@mail.corp.redhat.com> References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> <20151019085150.GB27762@mail.corp.redhat.com> Message-ID: Hi Lukas, Thank you. These packages fixed the issue. Best regards, Fabian -----Urspr?ngliche Nachricht----- Von: Lukas Slebodnik [mailto:lslebodn at redhat.com] Gesendet: Montag, 19. Oktober 2015 10:52 An: Zoske, Fabian Cc: freeipa-users at redhat.com Betreff: Re: [Freeipa-users] SUDO does not always works on first try On (19/10/15 08:39), Zoske, Fabian wrote: >Hi Jakub, > >I think there is a package missing. >When I try to install the packages you provided, yum exits with an error. >" Requires: python-sssdconfig = 1.12.2-58.el7_1.18 " > python-sssdconfig is noarch package which is missing in https://jhrozek.fedorapeople.org/sssd-test-builds/ I hope Jakub will upload it. >Can you provide me this package or tell me where to find it? > Alternatively, you can test backported version from fedora 21. It is the latest 1.12 release + few bugfixes. https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/ LS From pspacek at redhat.com Thu Oct 22 07:24:09 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 09:24:09 +0200 Subject: [Freeipa-users] Unable to enroll new client in DNS In-Reply-To: References: Message-ID: <56288F19.6080908@redhat.com> On 21.10.2015 22:43, Justin Lambert wrote: > ;; ANSWER SECTION: > 2667812275.sig-ipa1.domain.com. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0 0 > > dns_tkey_negotiategss: TKEY is unacceptable Please consult named logs on server ipa1.domain.com and see if there are any errors related to dynamic update. Speaking about GSS-TSIG, one of problems can be clock skew between DNS server and client. Also, please add information about package versions: $ rpm -q bind bind-dyndb-ldap Thank you. -- Petr^2 Spacek From jhrozek at redhat.com Thu Oct 22 09:33:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 22 Oct 2015 11:33:46 +0200 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> <20151019085150.GB27762@mail.corp.redhat.com> Message-ID: <20151022093346.GD26101@hendrix.redhat.com> On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote: > Hi Lukas, > > Thank you. These packages fixed the issue. Thank you very much for the testing and reporting back! From mkosek at redhat.com Thu Oct 22 11:12:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Oct 2015 13:12:30 +0200 Subject: [Freeipa-users] Steps to rebuild a master node in IPA cluster In-Reply-To: <8EB36B14-D1BF-461A-9384-DAACD2409A79@cccis.com> References: <8EB36B14-D1BF-461A-9384-DAACD2409A79@cccis.com> Message-ID: <5628C49E.7070904@redhat.com> On 10/21/2015 11:11 PM, Andrey Ptashnik wrote: > Hello IPA Team, > > In one location we have IPA cluster based on CentOS 7.1 with IPA 4.1.0. One master and another replica. We noticed that Master node potentially has a corrupted database, some records cannot be deleted and IPA services crush one in a while. Second member (aka replica) is stable. We wanted to rebuild the Master node. > > What are the correct steps to move master functions to the replica, retire the old master and rebuild it? > > Regards, > > Andrey Ptashnik Would http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master help? From jlambert at letsevenup.com Thu Oct 22 12:23:04 2015 From: jlambert at letsevenup.com (Justin Lambert) Date: Thu, 22 Oct 2015 06:23:04 -0600 Subject: [Freeipa-users] Unable to enroll new client in DNS In-Reply-To: <56288F19.6080908@redhat.com> References: <56288F19.6080908@redhat.com> Message-ID: When I looked at the DNS logs there was nothing of any value (with a fresh attempt of registering DNS records) so I added a logging channel for ldap at severity 9. After restarting bind the DNS registration worked without issue. Removing the logging channel and re-running the update worked. It appears that restarting bind fixed the issue, which is a bit scary. I?m running bind-dyndb-ldap-6.0.2. Do you know if anyone has seen this issue before? On Thu, Oct 22, 2015 at 1:24 AM, Petr Spacek wrote: > On 21.10.2015 22:43, Justin Lambert wrote: > > ;; ANSWER SECTION: > > 2667812275.sig-ipa1.domain.com. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0 0 > > > > dns_tkey_negotiategss: TKEY is unacceptable > > Please consult named logs on server ipa1.domain.com and see if there are > any > errors related to dynamic update. > > Speaking about GSS-TSIG, one of problems can be clock skew between DNS > server > and client. > > Also, please add information about package versions: > $ rpm -q bind bind-dyndb-ldap > > Thank you. > > -- > Petr^2 Spacek > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Oct 22 14:08:01 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Oct 2015 16:08:01 +0200 Subject: [Freeipa-users] Unable to enroll new client in DNS In-Reply-To: References: <56288F19.6080908@redhat.com> Message-ID: <5628EDC1.8050100@redhat.com> On 22.10.2015 14:23, Justin Lambert wrote: > When I looked at the DNS logs there was nothing of any value (with a fresh > attempt of registering DNS records) so I added a logging channel for ldap > at severity 9. After restarting bind the DNS registration worked without > issue. Removing the logging channel and re-running the update worked. It > appears that restarting bind fixed the issue, which is a bit scary. I?m > running bind-dyndb-ldap-6.0.2. Do you know if anyone has seen this issue > before? No, I did not hear about this particular issue. Please let me know if it happens again. Have a nice day! Petr^2 Spacek > > On Thu, Oct 22, 2015 at 1:24 AM, Petr Spacek wrote: > >> On 21.10.2015 22:43, Justin Lambert wrote: >>> ;; ANSWER SECTION: >>> 2667812275.sig-ipa1.domain.com. 0 ANY TKEY gss-tsig. 0 0 3 BADKEY 0 0 >>> >>> dns_tkey_negotiategss: TKEY is unacceptable >> >> Please consult named logs on server ipa1.domain.com and see if there are >> any >> errors related to dynamic update. >> >> Speaking about GSS-TSIG, one of problems can be clock skew between DNS >> server >> and client. >> >> Also, please add information about package versions: >> $ rpm -q bind bind-dyndb-ldap >> >> Thank you. >> >> -- >> Petr^2 Spacek From janellenicole80 at gmail.com Thu Oct 22 15:44:12 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 22 Oct 2015 08:44:12 -0700 Subject: [Freeipa-users] clean-ruv : How Long? Message-ID: <5629044C.6000303@gmail.com> Hello, I was wondering if there is any average or expectation of how long a "clean-ruv" task should take across 16 fairly busy servers? Thank you ~J From mareynol at redhat.com Thu Oct 22 19:12:05 2015 From: mareynol at redhat.com (Mark Reynolds) Date: Thu, 22 Oct 2015 15:12:05 -0400 Subject: [Freeipa-users] clean-ruv : How Long? In-Reply-To: <5629044C.6000303@gmail.com> References: <5629044C.6000303@gmail.com> Message-ID: <56293505.7080405@redhat.com> Hi Janelle, It's really hard to say how long it might take. I know if the replicas are under heavy replication load it can take while to complete. Either way it should not take long to complete(a few hours max) - as long as all the replicas are online. There is very good logging for cleanAllRUV in the Directory Server's errors log. If the task is hung up somewhere it should say what replica(repl agreement) is causing the task to not progress. Then from there you can look at that replica to see whats going on that system. You might have to chase down each replica until you find that one that is acting up. Typically when cleanallruv is not finishing it's because a replica is down(shutdown), or there is an old repl agreement that points to replica that no longer exists. Here is a troubleshooting page that might also be useful: http://www.port389.org/docs/389ds/FAQ/troubleshoot-cleanallruv.html Mark On 10/22/2015 11:44 AM, Janelle wrote: > Hello, > > I was wondering if there is any average or expectation of how long a > "clean-ruv" task should take across 16 fairly busy servers? > > Thank you > ~J > From randym at chem.byu.edu Fri Oct 23 18:51:41 2015 From: randym at chem.byu.edu (Randolph Morgan) Date: Fri, 23 Oct 2015 12:51:41 -0600 Subject: [Freeipa-users] FreeIPA, Windows and Kerberos Message-ID: <562A81BD.4000100@chem.byu.edu> We are running a mixed environment network. However, all of our authentication is performed via LDAP, we do not have an AD on our network, nor do we have any Windows servers, all of our servers are running RHEL. We are working on implementing a new authentication server that is running FreeIPA, but would like to do single sign-on via Kerberos. I have been reading posts for the better part of two weeks and can not find instructions that work, on how to get Windows (XP - 10) to authenticate via Kerberos. Here is a list of some of the sites that I have looked at: https://support.microsoft.com/en-us/kb/837361 https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 http://www.freeipa.org/page/Windows_authentication_against_FreeIPA https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html (This is an older post but I was getting desperate) http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step So here is the problem, when I attempt to set the Realm on the Windows client I receive the following error: C:\Users\randym>ksetup /setrealm CHEM.BYU.EDU Setting Dns Domain Failed to set dns domain info: 0xc0000022 Failed /SetRealm : 0xc0000022 I have tried several varieties of this command, including setting the domain instead of the realm and always get the same result. Can someone please put together a step by step process that includes both server side and client side for configuring Kerberos to work with Windows and FreeIPA. Thank You in advance, Randy -- Randy Morgan CSR Department of Chemistry and Biochemistry Brigham Young University 801-422-4100 From abokovoy at redhat.com Fri Oct 23 20:31:03 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 Oct 2015 23:31:03 +0300 Subject: [Freeipa-users] FreeIPA, Windows and Kerberos In-Reply-To: <562A81BD.4000100@chem.byu.edu> References: <562A81BD.4000100@chem.byu.edu> Message-ID: <20151023203103.GB6367@redhat.com> On Fri, 23 Oct 2015, Randolph Morgan wrote: >We are running a mixed environment network. However, all of our >authentication is performed via LDAP, we do not have an AD on our >network, nor do we have any Windows servers, all of our servers are >running RHEL. We are working on implementing a new authentication >server that is running FreeIPA, but would like to do single sign-on >via Kerberos. I have been reading posts for the better part of two >weeks and can not find instructions that work, on how to get Windows >(XP - 10) to authenticate via Kerberos. Here is a list of some of the >sites that I have looked at: > >https://support.microsoft.com/en-us/kb/837361 >https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html >https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 These are irrelevant for the configuration of FreeIPA with machines post Windows 7. >http://www.freeipa.org/page/Windows_authentication_against_FreeIPA This document still stands. Namely, we do not support joining Windows machines to FreeIPA domain. -- / Alexander Bokovoy From mrorourke at earthlink.net Fri Oct 23 23:58:56 2015 From: mrorourke at earthlink.net (Michael ORourke) Date: Fri, 23 Oct 2015 19:58:56 -0400 Subject: [Freeipa-users] FreeIPA, Windows and Kerberos In-Reply-To: <562A81BD.4000100@chem.byu.edu> References: <562A81BD.4000100@chem.byu.edu> Message-ID: <562AC9C0.6080501@earthlink.net> What about the pGina project? I haven't tried this personally, but it sounds like it might be something that could work with FreeIPA (using the LDAP plugin). Reference: http://pgina.org/ And this article looks helpful: http://www.freeipa.org/page/Windows_authentication_against_FreeIPA Or perhaps doing something with Samba and FreeIPA. What exactly are you trying to do? When you say, "single sign-on via kerberos", do you have some Linux servers that you want to access from different versions of Windows and you want to be able to authenticate without typing in a password every time (e.g. using PuTTY)? -Mike On 10/23/2015 2:51 PM, Randolph Morgan wrote: > We are running a mixed environment network. However, all of our > authentication is performed via LDAP, we do not have an AD on our > network, nor do we have any Windows servers, all of our servers are > running RHEL. We are working on implementing a new authentication > server that is running FreeIPA, but would like to do single sign-on > via Kerberos. I have been reading posts for the better part of two > weeks and can not find instructions that work, on how to get Windows > (XP - 10) to authenticate via Kerberos. Here is a list of some of the > sites that I have looked at: > > https://support.microsoft.com/en-us/kb/837361 > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 > > http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html > (This is an older post but I was getting desperate) > http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step > > > So here is the problem, when I attempt to set the Realm on the Windows > client I receive the following error: > > C:\Users\randym>ksetup /setrealm CHEM.BYU.EDU > Setting Dns Domain > Failed to set dns domain info: 0xc0000022 > Failed /SetRealm : 0xc0000022 > > I have tried several varieties of this command, including setting the > domain instead of the realm and always get the same result. Can > someone please put together a step by step process that includes both > server side and client side for configuring Kerberos to work with > Windows and FreeIPA. > > Thank You in advance, > > Randy > From prasun.gera at gmail.com Sat Oct 24 03:57:06 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 23 Oct 2015 20:57:06 -0700 Subject: [Freeipa-users] enabling selinux on ipa server Message-ID: selinux was disabled for some reason when the ipa server(replica) was installed. I enabled it, and see that there are a lot of selinux related permissions problems in syslog. Is this a known issue ? I tried fixing some of them manually, but i would like a better approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Sat Oct 24 07:16:18 2015 From: fujisan43 at gmail.com (Fujisan) Date: Sat, 24 Oct 2015 09:16:18 +0200 Subject: [Freeipa-users] FreeIPA, Windows and Kerberos In-Reply-To: <562A81BD.4000100@chem.byu.edu> References: <562A81BD.4000100@chem.byu.edu> Message-ID: Have you tried with /setdomain? ksetup /setdomain CHEM.BYU.EDU I've done like this on windows 8.1 and windows 10. I had trouble doing it on one windows 7 desktop so I upgraded to windows 10. ?These are the only steps I did to authenticate a windows desktop via kerberos, nothing more:? 1. ksetup /setdomain [REALM NAME] 2. ksetup /addkdc [REALM NAME] [kdc DNS name] 3. ksetup /addkpasswd [REALM NAME] [kdc DNS name] 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) 5. ksetup /mapuser * * On Fri, Oct 23, 2015 at 8:51 PM, Randolph Morgan wrote: > We are running a mixed environment network. However, all of our > authentication is performed via LDAP, we do not have an AD on our network, > nor do we have any Windows servers, all of our servers are running RHEL. > We are working on implementing a new authentication server that is running > FreeIPA, but would like to do single sign-on via Kerberos. I have been > reading posts for the better part of two weeks and can not find > instructions that work, on how to get Windows (XP - 10) to authenticate via > Kerberos. Here is a list of some of the sites that I have looked at: > > https://support.microsoft.com/en-us/kb/837361 > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html > > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 > http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Using_Microsoft_Windows.html > (This is an older post but I was getting desperate) > > http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step > > So here is the problem, when I attempt to set the Realm on the Windows > client I receive the following error: > > C:\Users\randym>ksetup /setrealm CHEM.BYU.EDU > Setting Dns Domain > Failed to set dns domain info: 0xc0000022 > Failed /SetRealm : 0xc0000022 > > I have tried several varieties of this command, including setting the > domain instead of the realm and always get the same result. Can someone > please put together a step by step process that includes both server side > and client side for configuring Kerberos to work with Windows and FreeIPA. > > Thank You in advance, > > Randy > > -- > Randy Morgan > CSR > Department of Chemistry and Biochemistry > Brigham Young University > 801-422-4100 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Oct 24 17:51:47 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 24 Oct 2015 19:51:47 +0200 Subject: [Freeipa-users] enabling selinux on ipa server In-Reply-To: References: Message-ID: <20151024175147.GA25690@mail.corp.redhat.com> On (23/10/15 20:57), Prasun Gera wrote: >selinux was disabled for some reason when the ipa server(replica) was >installed. I enabled it, and see that there are a lot of selinux related >permissions problems in syslog. Is this a known issue ? I tried fixing some >of them manually, but i would like a better approach. FreeIPA should work fine with SELinux in enforcing mode. I would recommend to restore SELinux context of files on that machine. restorecon -Rv / LS From prasun.gera at gmail.com Sat Oct 24 23:32:13 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sat, 24 Oct 2015 16:32:13 -0700 Subject: [Freeipa-users] enabling selinux on ipa server In-Reply-To: <20151024175147.GA25690@mail.corp.redhat.com> References: <20151024175147.GA25690@mail.corp.redhat.com> Message-ID: I've done that now in addition to the few fixes that I made manually earlier. These were the messages: SELinux is preventing /usr/sbin/ns-slapd from write access on the file ldap_988 SELinux is preventing /usr/sbin/httpd from read access on the lnk_file /etc/httpd/logs And a few others. I also had to do sudo setsebool -P httpd_manage_ipa 1 On Sat, Oct 24, 2015 at 10:51 AM, Lukas Slebodnik wrote: > On (23/10/15 20:57), Prasun Gera wrote: > >selinux was disabled for some reason when the ipa server(replica) was > >installed. I enabled it, and see that there are a lot of selinux related > >permissions problems in syslog. Is this a known issue ? I tried fixing > some > >of them manually, but i would like a better approach. > FreeIPA should work fine with SELinux in enforcing mode. > > I would recommend to restore SELinux context of files on that machine. > > restorecon -Rv / > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sun Oct 25 04:13:27 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 25 Oct 2015 00:13:27 -0400 Subject: [Freeipa-users] enabling selinux on ipa server In-Reply-To: References: <20151024175147.GA25690@mail.corp.redhat.com> Message-ID: <562C56E7.6030608@redhat.com> Prasun Gera wrote: > I've done that now in addition to the few fixes that I made manually > earlier. These were the messages: > SELinux is preventing /usr/sbin/ns-slapd from write access on the file > ldap_988 > SELinux is preventing /usr/sbin/httpd from read access on the lnk_file > /etc/httpd/logs > And a few others. I also had to do sudo setsebool -P httpd_manage_ipa 1 It would help to know what version you're using. The installer will skip setting the booleans if SELinux disabled. The installer won't disable SELinux itself. A default install will enable these booleans: httpd_can_network_connect httpd_manage_ipa httpd_run_ipa AD trust will enable samba_portmapper rob > > On Sat, Oct 24, 2015 at 10:51 AM, Lukas Slebodnik > wrote: > > On (23/10/15 20:57), Prasun Gera wrote: > >selinux was disabled for some reason when the ipa server(replica) was > >installed. I enabled it, and see that there are a lot of selinux > related > >permissions problems in syslog. Is this a known issue ? I tried > fixing some > >of them manually, but i would like a better approach. > FreeIPA should work fine with SELinux in enforcing mode. > > I would recommend to restore SELinux context of files on that machine. > > restorecon -Rv / > > LS > > > > From prasun.gera at gmail.com Sun Oct 25 08:31:12 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 25 Oct 2015 01:31:12 -0700 Subject: [Freeipa-users] enabling selinux on ipa server In-Reply-To: <562C56E7.6030608@redhat.com> References: <20151024175147.GA25690@mail.corp.redhat.com> <562C56E7.6030608@redhat.com> Message-ID: I'm using the default version on RHEL7. I think that's 4.1.x. This was a replica server. Selinux was disabled when the replica was installed. I enabled in in enforcing mode yesterday, and saw those issues. On the main server, selinux is (and has always been) enabled in enforcing mode, and everything works fine. I also compared the bools between the main server and the replica, and the bools on the main server were correctly setup, whereas the ones you mentioned weren't set up properly on the replica. So from the limited information I have at hand, I think that setting up a replica server in the selinux disabled state didn't set up the selinux related stuff properly, which manifested later when i set it to enforcing mode. On Sat, Oct 24, 2015 at 9:13 PM, Rob Crittenden wrote: > Prasun Gera wrote: > > I've done that now in addition to the few fixes that I made manually > > earlier. These were the messages: > > SELinux is preventing /usr/sbin/ns-slapd from write access on the file > > ldap_988 > > SELinux is preventing /usr/sbin/httpd from read access on the lnk_file > > /etc/httpd/logs > > And a few others. I also had to do sudo setsebool -P httpd_manage_ipa 1 > > It would help to know what version you're using. > > The installer will skip setting the booleans if SELinux disabled. The > installer won't disable SELinux itself. > > A default install will enable these booleans: > > httpd_can_network_connect > httpd_manage_ipa > httpd_run_ipa > > AD trust will enable samba_portmapper > > rob > > > > > On Sat, Oct 24, 2015 at 10:51 AM, Lukas Slebodnik > > wrote: > > > > On (23/10/15 20:57), Prasun Gera wrote: > > >selinux was disabled for some reason when the ipa server(replica) > was > > >installed. I enabled it, and see that there are a lot of selinux > > related > > >permissions problems in syslog. Is this a known issue ? I tried > > fixing some > > >of them manually, but i would like a better approach. > > FreeIPA should work fine with SELinux in enforcing mode. > > > > I would recommend to restore SELinux context of files on that > machine. > > > > restorecon -Rv / > > > > LS > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Oct 26 08:36:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 26 Oct 2015 09:36:33 +0100 Subject: [Freeipa-users] FreeIPA, Windows and Kerberos In-Reply-To: <20151023203103.GB6367@redhat.com> References: <562A81BD.4000100@chem.byu.edu> <20151023203103.GB6367@redhat.com> Message-ID: <562DE611.3000001@redhat.com> On 23.10.2015 22:31, Alexander Bokovoy wrote: > On Fri, 23 Oct 2015, Randolph Morgan wrote: >> We are running a mixed environment network. However, all of our >> authentication is performed via LDAP, we do not have an AD on our network, >> nor do we have any Windows servers, all of our servers are running RHEL. We >> are working on implementing a new authentication server that is running >> FreeIPA, but would like to do single sign-on via Kerberos. I have been >> reading posts for the better part of two weeks and can not find instructions >> that work, on how to get Windows (XP - 10) to authenticate via Kerberos. >> Here is a list of some of the sites that I have looked at: >> >> https://support.microsoft.com/en-us/kb/837361 >> https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html >> https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#id2573486 >> > These are irrelevant for the configuration of FreeIPA with machines post > Windows 7. > >> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > This document still stands. Namely, we do not support joining Windows > machines to FreeIPA domain. In other words, you really need an AD or Samba 4 server (with cross-forest trust support, if it was released already ...) to get proper integration between FreeIPA and Windows world. The main limitation is that FreeIPA currently lacks support for Global Catalog so you will not be able to log-in into Windows workstations using credentials from FreeIPA. It will work the other way around. I hope this helps. -- Petr^2 Spacek From f.zoske at euroimmun.de Mon Oct 26 12:34:21 2015 From: f.zoske at euroimmun.de (Zoske, Fabian) Date: Mon, 26 Oct 2015 12:34:21 +0000 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: <20151022093346.GD26101@hendrix.redhat.com> References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> <20151019085150.GB27762@mail.corp.redhat.com> <20151022093346.GD26101@hendrix.redhat.com> Message-ID: Hi folks, Unfortunately the fix doesn't work as expected. On the first hosts I tried, there was no sign of the problem anymore, but when a colleage tried the hosts the problem occurs again. And we discovered another side effect: new enrolled IPA clients are not able to communicate with the AD-DCs after the update of SSSD von IPA-DC. Do you need any logs? Best regards, Fabian -----Urspr?ngliche Nachricht----- Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Jakub Hrozek Gesendet: Donnerstag, 22. Oktober 2015 11:34 An: freeipa-users at redhat.com Betreff: Re: [Freeipa-users] SUDO does not always works on first try On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote: > Hi Lukas, > > Thank you. These packages fixed the issue. Thank you very much for the testing and reporting back! -- 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 From jhrozek at redhat.com Mon Oct 26 13:23:48 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 26 Oct 2015 14:23:48 +0100 Subject: [Freeipa-users] SUDO does not always works on first try In-Reply-To: References: <20151007080241.GP3048@hendrix> <20151012094711.GU8948@hendrix> <20151016083214.GJ14465@hendrix.arn.redhat.com> <20151019085150.GB27762@mail.corp.redhat.com> <20151022093346.GD26101@hendrix.redhat.com> Message-ID: <20151026132348.GA3530@hendrix.arn.redhat.com> On Mon, Oct 26, 2015 at 12:34:21PM +0000, Zoske, Fabian wrote: > Hi folks, > > Unfortunately the fix doesn't work as expected. On the first hosts I tried, there was no sign of the problem anymore, but when a colleage tried the hosts the problem occurs again. > And we discovered another side effect: new enrolled IPA clients are not able to communicate with the AD-DCs after the update of SSSD von IPA-DC. > > Do you need any logs? Yes, from both server and client. > > Best regards, > Fabian > > > -----Urspr?ngliche Nachricht----- > Von: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] Im Auftrag von Jakub Hrozek > Gesendet: Donnerstag, 22. Oktober 2015 11:34 > An: freeipa-users at redhat.com > Betreff: Re: [Freeipa-users] SUDO does not always works on first try > > On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote: > > Hi Lukas, > > > > Thank you. These packages fixed the issue. > > Thank you very much for the testing and reporting back! > > -- > 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 From james.masson at jmips.co.uk Mon Oct 26 15:05:18 2015 From: james.masson at jmips.co.uk (James Masson) Date: Mon, 26 Oct 2015 15:05:18 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <56254D39.3000303@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> Message-ID: <562E412E.6030504@jmips.co.uk> On 19/10/15 21:06, Rob Crittenden wrote: > James Masson wrote: >> >> Hi list, >> >> I successfully have IPA working with CA certs signed by an upstream Dogtag. >> >> Now I'm trying to use a CA cert signed by a different type of CA - Vault. >> >> Setup fails, using the same 2 step IPA setup process as used with >> upstream Dogtag. I've also tried the external-ca-type option. >> >> Likely, IPA doesn't like the certificate - however, I can't pinpoint why. > > I'm guessing you don't include the entire CA certchain of Vault. Dogtag > is failing to startup because it can't verify its own cert chain: > > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > CAPresence: CA is present > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > SystemCertsVerification: system certs verification failure > 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] > SelfTestSubsystem: The CRITICAL self test plugin called > selftests.container.instance.SystemCertsVerification running at startup > FAILED! > > rob > Hi Rob, Thanks for the reply. I do present the IPA installer with both the CA and the IPA cert - the IPAs python-based install code is happy with the cert chain, but the Java based dogtag code chokes on it. OpenSSL is happy with it too. ##### [root at foo ~]# openssl verify ipa.crt ipa.crt: O = LOCAL, CN = Certificate Authority error 20 at 0 depth lookup:unable to get local issuer certificate [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt ipa.crt: OK ### Any hints on how to reproduce this with more debug output? I'd like to know exactly what Dogtag doesn't like about the certificate. thanks James M From mkosek at redhat.com Mon Oct 26 16:11:06 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Oct 2015 17:11:06 +0100 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <562E412E.6030504@jmips.co.uk> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> Message-ID: <562E509A.8030506@redhat.com> On 10/26/2015 04:05 PM, James Masson wrote: > > > On 19/10/15 21:06, Rob Crittenden wrote: >> James Masson wrote: >>> >>> Hi list, >>> >>> I successfully have IPA working with CA certs signed by an upstream Dogtag. >>> >>> Now I'm trying to use a CA cert signed by a different type of CA - Vault. >>> >>> Setup fails, using the same 2 step IPA setup process as used with >>> upstream Dogtag. I've also tried the external-ca-type option. >>> >>> Likely, IPA doesn't like the certificate - however, I can't pinpoint why. >> >> I'm guessing you don't include the entire CA certchain of Vault. Dogtag >> is failing to startup because it can't verify its own cert chain: >> >> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >> CAPresence: CA is present >> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >> SystemCertsVerification: system certs verification failure >> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >> SelfTestSubsystem: The CRITICAL self test plugin called >> selftests.container.instance.SystemCertsVerification running at startup >> FAILED! >> >> rob >> > > > Hi Rob, > > Thanks for the reply. > > I do present the IPA installer with both the CA and the IPA cert - the IPAs > python-based install code is happy with the cert chain, but the Java based > dogtag code chokes on it. > > OpenSSL is happy with it too. > > ##### > [root at foo ~]# openssl verify ipa.crt > ipa.crt: O = LOCAL, CN = Certificate Authority > error 20 at 0 depth lookup:unable to get local issuer certificate > > [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt > ipa.crt: OK > ### > > Any hints on how to reproduce this with more debug output? I'd like to know > exactly what Dogtag doesn't like about the certificate. > > thanks > > James M Let me CC at least Jan Ch. and David, they may be able to help and should also make sure FreeIPA gets better in validating the certs, as appropriate. From jduino at oblong.com Mon Oct 26 16:41:47 2015 From: jduino at oblong.com (John Duino) Date: Mon, 26 Oct 2015 11:41:47 -0500 (CDT) Subject: [Freeipa-users] How grant access to userPassword for System Accounts Message-ID: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> I am trying to hook our VoIP solution (sipxecs-based openUC) to our FreeIPA. But it appears that it wants to read-in the userPassword rather than just auth against the ldap. I know Directory Manager is the only account that has the ability to read userPassword, but is there a way to grant that to a System Account (uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some other path/process I'm overlooking short of using the Directory Manager account? Thanks! John From gparente at redhat.com Mon Oct 26 17:05:21 2015 From: gparente at redhat.com (German Parente) Date: Mon, 26 Oct 2015 13:05:21 -0400 (EDT) Subject: [Freeipa-users] How grant access to userPassword for System Accounts In-Reply-To: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> References: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> Message-ID: <1902672719.45450360.1445879121127.JavaMail.zimbra@redhat.com> Hi John you could add a particular ACI to allow any groupdn or userdn to read/search userPassword under the required tree. Something like: aci: (targetattr = "userPassword") (target = "ldap:///cn=users,cn=accounts,dc=,dc=") (version 3.0;acl "Allow password read";allow (read,compare,search)(groupdn = "ldap:///");) Regards, German. ----- Original Message ----- > From: "John Duino" > To: "freeipa-users" > Sent: Monday, October 26, 2015 5:41:47 PM > Subject: [Freeipa-users] How grant access to userPassword for System Accounts > > I am trying to hook our VoIP solution (sipxecs-based openUC) to our FreeIPA. > But it appears that it wants to read-in the userPassword rather than just > auth against the ldap. > I know Directory Manager is the only account that has the ability to read > userPassword, but is there a way to grant that to a System Account > (uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some other > path/process I'm overlooking short of using the Directory Manager account? > > Thanks! > > John > > -- > 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 > From janellenicole80 at gmail.com Mon Oct 26 17:24:06 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 26 Oct 2015 10:24:06 -0700 Subject: [Freeipa-users] OTP vs password? Message-ID: <562E61B6.3000405@gmail.com> Hello all... Seeing something very strange. With OTP enabled for all users - here is the configuration: Some hosts fully "enrolled" with IPA, and some are simply configured with authconfig to use LDAP backend for authentication. RANDOMLY <---- Keyword here -- all systems use SSSD regardless of the authentication method. A user will be able to login with password+token, but the random part - sometimes JUST the password. Is this possible due to some odd caching issues with SSSD perhaps or ??? How might I research this? is there anything to look for in configs or logs? thank you ~J From jhrozek at redhat.com Mon Oct 26 18:39:40 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 26 Oct 2015 19:39:40 +0100 Subject: [Freeipa-users] OTP vs password? In-Reply-To: <562E61B6.3000405@gmail.com> References: <562E61B6.3000405@gmail.com> Message-ID: <20151026183940.GB3124@hendrix> On Mon, Oct 26, 2015 at 10:24:06AM -0700, Janelle wrote: > Hello all... > > Seeing something very strange. With OTP enabled for all users - here is the > configuration: > > Some hosts fully "enrolled" with IPA, and some are simply configured with > authconfig to use LDAP backend for authentication. > > RANDOMLY <---- Keyword here -- all systems use SSSD regardless of the > authentication method. A user will be able to login with password+token, but > the random part - sometimes JUST the password. Is this possible due to some > odd caching issues with SSSD perhaps or ??? How might I research this? is > there anything to look for in configs or logs? I would assume that when just the password suffices, the client would be offline (because when offline, we can only compare the first factor). You can verify this with running klist -- that would show you if the TGT was acquired when you logged in or by increasing pam_verbosity to tell you when the login happened offline. btw for testing, you can send SIGUSR1 and SIGUSR2 to trigger online/offline transitions (see man sssd(8)) From tobeychris at hotmail.com Mon Oct 26 20:05:33 2015 From: tobeychris at hotmail.com (Chris Tobey) Date: Mon, 26 Oct 2015 16:05:33 -0400 Subject: [Freeipa-users] FreeNAS Authenticating Against FreeIPA Message-ID: Hi Youenn, That is very possible. I was looking at the logs for dirsrv and did notice this though: [26/Oct/2015:15:56:51 -0400] - slapd shutting down - signaling operation threads [26/Oct/2015:15:56:51 -0400] - slapd shutting down - closing down internal subsystems and plugins [26/Oct/2015:15:56:51 -0400] - Waiting for 4 database threads to stop [26/Oct/2015:15:56:52 -0400] - All database threads now stopped [26/Oct/2015:15:56:52 -0400] - slapd stopped. [26/Oct/2015:15:56:56 -0400] - 389-Directory/1.2.11.15 B2014.314.1342 starting up [26/Oct/2015:15:56:56 -0400] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=burlington,dc=test,dc=tv [26/Oct/2015:15:56:56 -0400] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=burlington,dc=test,dc=tv [26/Oct/2015:15:56:56 -0400] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=burlington,dc=test,dc=tv [26/Oct/2015:15:56:56 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=burlington,dc=test,dc=tv--no CoS Templates found, which should be added before the CoS Definition. [26/Oct/2015:15:56:56 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=burlington,dc=test,dc=tv--no CoS Templates found, which should be added before the CoS Definition. [26/Oct/2015:15:56:56 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [26/Oct/2015:15:56:56 -0400] - Listening on All Interfaces port 636 for LDAPS requests [26/Oct/2015:15:56:56 -0400] - Listening on /var/run/slapd-BURLINGTON-TEST-TV.socket for LDAPI requests [26/Oct/2015:15:57:35 -0400] sidgen_task_thread - [file ipa_sidgen_task.c, line 191]: Sidgen task starts ... [26/Oct/2015:15:57:35 -0400] find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [16777294l] into an unused SID. [26/Oct/2015:15:57:35 -0400] do_work - [file ipa_sidgen_task.c, line 151]: Cannot add SID to existing entry. [26/Oct/2015:15:57:35 -0400] sidgen_task_thread - [file ipa_sidgen_task.c, line 196]: Sidgen task finished [32]. All of our UIDs are in the format 1677xxxx, does anyone know if this is causing an issue with sidgen? When I do an ldapsearch on the admin user I can see that the lines: ? objectClass: ipaNTUserAttrs ? ipaNTSecurityIdentifier: S-1-5-21-248003272-3197508955-2021798454-500 ? And my SID looks correct based on: $ net getlocalsid SID for domain CHIMERA is: S-1-5-21-248003272-3197508955-2021798454 But when I do an ldapsearch on any other users I do not see these properties added. Thank From: Youenn PIOLET [mailto:piolet.y at gmail.com] Sent: October-19-15 8:34 AM To: Chris Tobey Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Hi Chris, This may come from the ipa attributes added by adtrust on user/group classes. For example in 4.1.4: FreeIPA will add on each user the attribute (for ipasam.so usage): ipaNTSecurityIdentifier: S-1-5-**-******* when standard samba attributes known by samba with ldapsam.so are: sambaSID: S-1-5-**-******* I guess as the OID must be different, your CIFS will not recognise the attribute and won't be able to use it. I also guess it is the same for the password hash that may not be using the right algorithm. You can check this directly in your IPA 365directory tree, and with dirsrv logfiles. I suppose you would see FreeNAS trying to search for specific attributes in user objects that don't exist. These informations are based on deduction but I'm not confident enough to assure you this is a fact :) -- Youenn Piolet piolet.y at gmail.com 2015-10-17 16:47 GMT+02:00 Chris Tobey : Hi Youenn, Thank you for the response. I am sure the issue is related to the samba attributes not existing, but I am not fully clear on how to fix it. I was trying to find out the correct steps on a CentOS system, and I think it is something like: >yum remove samba-common >yum install samba4 >yum install ipa-server-trust-ad >ipa-adtrust-install I thought the ipa-adtrust-install was supposed to add the samba attributes, but for some reason it still does not work. Does anyone have any insight in what steps I might have missed? Thanks, -Chris From: Youenn PIOLET [mailto:piolet.y at gmail.com] Sent: October-11-15 6:49 PM To: Chris Tobey Cc: freeipa-users at redhat.com; Matt . Subject: Re: [Freeipa-users] FreeNAS Authenticating Againts FreeIPA Sorry for the double post. I forgot to say that my speech is about newest versions of FreeIPA. Maybe someone here knows something about IPA 3.0 ? I'm not sure it used to work with ipasam module. But I suppose the problem is the same: you need to generate Samba schema values for your IPA users in the directory. Cheers, -- Youenn Piolet piolet.y at gmail.com 2015-10-12 0:41 GMT+02:00 Youenn PIOLET : Hi Chris, First, to be sure were on the same page: Without IPA, to make CIFS users authenticate against directory in a classic LDAP implementation, you need to extend your LDAP tree with Samba schema. The FreeNAS documentation is a bit light on this subjet and previous FreeNAS versions (stable 9.3 included) used to mess up rfc2307bis/rfc2307. I think it is fixed now, and know nothing about your 9.2 version. Wrote some messy stuff about it here: https://github.com/uZer/rootools/blob/master/ldap/integrations/ldap.integration.freenas.md To make CIFS users authenticate or FreeIPA recent versions (I only tried with 4.1), I suggest you to start by reading some of our investigations in this thread: [Freeipa-users] Ubuntu Samba Server Auth against IPA https://www.redhat.com/archives/freeipa-users/2015-August/thread.html#00000 When we discuss about this in august, I've spend almost a week trying to make this integration with FreeNAS/FreeIPA work. I quit FreeNAS without fully understand why it didn't work, and moved our CIFS to a dedicated Centos server. Matt arrived with a similar situation in Ubuntu. To quickly summarize the issue, FreeNAS and Ubuntu CIFS work by default with ldapsam.so module. FreeIPA developpers have built a AD trust exchange possibility with a custom ipasam module that isn't compiled yet for Ubuntu or FreeNAS. This module gives the possibility to use IPA AD trust components (e.g. special schema in IPA's directory managing user/group NT SID) If you can't compile the module for FreeNAS / FreeBSD, you may need to extend 365directory with Samba schema. You will need to find a way to generate the new attributes when adding users or groups in FreeIPA, and a way to store password in a CIFS/NT understandable way. I don't suggest you to follow this dark path. You can also quit FreeNAS and migrate to CentOS with ipasam as I did ;) Good luck in your experimentations, I hope you will succeed! -- Youenn Piolet piolet.y at gmail.com 2015-10-11 2:06 GMT+02:00 Chris Tobey : Hi Everyone, I have a functioning FreeIPA server that manages all my users and I would like to also use it for my FreeNAS CIFS shares to authenticate against. Does anyone know what needs to be run on both servers to get this working? I believe it has something to do with Samba properties on the FreeIPA side. I had tried asking the FreeNAS forums but they were of no help (https://forums.freenas.org/index.php?threads/freeipa-and-freenas-ldap-setup.37083/). I have seen similar requests and success stories, but no actual steps on how to do it. Info: FreeIPA v3.0.0-42 running on CentOS 6.6. FreeNAS 9.2.1.9 (can use 9.3 if easier, was trying to get it working before dealing with certs). Any help is appreciated. Thanks, -Chris -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 27 07:50:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Oct 2015 08:50:52 +0100 Subject: [Freeipa-users] How grant access to userPassword for System Accounts In-Reply-To: <1902672719.45450360.1445879121127.JavaMail.zimbra@redhat.com> References: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> <1902672719.45450360.1445879121127.JavaMail.zimbra@redhat.com> Message-ID: <562F2CDC.6020703@redhat.com> Hi John, let me add that preferred way is to convince your 'solution' to do it in a safe way. Also, FreeIPA does not store passwords in clear text so the userPassword attribute should show only hashes and not clear text. It depends on the 'solution' if it can deal with hashes or not. Have a nice day. Petr^2 Spacek On 26.10.2015 18:05, German Parente wrote: > > Hi John > > you could add a particular ACI to allow any groupdn or userdn to read/search userPassword under the required tree. Something like: > > aci: (targetattr = "userPassword") (target = "ldap:///cn=users,cn=accounts,dc=,dc=") (version 3.0;acl "Allow password read";allow (read,compare,search)(groupdn = "ldap:///");) > > Regards, > > German. > > > ----- Original Message ----- >> From: "John Duino" >> To: "freeipa-users" >> Sent: Monday, October 26, 2015 5:41:47 PM >> Subject: [Freeipa-users] How grant access to userPassword for System Accounts >> >> I am trying to hook our VoIP solution (sipxecs-based openUC) to our FreeIPA. >> But it appears that it wants to read-in the userPassword rather than just >> auth against the ldap. >> I know Directory Manager is the only account that has the ability to read >> userPassword, but is there a way to grant that to a System Account >> (uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some other >> path/process I'm overlooking short of using the Directory Manager account? >> >> Thanks! >> >> John >> >> -- >> 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 >> > -- Petr^2 Spacek From abokovoy at redhat.com Tue Oct 27 08:42:29 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Oct 2015 10:42:29 +0200 Subject: [Freeipa-users] How grant access to userPassword for System Accounts In-Reply-To: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> References: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> Message-ID: <20151027084229.GI6367@redhat.com> On Mon, 26 Oct 2015, John Duino wrote: >I am trying to hook our VoIP solution (sipxecs-based openUC) to our >FreeIPA. But it appears that it wants to read-in the userPassword >rather than just auth against the ldap. I know Directory Manager is >the only account that has the ability to read userPassword, but is >there a way to grant that to a System Account >(uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some >other path/process I'm overlooking short of using the Directory Manager >account? sipxecs internally uses LDAP bind authentication, it does not need access to userPassword. See, for example, the actual code that does it via Spring framework's LDAP Bind Authentication provider: https://github.com/SIPfoundry/sipxecs/blob/master/sipXconfig/neoconf/src/org/sipfoundry/sipxconfig/security/ConfigurableLdapAuthenticationProvider.java#L167 I wonder what is your configuration compared to what is listed in https://sipfoundry.atlassian.net/wiki/display/sipXecs/LDAP+Integration -- you can send me screenshots off-list. -- / Alexander Bokovoy From th at casalogic.dk Tue Oct 27 13:53:53 2015 From: th at casalogic.dk (Troels Hansen) Date: Tue, 27 Oct 2015 14:53:53 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 Message-ID: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> This might be related to the old thread https://www.redhat.com/archives/freeipa-users/2015-January/msg00285.html but on the other side not quite, and can't see that it have been been solved. I have been spending quite some time on this, but haven't been able to solve it yet. My problem is: I have a complete new infrastructure based om RedHat7 and CentOS7 servers. No Windows and defenently no AD, however we use Samba for sharing files to some clients. Clients is mostly Ubuntu based laptops, completely individually manages. No central user admin or anything. Users manage their own PC 100%. We have two IPA servers set up, and all Linux servers authenticate against IPA and all that works flawless. We migrated from a pure LDAP / Samba3 based solution to IPA / Samba4, using the ipa migrate script and this also worked fine. Now comes the tricky part that I haven't been able to solve. I can't seem to set Samba to play with IPA. I have been trying to use plain old ldapsam backend, but never managed to get it to work. Seems Samba can't authenticate users. Tried ipasam backend, using kerberos, following the instructions from the old thread: https://www.redhat.com/archives/freeipa-users/2015-September/msg00052.html Samba fails to start up, with a: 2015/10/27 14:13:42.127557, 0] ipa_sam.c:4478(pdb_init_ipasam) pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it. [2015/10/27 14:13:42.127785, 0] ../source3/passdb/pdb_interface.c:178(make_pdb_method_name) pdb backend ipasam:"ldaps://kenai.casalogic.lan ldaps://koda.casalogic.lan" did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO) If I look at tje users directly in LDAP, I can see they don't have a ipaNTHash or ipaNTSecurityIdentifier attribute, however have preserved their old LDAP-ish sambaLMPassword and sambaNTPassword I might be completely off, but I need Samba to authenticate users against IPA, using password, and not krb as I have no control over the clients. FreeIPA is currently 4.1 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.doll at gmail.com Tue Oct 27 14:46:42 2015 From: joshua.doll at gmail.com (Joshua Doll) Date: Tue, 27 Oct 2015 14:46:42 +0000 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> Message-ID: On Tue, Oct 27, 2015 at 10:03 AM Troels Hansen wrote: > This might be related to the old thread > https://www.redhat.com/archives/freeipa-users/2015-January/msg00285.html > but on the other side not quite, and can't see that it have been been > solved. > > I have been spending quite some time on this, but haven't been able to > solve it yet. > > My problem is: > > I have a complete new infrastructure based om RedHat7 and CentOS7 servers. > No Windows and defenently no AD, however we use Samba for sharing files to > some clients. > > Clients is mostly Ubuntu based laptops, completely individually manages. > No central user admin or anything. > Users manage their own PC 100%. > > We have two IPA servers set up, and all Linux servers authenticate against > IPA and all that works flawless. > > We migrated from a pure LDAP / Samba3 based solution to IPA / Samba4, > using the ipa migrate script and this also worked fine. > > Now comes the tricky part that I haven't been able to solve. > > I can't seem to set Samba to play with IPA. > > I have been trying to use plain old ldapsam backend, but never managed to > get it to work. > Seems Samba can't authenticate users. > > Tried ipasam backend, using kerberos, following the instructions from the > old thread: > https://www.redhat.com/archives/freeipa-users/2015-September/msg00052.html > Samba fails to start up, with a: > 2015/10/27 14:13:42.127557, 0] ipa_sam.c:4478(pdb_init_ipasam) > pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the > domain. We cannot work reliably without it. > [2015/10/27 14:13:42.127785, 0] > ../source3/passdb/pdb_interface.c:178(make_pdb_method_name) > pdb backend ipasam:"ldaps://kenai.casalogic.lan > ldaps://koda.casalogic.lan" did not correctly init (error was > NT_STATUS_CANT_ACCESS_DOMAIN_INFO) > > If I look at tje users directly in LDAP, I can see they don't have a > ipaNTHash or ipaNTSecurityIdentifier attribute, however have preserved > their old LDAP-ish sambaLMPassword and sambaNTPassword > > I might be completely off, but I need Samba to authenticate users against > IPA, using password, and not krb as I have no control over the clients. > > FreeIPA is currently 4.1 > > -- > > Med venlig hilsen > > *Troels Hansen* > > Systemkonsulent > > Casalogic A/S > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos > og meget mere. > -- > 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 To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the ipa-adtrust-install --add-sids, even though I was not setting up a trust. It would be nice if there was a way to generate these values another way, maybe there is but I missed it. --Joshua D Doll -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 27 14:48:05 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 27 Oct 2015 15:48:05 +0100 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <1445376356.31026.15.camel@stefany.eu> References: <1445376356.31026.15.camel@stefany.eu> Message-ID: <562F8EA5.5090207@redhat.com> On 20.10.2015 23:25, Martin ?tefany wrote: > Hello, > > did anybody manage to get FreeIPA admin user (member of admins group, > full sudo access, etc.) to be also Cockpit user with administrative > privileges? I've already figured out that it's closely related to > Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... I > was not able to get a working configuration. > > Some version / configuration details: > $ cat /etc/centos-release > CentOS Linux release 7.1.1503 (Core) > > $ rpm -q ipa-client > ipa-client-4.1.0-18.el7.centos.4.x86_64 > > $ rpm -q cockpit # from sgallagh's COPR repository > cockpit-0.80-1.el7.centos.x86_64 > > $ rpm -q polkit > polkit-0.112-5.el7.x86_64 > > $ sudo ls /etc/polkit-1/rules.d/ > 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules > > $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules > polkit.addAdminRule(function(action, subject) { > return ["unix-group:admins", "unix-group:wheel"]; > }); > > $ sudo ls /etc/polkit-1/localauthority.conf.d/ > 40-custom.conf > > $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf > [Configuration] > AdminIdentities=unix-group:admins;unix-group:wheel > > $ ipa user-show martin | grep groups > Member of groups: trust admins, ipausers, admins, ... > > Cockpit logs me in automatically using Kerberos (GSSAPI), but I can't > perform administrative tasks, cannot see journald, etc. > > One thing that I thought to cause the issue is that pkexec is asking me > select user first, instead of asking/not asking for password: > $ pkexec cockpit-bridge > ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === > Authentication is needed to run `/usr/bin/cockpit-bridge' as the super > user > Multiple identities can be used for authentication: > 1. Martin ?tefany (martin) > 2. ... > 3. ... > Choose identity to authenticate as (1-3): 1 > Password: > ==== AUTHENTICATION COMPLETE === > cockpit-bridge: no option specified > > and documentation claims that sudo / pkexec should not ask for password > for particular user, but 1. I don't like that idea; 2. I have regular > 1000:1000 user in wheel group for whom everything works just fine - sudo > and pkexec ask for password as expected, and still in cockpit admin > stuff works as expected. I have seen your answer in the ticket https://fedorahosted.org/freeipa/ticket/3203#comment:6 Could you create a very short and concise how-to to http://www.freeipa.org/page/HowTos , please? Your Fedora login should allow you to create a new wiki page and to link it to http://www.freeipa.org/page/HowTos . Thank you for your time! -- Petr^2 Spacek From jduino at oblong.com Tue Oct 27 15:26:11 2015 From: jduino at oblong.com (John Duino) Date: Tue, 27 Oct 2015 10:26:11 -0500 (CDT) Subject: [Freeipa-users] How grant access to userPassword for System Accounts In-Reply-To: References: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> <20151027084229.GI6367@redhat.com> Message-ID: <1210881555.6255848.1445959571253.JavaMail.zimbra@oblong.com> Hmmm seems I have been misinformed, then. And then why does it have a field for 'mapping' the password? Well, I think that's off-topic for the list. I'll dig more later today. -- John Duino ----- Original Message ----- From: "Alexander Bokovoy" To: "John Duino" Cc: "freeipa-users" Sent: Tuesday, October 27, 2015 1:42:29 AM Subject: Re: [Freeipa-users] How grant access to userPassword for System Accounts On Mon, 26 Oct 2015, John Duino wrote: >I am trying to hook our VoIP solution (sipxecs-based openUC) to our >FreeIPA. But it appears that it wants to read-in the userPassword >rather than just auth against the ldap. I know Directory Manager is >the only account that has the ability to read userPassword, but is >there a way to grant that to a System Account >(uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some >other path/process I'm overlooking short of using the Directory Manager >account? sipxecs internally uses LDAP bind authentication, it does not need access to userPassword. See, for example, the actual code that does it via Spring framework's LDAP Bind Authentication provider: https://github.com/SIPfoundry/sipxecs/blob/master/sipXconfig/neoconf/src/org/sipfoundry/sipxconfig/security/ConfigurableLdapAuthenticationProvider.java#L167 I wonder what is your configuration compared to what is listed in https://sipfoundry.atlassian.net/wiki/display/sipXecs/LDAP+Integration -- you can send me screenshots off-list. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 27 15:38:59 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Oct 2015 17:38:59 +0200 Subject: [Freeipa-users] How grant access to userPassword for System Accounts In-Reply-To: <1210881555.6255848.1445959571253.JavaMail.zimbra@oblong.com> References: <1725183904.6078146.1445877707863.JavaMail.zimbra@oblong.com> <20151027084229.GI6367@redhat.com> <1210881555.6255848.1445959571253.JavaMail.zimbra@oblong.com> Message-ID: <20151027153859.GP6367@redhat.com> On Tue, 27 Oct 2015, John Duino wrote: >Hmmm seems I have been misinformed, then. And then why does it have a >field for 'mapping' the password? Well, I think that's off-topic for >the list. I'll dig more later today. My understanding is that sipxecs has several modes for verifying passwords when users come from LDAP: - password is stored locally in sipxecs database and checked directly - password is stored in LDAP and checked by LDAP bind - password is complemented by PIN The methods can be combined, but there is also LDAP migration which means a local database is populated with data from LDAP, thus setting initial values in the database based on LDAP values. I guess this is where userPassword is coming into play and perhaps some option can be used to say 'use default password if no password is available in LDAP'. I haven't configured sipxecs myself but I saw that in documentation, IIRC. > >-- >John Duino > >----- Original Message ----- >From: "Alexander Bokovoy" >To: "John Duino" >Cc: "freeipa-users" >Sent: Tuesday, October 27, 2015 1:42:29 AM >Subject: Re: [Freeipa-users] How grant access to userPassword for System Accounts > >On Mon, 26 Oct 2015, John Duino wrote: >>I am trying to hook our VoIP solution (sipxecs-based openUC) to our >>FreeIPA. But it appears that it wants to read-in the userPassword >>rather than just auth against the ldap. I know Directory Manager is >>the only account that has the ability to read userPassword, but is >>there a way to grant that to a System Account >>(uid=voip,cn=sysaccounts,cn=etc,dc=oblong,dc=com)? Or perhaps some >>other path/process I'm overlooking short of using the Directory Manager >>account? >sipxecs internally uses LDAP bind authentication, it does not need >access to userPassword. > >See, for example, the actual code that does it via Spring framework's >LDAP Bind Authentication provider: >https://github.com/SIPfoundry/sipxecs/blob/master/sipXconfig/neoconf/src/org/sipfoundry/sipxconfig/security/ConfigurableLdapAuthenticationProvider.java#L167 > >I wonder what is your configuration compared to what is listed in >https://sipfoundry.atlassian.net/wiki/display/sipXecs/LDAP+Integration >-- you can send me screenshots off-list. >-- >/ 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 -- / Alexander Bokovoy From sdutina at gmail.com Tue Oct 27 16:51:59 2015 From: sdutina at gmail.com (Srdjan Dutina) Date: Tue, 27 Oct 2015 17:51:59 +0100 Subject: [Freeipa-users] Winsync Message-ID: Hi! Is syncing (winsync) users and passwords from MS Active Directory deprecated in FreeIPA 4.x? If not, is there some documentation on how to use it? Additionaly, when using FreeIPA - AD trust, is it possible for user from trusted domain to log on to FreeIPA web UI? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Oct 27 17:06:44 2015 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 27 Oct 2015 18:06:44 +0100 Subject: [Freeipa-users] Winsync In-Reply-To: References: Message-ID: <562FAF24.9060707@redhat.com> On 10/27/2015 05:51 PM, Srdjan Dutina wrote: > Hi! > Hello Srdjan, > Is syncing (winsync) users and passwords from MS Active Directory > deprecated in FreeIPA 4.x? > If not, is there some documentation on how to use it? > Winsync synchronization is not deprecated as of now, but we are trying to move away from it in favor of the trust-based solution. I would certainly encourage you to try that before using winsync. > Additionaly, when using FreeIPA - AD trust, is it possible for user from > trusted domain to log on to FreeIPA web UI? Yes. > > > Thanks! > > From marc.boorshtein at tremolosecurity.com Tue Oct 27 17:11:25 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 27 Oct 2015 13:11:25 -0400 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy Message-ID: All, I'm trying to create an S4u2self/proxy that will give me a ticket to log into ipa web. I have ipa installed on centos 7 and the client installed on centos 6. The client is written in Java (Java 8). When I try the following impersonation code: GSSManager manager = GSSManager.getInstance(); GSSCredential self = manager.createCredential(GSSCredential.INITIATE_ONLY); GSSName user = manager.createName("mmosley", GSSName.NT_USER_NAME); GSSCredential impCred = ((ExtendedGSSCredential)self).impersonate(user); I get the following output from Java: [tremoloadmin at unison-freeipa ~]$ java -Djavax.security.auth.useSubjectCredsOnly=false -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true -jar tests4u-1.0-SNAPSHOT-jar-with-dependencies.jar Hello World! Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) No Subject >>>KinitOptions cache name is /tmp/krb5cc_500 >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>DEBUG key type: 18 >>>DEBUG auth time: Mon Oct 26 21:11:17 EDT 2015 >>>DEBUG start time: Mon Oct 26 21:11:17 EDT 2015 >>>DEBUG end time: Tue Oct 27 21:11:17 EDT 2015 >>>DEBUG renew_till time: Tue Oct 27 21:11:18 EDT 2015 >>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN Java config name: null Native config name: /etc/krb5.conf Loaded from native config >>>DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>DEBUG key type: 0 >>>DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG start time: null >>>DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Oct 27 21:11:17 EDT 2015 Search Subject for SPNEGO INIT cred (<>, sun.security.jgss.spnego.SpNegoCredElement) No Subject Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) No Subject >>>KinitOptions cache name is /tmp/krb5cc_500 >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>DEBUG key type: 18 >>>DEBUG auth time: Mon Oct 26 21:11:17 EDT 2015 >>>DEBUG start time: Mon Oct 26 21:11:17 EDT 2015 >>>DEBUG end time: Tue Oct 27 21:11:17 EDT 2015 >>>DEBUG renew_till time: Tue Oct 27 21:11:18 EDT 2015 >>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>DEBUG key type: 0 >>>DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG start time: null >>>DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Oct 27 21:11:17 EDT 2015 >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 18 17 16 23. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>> KdcAccessibility: reset getKDCFromDNS using UDP >>> KrbKdcReq send: kdc=freeipa.rhelent.lan. UDP:88, timeout=30000, number of retries =3, #bytes=825 >>> KDCCommunication: kdc=freeipa.rhelent.lan. UDP:88, timeout=30000,Attempt =1, #bytes=825 >>> KrbKdcReq send: #bytes read=680 >>> KdcAccessibility: remove freeipa.rhelent.lan.:88 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType > KrbKdcRep.check: at #1. request for true, received false Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) at io.tremolo.App.main(App.java:27) Caused by: KrbException: Message stream modified (41) at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:73) at sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:87) at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259) at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:270) at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:67) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 3 more Looking at KrbKdcRep.java:73 it looks like the failure is happening because java is setting the forwardable flag to true on the request but the response has no options in it. Should the forwardable option be false in the request? I setup my client with: ipa - freeipa.rhelent.lan sp - freeipa.rhelent.lan proxy - unison-freeipa.rhelent.lan $ ipa service-add HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN --ok-as-delegate=true Added the following to 389: dn: cn=ipaweb-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan objectClass: groupOfPrincipals objectClass: top cn: ipaweb-http-delegation-targets memberPrincipal: HTTP/freeipa.rhelent.lan at RHELENT.LAN dn: cn=unison-http-delegation,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top cn: unison-http-delegation memberPrincipal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN ipaAllowedTarget: cn=ipaweb-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan then created a keytab and was able to kinit with it: ipa-getkeytab -s freeipa.rhelent.lan -p HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k unison-freeipa.keytab Finally, when I look at the packets I see one request and one response: request: Kerberos tgs-req pvno: 5 msg-type: krb-tgs-req (12) padata: 2 items PA-DATA PA-FOR-USER padata-type: kRB5-PADATA-S4U2SELF (129) padata-value: 304fa0143012a003020101a10b30091b076d6d6f736c6579... name name-type: kRB5-NT-PRINCIPAL (1) name-string: 1 item KerberosString: mmosley realm: RHELENT.LAN cksum cksumtype: cKSUMTYPE-HMAC-MD5 (-138) checksum: fdd3addace7f48fe263bfcc1a4dbec72 auth: Kerberos PA-DATA PA-TGS-REQ padata-type: kRB5-PADATA-TGS-REQ (1) padata-value: 6e82023730820233a003020105a10302010ea20703050000... ap-req pvno: 5 msg-type: krb-ap-req (14) Padding: 0 ap-options: 00000000 0... .... = reserved: False .0.. .... = use-session-key: False ..0. .... = mutual-required: False ticket tkt-vno: 5 realm: RHELENT.LAN sname name-type: kRB5-NT-SRV-INST (2) name-string: 2 items KerberosString: krbtgt KerberosString: RHELENT.LAN enc-part etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) kvno: 1 cipher: a07df35b253755d20a234bb8f5ce573e06e27d95f9e4c996... authenticator etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) cipher: fe25dc900c05901a5b1c778f0d0410fd245e58507dc4ac40... req-body Padding: 0 kdc-options: 40000000 (forwardable) 0... .... = reserved: False .1.. .... = forwardable: True ..0. .... = forwarded: False ...0 .... = proxiable: False .... 0... = proxy: False .... .0.. = allow-postdate: False .... ..0. = postdated: False .... ...0 = unused7: False 0... .... = renewable: False .0.. .... = unused9: False ..0. .... = unused10: False ...0 .... = opt-hardware-auth: False .... ..0. = request-anonymous: False .... ...0 = canonicalize: False 0... .... = constrained-delegation: False ..0. .... = disable-transited-check: False ...0 .... = renewable-ok: False .... 0... = enc-tkt-in-skey: False .... ..0. = renew: False .... ...0 = validate: False realm: RHELENT.LAN sname name-type: kRB5-NT-PRINCIPAL (1) name-string: 2 items KerberosString: HTTP KerberosString: unison-freeipa.rhelent.lan till: 1970-01-01 00:00:00 (UTC) nonce: 1950860413 etype: 4 items ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) ENCTYPE: eTYPE-DES3-CBC-SHA1 (16) ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23) And the response: Kerberos tgs-rep pvno: 5 msg-type: krb-tgs-rep (13) crealm: RHELENT.LAN cname name-type: kRB5-NT-PRINCIPAL (1) name-string: 1 item KerberosString: mmosley ticket tkt-vno: 5 realm: RHELENT.LAN sname name-type: kRB5-NT-PRINCIPAL (1) name-string: 2 items KerberosString: HTTP KerberosString: unison-freeipa.rhelent.lan enc-part etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) kvno: 1 cipher: d5ba7253ac30a63034ac5985fa0c782dc86cb0a9dd859127... enc-part etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) cipher: 7c6f2034caddf129d1550b91f4ef0157b2f9ac4c351023d3... On the IPA server I get: Oct 26 23:29:40 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.2.167: ISSUE: authtime 1445908277, etypes {rep=18 tkt=18 ses=18}, HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN Oct 26 23:29:40 freeipa.rhelent.lan krb5kdc[7507](info): ... PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN It looks like everything is working, right? If either Java didn't send the forwardable to "true" or if IPA sent the options back in the response I'd be in business? Any thoughts? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 From abokovoy at redhat.com Tue Oct 27 17:20:26 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Oct 2015 19:20:26 +0200 Subject: [Freeipa-users] Winsync In-Reply-To: <562FAF24.9060707@redhat.com> References: <562FAF24.9060707@redhat.com> Message-ID: <20151027172026.GS6367@redhat.com> On Tue, 27 Oct 2015, Tomas Babej wrote: > > >On 10/27/2015 05:51 PM, Srdjan Dutina wrote: >> Hi! >> > >Hello Srdjan, > >> Is syncing (winsync) users and passwords from MS Active Directory >> deprecated in FreeIPA 4.x? >> If not, is there some documentation on how to use it? >> > >Winsync synchronization is not deprecated as of now, but we are trying >to move away from it in favor of the trust-based solution. I would >certainly encourage you to try that before using winsync. Documentation is in the 'Windows Integration Guide': https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html Chapter 7 covers winsync. >> Additionaly, when using FreeIPA - AD trust, is it possible for user from >> trusted domain to log on to FreeIPA web UI? > >Yes. No. AD users cannot login to web UI. We are planning to add this possibility in FreeIPA 4.4 or around that time, to allow AD users to manage parts of their ID overrides. -- / Alexander Bokovoy From sdutina at gmail.com Tue Oct 27 17:33:48 2015 From: sdutina at gmail.com (Srdjan Dutina) Date: Tue, 27 Oct 2015 18:33:48 +0100 Subject: [Freeipa-users] Winsync In-Reply-To: <20151027172026.GS6367@redhat.com> References: <562FAF24.9060707@redhat.com> <20151027172026.GS6367@redhat.com> Message-ID: Hi Aleksander and Tomas, thanks for quick responses! I find trust-based solution more advanced but also more complicated - two sites, one with FreeIPA and other with AD domain, limited communication from FreeIPA to AD site, FreeIPA not aware of AD sites, questionable use of RODCs and Kerberos which heavily depends on DNS. Acceptable solution would be public key login for my AD users but they are not able to log in to Free IPA web UI to update their SSH keys. So Winsync seems like simpler solution here. Regards, Srdjan. On Tue, Oct 27, 2015 at 6:20 PM, Alexander Bokovoy wrote: > On Tue, 27 Oct 2015, Tomas Babej wrote: > >> >> >> On 10/27/2015 05:51 PM, Srdjan Dutina wrote: >> >>> Hi! >>> >>> >> Hello Srdjan, >> >> Is syncing (winsync) users and passwords from MS Active Directory >>> deprecated in FreeIPA 4.x? >>> If not, is there some documentation on how to use it? >>> >>> >> Winsync synchronization is not deprecated as of now, but we are trying >> to move away from it in favor of the trust-based solution. I would >> certainly encourage you to try that before using winsync. >> > Documentation is in the 'Windows Integration Guide': > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html > > Chapter 7 covers winsync. > > Additionaly, when using FreeIPA - AD trust, is it possible for user from >>> trusted domain to log on to FreeIPA web UI? >>> >> >> Yes. >> > No. AD users cannot login to web UI. We are planning to add this > possibility in FreeIPA 4.4 or around that time, to allow AD users to > manage parts of their ID overrides. > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Oct 27 19:15:32 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Oct 2015 15:15:32 -0400 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: Message-ID: <562FCD54.2080702@redhat.com> On 27/10/15 13:11, Marc Boorshtein wrote: > All, > > I'm trying to create an S4u2self/proxy that will give me a ticket to > log into ipa web. I have ipa installed on centos 7 and the client > installed on centos 6. The client is written in Java (Java 8). When > I try the following impersonation code: > > GSSManager manager = GSSManager.getInstance(); > > GSSCredential self = > manager.createCredential(GSSCredential.INITIATE_ONLY); > > GSSName user = manager.createName("mmosley", GSSName.NT_USER_NAME); > > GSSCredential impCred = ((ExtendedGSSCredential)self).impersonate(user); > > I get the following output from Java: > > [tremoloadmin at unison-freeipa ~]$ java > -Djavax.security.auth.useSubjectCredsOnly=false > -Dsun.security.krb5.debug=true -Dsun.security.jgss.debug=true -jar > tests4u-1.0-SNAPSHOT-jar-with-dependencies.jar > Hello World! > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > No Subject >>>> KinitOptions cache name is /tmp/krb5cc_500 >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>> DEBUG key type: 18 >>>> DEBUG auth time: Mon Oct 26 21:11:17 EDT 2015 >>>> DEBUG start time: Mon Oct 26 21:11:17 EDT 2015 >>>> DEBUG end time: Tue Oct 27 21:11:17 EDT 2015 >>>> DEBUG renew_till time: Tue Oct 27 21:11:18 EDT 2015 >>>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > Java config name: null > Native config name: /etc/krb5.conf > Loaded from native config >>>> DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>> DEBUG key type: 0 >>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG start time: null >>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() > Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Oct 27 21:11:17 EDT > 2015 > Search Subject for SPNEGO INIT cred (<>, > sun.security.jgss.spnego.SpNegoCredElement) > No Subject > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > No Subject >>>> KinitOptions cache name is /tmp/krb5cc_500 >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>> DEBUG key type: 18 >>>> DEBUG auth time: Mon Oct 26 21:11:17 EDT 2015 >>>> DEBUG start time: Mon Oct 26 21:11:17 EDT 2015 >>>> DEBUG end time: Tue Oct 27 21:11:17 EDT 2015 >>>> DEBUG renew_till time: Tue Oct 27 21:11:18 EDT 2015 >>>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>> DEBUG key type: 0 >>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG start time: null >>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() > Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Oct 27 21:11:17 EDT > 2015 >>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType > Using builtin default etypes for default_tgs_enctypes > default etypes for default_tgs_enctypes: 18 17 16 23. >>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>>> KdcAccessibility: reset > getKDCFromDNS using UDP >>>> KrbKdcReq send: kdc=freeipa.rhelent.lan. UDP:88, timeout=30000, number of retries =3, #bytes=825 >>>> KDCCommunication: kdc=freeipa.rhelent.lan. UDP:88, timeout=30000,Attempt =1, #bytes=825 >>>> KrbKdcReq send: #bytes read=680 >>>> KdcAccessibility: remove freeipa.rhelent.lan.:88 >>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> KrbKdcRep.check: at #1. request for true, received false > Exception in thread "main" GSSException: Failure unspecified at > GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials > failed!) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) > at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) > at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) > at io.tremolo.App.main(App.java:27) > Caused by: KrbException: Message stream modified (41) > at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:73) > at sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:87) > at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259) > at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:270) > at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:67) > at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) > ... 3 more > > Looking at KrbKdcRep.java:73 it looks like the failure is happening > because java is setting the forwardable flag to true on the request > but the response has no options in it. Should the forwardable option > be false in the request? That's a fair guess. the whole point of constrained delegation (including protocol impersonation) is that you do not want to forward tickets, so you shouldn't ask for forwardable tickets methinks. Simo. > > > I setup my client with: > > ipa - freeipa.rhelent.lan > sp - freeipa.rhelent.lan > proxy - unison-freeipa.rhelent.lan > > $ ipa service-add HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > --ok-as-delegate=true > Added the following to 389: > > dn: cn=ipaweb-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan > objectClass: groupOfPrincipals > objectClass: top > cn: ipaweb-http-delegation-targets > memberPrincipal: HTTP/freeipa.rhelent.lan at RHELENT.LAN > > dn: cn=unison-http-delegation,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan > objectClass: ipaKrb5DelegationACL > objectClass: groupOfPrincipals > objectClass: top > cn: unison-http-delegation > memberPrincipal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > ipaAllowedTarget: > cn=ipaweb-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=rhelent,dc=lan > > then created a keytab and was able to kinit with it: > > ipa-getkeytab -s freeipa.rhelent.lan -p > HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k unison-freeipa.keytab > > Finally, when I look at the packets I see one request and one response: > > request: > > Kerberos > tgs-req > pvno: 5 > msg-type: krb-tgs-req (12) > padata: 2 items > PA-DATA PA-FOR-USER > padata-type: kRB5-PADATA-S4U2SELF (129) > padata-value: > 304fa0143012a003020101a10b30091b076d6d6f736c6579... > name > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 1 item > KerberosString: mmosley > realm: RHELENT.LAN > cksum > cksumtype: cKSUMTYPE-HMAC-MD5 (-138) > checksum: fdd3addace7f48fe263bfcc1a4dbec72 > auth: Kerberos > PA-DATA PA-TGS-REQ > padata-type: kRB5-PADATA-TGS-REQ (1) > padata-value: > 6e82023730820233a003020105a10302010ea20703050000... > ap-req > pvno: 5 > msg-type: krb-ap-req (14) > Padding: 0 > ap-options: 00000000 > 0... .... = reserved: False > .0.. .... = use-session-key: False > ..0. .... = mutual-required: False > ticket > tkt-vno: 5 > realm: RHELENT.LAN > sname > name-type: kRB5-NT-SRV-INST (2) > name-string: 2 items > KerberosString: krbtgt > KerberosString: RHELENT.LAN > enc-part > etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > kvno: 1 > cipher: > a07df35b253755d20a234bb8f5ce573e06e27d95f9e4c996... > authenticator > etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > cipher: > fe25dc900c05901a5b1c778f0d0410fd245e58507dc4ac40... > req-body > Padding: 0 > kdc-options: 40000000 (forwardable) > 0... .... = reserved: False > .1.. .... = forwardable: True > ..0. .... = forwarded: False > ...0 .... = proxiable: False > .... 0... = proxy: False > .... .0.. = allow-postdate: False > .... ..0. = postdated: False > .... ...0 = unused7: False > 0... .... = renewable: False > .0.. .... = unused9: False > ..0. .... = unused10: False > ...0 .... = opt-hardware-auth: False > .... ..0. = request-anonymous: False > .... ...0 = canonicalize: False > 0... .... = constrained-delegation: False > ..0. .... = disable-transited-check: False > ...0 .... = renewable-ok: False > .... 0... = enc-tkt-in-skey: False > .... ..0. = renew: False > .... ...0 = validate: False > realm: RHELENT.LAN > sname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 2 items > KerberosString: HTTP > KerberosString: unison-freeipa.rhelent.lan > till: 1970-01-01 00:00:00 (UTC) > nonce: 1950860413 > etype: 4 items > ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17) > ENCTYPE: eTYPE-DES3-CBC-SHA1 (16) > ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23) > > And the response: > Kerberos > tgs-rep > pvno: 5 > msg-type: krb-tgs-rep (13) > crealm: RHELENT.LAN > cname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 1 item > KerberosString: mmosley > ticket > tkt-vno: 5 > realm: RHELENT.LAN > sname > name-type: kRB5-NT-PRINCIPAL (1) > name-string: 2 items > KerberosString: HTTP > KerberosString: unison-freeipa.rhelent.lan > enc-part > etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > kvno: 1 > cipher: d5ba7253ac30a63034ac5985fa0c782dc86cb0a9dd859127... > enc-part > etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) > cipher: 7c6f2034caddf129d1550b91f4ef0157b2f9ac4c351023d3... > > On the IPA server I get: > > Oct 26 23:29:40 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (4 > etypes {18 17 16 23}) 192.168.2.167: ISSUE: authtime 1445908277, > etypes {rep=18 tkt=18 ses=18}, > HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN for > HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > > Oct 26 23:29:40 freeipa.rhelent.lan krb5kdc[7507](info): ... > PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN > > It looks like everything is working, right? If either Java didn't > send the forwardable to "true" or if IPA sent the options back in the > response I'd be in business? Any thoughts? > > Thanks > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > -- Simo Sorce * Red Hat, Inc * New York From marc.boorshtein at tremolosecurity.com Tue Oct 27 19:43:40 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 27 Oct 2015 15:43:40 -0400 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <562FCD54.2080702@redhat.com> References: <562FCD54.2080702@redhat.com> Message-ID: >> >> Looking at KrbKdcRep.java:73 it looks like the failure is happening >> because java is setting the forwardable flag to true on the request >> but the response has no options in it. Should the forwardable option >> be false in the request? > > > That's a fair guess. > the whole point of constrained delegation (including protocol impersonation) > is that you do not want to forward tickets, so you shouldn't ask for > forwardable tickets methinks. > > Simo. > Thanks Simio. I tried running kinit with forwarding disabled: $ kinit HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k -t ./unison-freeipa.keytab -F $ klist -f Ticket cache: FILE:/tmp/krb5cc_500 Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN Valid starting Expires Service principal 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN Flags: IA But when I try again Java refuses to generate the ticket: tremoloadmin at unison-freeipa ~]$ klist -f Ticket cache: FILE:/tmp/krb5cc_500 Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN Valid starting Expires Service principal 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN Flags: IA Hello World! Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) No Subject >>>KinitOptions cache name is /tmp/krb5cc_500 >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>DEBUG key type: 18 >>>DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN Java config name: /home/tremoloadmin/krb5.conf Loaded from Java config >>>DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>DEBUG key type: 0 >>>DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG start time: null >>>DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT 2015 Search Subject for SPNEGO INIT cred (<>, sun.security.jgss.spnego.SpNegoCredElement) No Subject Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) No Subject >>>KinitOptions cache name is /tmp/krb5cc_500 >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>DEBUG key type: 18 >>>DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>DEBUG key type: 0 >>>DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG start time: null >>>DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>DEBUG renew_till time: null >>> CCacheInputStream: readFlags() Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT 2015 >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType Exception in thread "main" GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) at io.tremolo.App.main(App.java:27) Caused by: KrbException: Invalid option setting in ticket request. (101) at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:165) at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:100) at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:66) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 3 more Looking at KrbTgsReq line 165: if (options.get(KDCOptions.FORWARDABLE) && (!(asCreds.flags.get(Krb5.TKT_OPTS_FORWARDABLE)))) { throw new KrbException(Krb5.KRB_AP_ERR_REQ_OPTIONS); } If I read this correctly it has to be forwardable? If thats the case is Java wrong for requiring the options to be there or is ipa wrong for not sending the options with the response ticket? Thanks From martin at stefany.eu Tue Oct 27 20:08:30 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Tue, 27 Oct 2015 21:08:30 +0100 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <20151021073253.GH3084@hendrix.redhat.com> References: <1445376356.31026.15.camel@stefany.eu> <20151021073253.GH3084@hendrix.redhat.com> Message-ID: <1445976510.2763.22.camel@stefany.eu> On St, 2015-10-21 at 09:32 +0200, Jakub Hrozek wrote: > On Tue, Oct 20, 2015 at 11:25:56PM +0200, Martin ?tefany wrote: > > Hello, > > > > did anybody manage to get FreeIPA admin user (member of admins > > group, > > full sudo access, etc.) to be also Cockpit user with administrative > > privileges? I've already figured out that it's closely related to > > Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... > > I > > was not able to get a working configuration. > > > > Some version / configuration details: > > $ cat /etc/centos-release > > CentOS Linux release 7.1.1503 (Core) > > > > $ rpm -q ipa-client > > ipa-client-4.1.0-18.el7.centos.4.x86_64 > > > > $ rpm -q cockpit # from sgallagh's COPR repository > > cockpit-0.80-1.el7.centos.x86_64 > > > > $ rpm -q polkit > > polkit-0.112-5.el7.x86_64 > > > > $ sudo ls /etc/polkit-1/rules.d/ > > 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules > > > > $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules > > polkit.addAdminRule(function(action, subject) { > > return ["unix-group:admins", "unix-group:wheel"]; > > }); > > > > $ sudo ls /etc/polkit-1/localauthority.conf.d/ > > 40-custom.conf > > > > $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf > > [Configuration] > > AdminIdentities=unix-group:admins;unix-group:wheel > > > > $ ipa user-show martin | grep groups > > Member of groups: trust admins, ipausers, admins, ... > > > > Cockpit logs me in automatically using Kerberos (GSSAPI), but I > > can't > > perform administrative tasks, cannot see journald, etc. > > > > One thing that I thought to cause the issue is that pkexec is asking > > me > > select user first, instead of asking/not asking for password: > > $ pkexec cockpit-bridge > > ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === > > Authentication is needed to run `/usr/bin/cockpit-bridge' as the > > super > > user > > Multiple identities can be used for authentication: > > 1. Martin ?tefany (martin) > > 2. ... > > 3. ... > > Choose identity to authenticate as (1-3): 1 > > Password: > > ==== AUTHENTICATION COMPLETE === > > cockpit-bridge: no option specified > > > > and documentation claims that sudo / pkexec should not ask for > > password > > for particular user, but 1. I don't like that idea; 2. I have > > regular > > 1000:1000 user in wheel group for whom everything works just fine - > > sudo > > and pkexec ask for password as expected, and still in cockpit admin > > stuff works as expected. > > Can you add the admin user to the wheel group on the Cockpit machine? > > But in general I think you're looking for: > https://sourceware.org/glibc/wiki/Proposals/GroupMerging > first round of patches is ready, although it still needs to go through > upstream review (IIRC). > Hello Jakub, adding specific user to local wheel group works, thank you. But it also requires local intervention on the system(s), and on per-user basis. Only limitation detail I see now with PolicyKit is that user is granted full admin rights via pkexec either when custom /etc/polkit-1/rules.d/40 -freeipa.rules is defined or when glibc group merging is merged. If I understand https://fedorahosted.org/freeipa/ticket/5350 correctly, this will be sort-of addressed based on hostgroups, but it will still give more control over the system than sudo would do, won't it? Thank you. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5715 bytes Desc: not available URL: From urgrue at gmail.com Tue Oct 27 20:09:57 2015 From: urgrue at gmail.com (urgrue) Date: Tue, 27 Oct 2015 21:09:57 +0100 Subject: [Freeipa-users] Wrong time / constantly expired passwords Message-ID: Hi, On a new install, I'm being forced a password reset on every login. Not sure why but this doesn't look right: # date Tue Oct 27 21:02:57 CET 2015 # ipa user-status blah1 Last successful authentication: 2015-10-27T19:34:53Z Last failed authentication: 2015-10-27T19:34:20Z Time now: 2015-10-27T20:03:00Z Where is it getting this wrong time from? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Oct 27 20:12:31 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Oct 2015 16:12:31 -0400 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: References: <562FCD54.2080702@redhat.com> Message-ID: <562FDAAF.3050609@redhat.com> On 27/10/15 15:43, Marc Boorshtein wrote: >>> >>> Looking at KrbKdcRep.java:73 it looks like the failure is happening >>> because java is setting the forwardable flag to true on the request >>> but the response has no options in it. Should the forwardable option >>> be false in the request? >> >> >> That's a fair guess. >> the whole point of constrained delegation (including protocol impersonation) >> is that you do not want to forward tickets, so you shouldn't ask for >> forwardable tickets methinks. >> >> Simo. >> > > Thanks Simio. I tried running kinit with forwarding disabled: > > $ kinit HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k -t > ./unison-freeipa.keytab -F > > $ klist -f > > Ticket cache: FILE:/tmp/krb5cc_500 > > Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > > > Valid starting Expires Service principal > > 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN > > Flags: IA > > But when I try again Java refuses to generate the ticket: > > tremoloadmin at unison-freeipa ~]$ klist -f > Ticket cache: FILE:/tmp/krb5cc_500 > Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > > Valid starting Expires Service principal > 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN > Flags: IA > > Hello World! > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > No Subject >>>> KinitOptions cache name is /tmp/krb5cc_500 >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>> DEBUG key type: 18 >>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN > Java config name: /home/tremoloadmin/krb5.conf > Loaded from Java config >>>> DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>> DEBUG key type: 0 >>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG start time: null >>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() > Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT > 2015 > Search Subject for SPNEGO INIT cred (<>, > sun.security.jgss.spnego.SpNegoCredElement) > No Subject > Search Subject for Kerberos V5 INIT cred (<>, > sun.security.jgss.krb5.Krb5InitCredential) > No Subject >>>> KinitOptions cache name is /tmp/krb5cc_500 >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is krbtgt/RHELENT.LAN at RHELENT.LAN >>>> DEBUG key type: 18 >>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>> DEBUG client principal is HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>> DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>> DEBUG key type: 0 >>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG start time: null >>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>> DEBUG renew_till time: null >>>> CCacheInputStream: readFlags() > Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to > krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT > 2015 >>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType > Exception in thread "main" GSSException: Failure unspecified at > GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials > failed!) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) > at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) > at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) > at io.tremolo.App.main(App.java:27) > Caused by: KrbException: Invalid option setting in ticket request. (101) > at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:165) > at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:100) > at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:66) > at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) > at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) > ... 3 more > > Looking at KrbTgsReq line 165: > > if (options.get(KDCOptions.FORWARDABLE) && > (!(asCreds.flags.get(Krb5.TKT_OPTS_FORWARDABLE)))) { > throw new KrbException(Krb5.KRB_AP_ERR_REQ_OPTIONS); > } > > If I read this correctly it has to be forwardable? If thats the case > is Java wrong for requiring the options to be there or is ipa wrong > for not sending the options with the response ticket? I think the best answer would be to look at what the MIT test program does and make sure Java does the same. This stuff works with the native libraries and is interoperable with Windows AD KDCs where the specification was born. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 27 20:45:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Oct 2015 16:45:58 -0400 Subject: [Freeipa-users] Wrong time / constantly expired passwords In-Reply-To: References: Message-ID: <562FE286.4050401@redhat.com> urgrue wrote: > Hi, > On a new install, I'm being forced a password reset on every login. Not > sure why but this doesn't look right: > > # date > Tue Oct 27 21:02:57 CET 2015 > > # ipa user-status blah1 > > Last successful authentication: 2015-10-27T19:34:53Z > Last failed authentication: 2015-10-27T19:34:20Z > Time now: 2015-10-27T20:03:00Z > > Where is it getting this wrong time from? What's wrong with the time? CET is one hour behind GMT right? That is reflected by the difference between the output of date and "Time now". Passwords administratively reset must be set by the user during the first authentication. If the password needs further reset then yeah, something is wrong, but the above looks ok. rob From martin at stefany.eu Tue Oct 27 21:26:09 2015 From: martin at stefany.eu (Martin =?UTF-8?Q?=C5=A0tefany?=) Date: Tue, 27 Oct 2015 22:26:09 +0100 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <562F8EA5.5090207@redhat.com> References: <1445376356.31026.15.camel@stefany.eu> <562F8EA5.5090207@redhat.com> Message-ID: <1445981169.2763.23.camel@stefany.eu> On Ut, 2015-10-27 at 15:48 +0100, Petr Spacek wrote: > On 20.10.2015 23:25, Martin ?tefany wrote: > > Hello, > > > > did anybody manage to get FreeIPA admin user (member of admins > > group, > > full sudo access, etc.) to be also Cockpit user with administrative > > privileges? I've already figured out that it's closely related to > > Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... > > I > > was not able to get a working configuration. > > > > Some version / configuration details: > > $ cat /etc/centos-release > > CentOS Linux release 7.1.1503 (Core) > > > > $ rpm -q ipa-client > > ipa-client-4.1.0-18.el7.centos.4.x86_64 > > > > $ rpm -q cockpit # from sgallagh's COPR repository > > cockpit-0.80-1.el7.centos.x86_64 > > > > $ rpm -q polkit > > polkit-0.112-5.el7.x86_64 > > > > $ sudo ls /etc/polkit-1/rules.d/ > > 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules > > > > $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules > > polkit.addAdminRule(function(action, subject) { > > return ["unix-group:admins", "unix-group:wheel"]; > > }); > > > > $ sudo ls /etc/polkit-1/localauthority.conf.d/ > > 40-custom.conf > > > > $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf > > [Configuration] > > AdminIdentities=unix-group:admins;unix-group:wheel > > > > $ ipa user-show martin | grep groups > > Member of groups: trust admins, ipausers, admins, ... > > > > Cockpit logs me in automatically using Kerberos (GSSAPI), but I > > can't > > perform administrative tasks, cannot see journald, etc. > > > > One thing that I thought to cause the issue is that pkexec is asking > > me > > select user first, instead of asking/not asking for password: > > $ pkexec cockpit-bridge > > ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === > > Authentication is needed to run `/usr/bin/cockpit-bridge' as the > > super > > user > > Multiple identities can be used for authentication: > > 1. Martin ?tefany (martin) > > 2. ... > > 3. ... > > Choose identity to authenticate as (1-3): 1 > > Password: > > ==== AUTHENTICATION COMPLETE === > > cockpit-bridge: no option specified > > > > and documentation claims that sudo / pkexec should not ask for > > password > > for particular user, but 1. I don't like that idea; 2. I have > > regular > > 1000:1000 user in wheel group for whom everything works just fine - > > sudo > > and pkexec ask for password as expected, and still in cockpit admin > > stuff works as expected. > > I have seen your answer in the ticket > https://fedorahosted.org/freeipa/ticket/3203#comment:6 > > Could you create a very short and concise how-to to > http://www.freeipa.org/page/HowTos , please? > > Your Fedora login should allow you to create a new wiki page and to > link it to > http://www.freeipa.org/page/HowTos . > > Thank you for your time! > Hello Petr, sure, done =) http://www.freeipa.org/page/Howto/FreeIPA_PolicyKit Thank you! Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5715 bytes Desc: not available URL: From urgrue at gmail.com Tue Oct 27 22:02:21 2015 From: urgrue at gmail.com (urgrue) Date: Tue, 27 Oct 2015 22:02:21 +0000 Subject: [Freeipa-users] Wrong time / constantly expired passwords In-Reply-To: <562FE286.4050401@redhat.com> References: <562FE286.4050401@redhat.com> Message-ID: Didn't realize it was GMT, so OK that's not the issue. Any suggestions on how to debug it? Everything looks OK, but passwords are just perma-expired at all times. On Tue, Oct 27, 2015, 21:45 Rob Crittenden wrote: > urgrue wrote: > > Hi, > > On a new install, I'm being forced a password reset on every login. Not > > sure why but this doesn't look right: > > > > # date > > Tue Oct 27 21:02:57 CET 2015 > > > > # ipa user-status blah1 > > > > Last successful authentication: 2015-10-27T19:34:53Z > > Last failed authentication: 2015-10-27T19:34:20Z > > Time now: 2015-10-27T20:03:00Z > > > > Where is it getting this wrong time from? > > What's wrong with the time? CET is one hour behind GMT right? That is > reflected by the difference between the output of date and "Time now". > > Passwords administratively reset must be set by the user during the > first authentication. If the password needs further reset then yeah, > something is wrong, but the above looks ok. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Wed Oct 28 00:27:11 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Tue, 27 Oct 2015 20:27:11 -0400 Subject: [Freeipa-users] IPA + Java 8 + S4U2Self/Proxy In-Reply-To: <562FDAAF.3050609@redhat.com> References: <562FCD54.2080702@redhat.com> <562FDAAF.3050609@redhat.com> Message-ID: Thanks Simo. It wouldn't surprise me that java's implementation is wrong. The comments in the source even ask if its necessary to check. Thanks Marc Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 On Tue, Oct 27, 2015 at 4:12 PM, Simo Sorce wrote: > On 27/10/15 15:43, Marc Boorshtein wrote: >>>> >>>> >>>> Looking at KrbKdcRep.java:73 it looks like the failure is happening >>>> because java is setting the forwardable flag to true on the request >>>> but the response has no options in it. Should the forwardable option >>>> be false in the request? >>> >>> >>> >>> That's a fair guess. >>> the whole point of constrained delegation (including protocol >>> impersonation) >>> is that you do not want to forward tickets, so you shouldn't ask for >>> forwardable tickets methinks. >>> >>> Simo. >>> >> >> Thanks Simio. I tried running kinit with forwarding disabled: >> >> $ kinit HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN -k -t >> ./unison-freeipa.keytab -F >> >> $ klist -f >> >> Ticket cache: FILE:/tmp/krb5cc_500 >> >> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >> >> >> Valid starting Expires Service principal >> >> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN >> >> Flags: IA >> >> But when I try again Java refuses to generate the ticket: >> >> tremoloadmin at unison-freeipa ~]$ klist -f >> Ticket cache: FILE:/tmp/krb5cc_500 >> Default principal: HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >> >> Valid starting Expires Service principal >> 10/27/15 15:32:52 10/28/15 15:32:52 krbtgt/RHELENT.LAN at RHELENT.LAN >> Flags: IA >> >> Hello World! >> Search Subject for Kerberos V5 INIT cred (<>, >> sun.security.jgss.krb5.Krb5InitCredential) >> No Subject >>>>> >>>>> KinitOptions cache name is /tmp/krb5cc_500 >>>>> DEBUG client principal is >>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>> DEBUG server principal is >>>>> krbtgt/RHELENT.LAN at RHELENT.LAN >>>>> DEBUG key type: 18 >>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>>> DEBUG renew_till time: null >>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>>> DEBUG client principal is >>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >> >> Java config name: /home/tremoloadmin/krb5.conf >> Loaded from Java config >>>>> >>>>> DEBUG server principal is >>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>>> DEBUG key type: 0 >>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>>> DEBUG start time: null >>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>>> DEBUG renew_till time: null >>>>> CCacheInputStream: readFlags() >> >> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to >> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT >> 2015 >> Search Subject for SPNEGO INIT cred (<>, >> sun.security.jgss.spnego.SpNegoCredElement) >> No Subject >> Search Subject for Kerberos V5 INIT cred (<>, >> sun.security.jgss.krb5.Krb5InitCredential) >> No Subject >>>>> >>>>> KinitOptions cache name is /tmp/krb5cc_500 >>>>> DEBUG client principal is >>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>> DEBUG server principal is >>>>> krbtgt/RHELENT.LAN at RHELENT.LAN >>>>> DEBUG key type: 18 >>>>> DEBUG auth time: Tue Oct 27 15:32:52 EDT 2015 >>>>> DEBUG start time: Tue Oct 27 15:32:52 EDT 2015 >>>>> DEBUG end time: Wed Oct 28 15:32:52 EDT 2015 >>>>> DEBUG renew_till time: null >>>>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; >>>>> DEBUG client principal is >>>>> HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN >>>>> DEBUG server principal is >>>>> X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/RHELENT.LAN at RHELENT.LAN@RHELENT.LAN >>>>> DEBUG key type: 0 >>>>> DEBUG auth time: Wed Dec 31 19:00:00 EST 1969 >>>>> DEBUG start time: null >>>>> DEBUG end time: Wed Dec 31 19:00:00 EST 1969 >>>>> DEBUG renew_till time: null >>>>> CCacheInputStream: readFlags() >> >> Found ticket for HTTP/unison-freeipa.rhelent.lan at RHELENT.LAN to go to >> krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Wed Oct 28 15:32:52 EDT >> 2015 >>>>> >>>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType >> >> Exception in thread "main" GSSException: Failure unspecified at >> GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials >> failed!) >> at >> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) >> at >> sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) >> at >> sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) >> at io.tremolo.App.main(App.java:27) >> Caused by: KrbException: Invalid option setting in ticket request. (101) >> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:165) >> at sun.security.krb5.KrbTgsReq.(KrbTgsReq.java:100) >> at >> sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:66) >> at >> sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) >> at >> sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) >> ... 3 more >> >> Looking at KrbTgsReq line 165: >> >> if (options.get(KDCOptions.FORWARDABLE) && >> (!(asCreds.flags.get(Krb5.TKT_OPTS_FORWARDABLE)))) { >> throw new KrbException(Krb5.KRB_AP_ERR_REQ_OPTIONS); >> } >> >> If I read this correctly it has to be forwardable? If thats the case >> is Java wrong for requiring the options to be there or is ipa wrong >> for not sending the options with the response ticket? > > > I think the best answer would be to look at what the MIT test program does > and make sure Java does the same. > This stuff works with the native libraries and is interoperable with Windows > AD KDCs where the specification was born. > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York From craig.linux at mypenguin.net.au Wed Oct 28 02:32:23 2015 From: craig.linux at mypenguin.net.au (craig.linux at mypenguin.net.au) Date: Wed, 28 Oct 2015 13:32:23 +1100 Subject: [Freeipa-users] anonymous LDAP attributes with IPA ipa-server-4.1 Message-ID: <20151028023223.GB16680@mypenguin.net.au> Hi, We have recently updated from IPA 3 to IPA 4.1 and one of the changes in security is what attributes are available for the anonymous LDAP queries. Does anyone know how to edit the anonymous LDAP settings so that the following are available? mail: craig at example.com postalCode: 3000 street: 1 Home Parade mobile: 0000-000-000 telephoneNumber: 03-0000-0000 Note: We have many different types of LDAP clients here and even though using encrypted BIND's did work from ldapsearch queries, I couldn't get them to consistently work from our email clients. Regards, Craig From prashant at apigee.com Wed Oct 28 05:41:23 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 28 Oct 2015 11:11:23 +0530 Subject: [Freeipa-users] anonymous LDAP attributes with IPA ipa-server-4.1 In-Reply-To: <20151028023223.GB16680@mypenguin.net.au> References: <20151028023223.GB16680@mypenguin.net.au> Message-ID: Making attributes anonymously readable is very simple. You need to look into RBAC and define the permissions/privileges you need. On 28 October 2015 at 08:02, wrote: > Hi, > > We have recently updated from IPA 3 to IPA 4.1 and one of the changes in > security is what attributes are available for the anonymous LDAP > queries. > > Does anyone know how to edit the anonymous LDAP settings so > that the following are available? > > mail: craig at example.com > postalCode: 3000 > street: 1 Home Parade > mobile: 0000-000-000 > telephoneNumber: 03-0000-0000 > > Note: We have many different types of LDAP clients here and even though > using encrypted BIND's did work from ldapsearch queries, I couldn't get > them to consistently work from our email clients. > > Regards, > > Craig > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Wed Oct 28 05:48:29 2015 From: prashant at apigee.com (Prashant Bapat) Date: Wed, 28 Oct 2015 11:18:29 +0530 Subject: [Freeipa-users] anonymous LDAP attributes with IPA ipa-server-4.1 In-Reply-To: References: <20151028023223.GB16680@mypenguin.net.au> Message-ID: ?Refer this doc https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#server-access-controls ? On 28 October 2015 at 11:11, Prashant Bapat wrote: > Making attributes anonymously readable is very simple. You need to look > into RBAC and define the permissions/privileges you need. > > On 28 October 2015 at 08:02, wrote: > >> Hi, >> >> We have recently updated from IPA 3 to IPA 4.1 and one of the changes in >> security is what attributes are available for the anonymous LDAP >> queries. >> >> Does anyone know how to edit the anonymous LDAP settings so >> that the following are available? >> >> mail: craig at example.com >> postalCode: 3000 >> street: 1 Home Parade >> mobile: 0000-000-000 >> telephoneNumber: 03-0000-0000 >> >> Note: We have many different types of LDAP clients here and even though >> using encrypted BIND's did work from ldapsearch queries, I couldn't get >> them to consistently work from our email clients. >> >> Regards, >> >> Craig >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitra.dehghan at gmail.com Wed Oct 28 05:32:26 2015 From: mitra.dehghan at gmail.com (mitra dehghan) Date: Wed, 28 Oct 2015 09:02:26 +0330 Subject: [Freeipa-users] Sync IPA and AD while using external CA Message-ID: hello, I want to implement and IPA server and Sync it with my 2012 ms ad. While things go well using an internal CA in each server, I came across kind of problem when I want integrate solution with my PKI which is already serving the AD server. I can install IPA with --external-ca switch. but when it comes to Sync. agreement it says "TLS error -8179:Peer's Certificate issuer is not recognized." The architecture is: - There is a root CA named contoso.com - There is a subordinate CA named local.dc - The certificates of AD and IPA server are both issued by local.dc - IPA's certificate is issued based on the CSR file generated by ipa-server-install - I have copied both certificates in /etc/openldap/certs directory and the rest was same as what i did in the internal CA scenario. while the FreeIPA docs say both servers must have internal CA's i need to integrate solution with available PKI. I would be glad hear suggestions if this scenario is applicable and what is wrong there. thank you -- m-dehghan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Oct 28 08:07:24 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 28 Oct 2015 09:07:24 +0100 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <1445976510.2763.22.camel@stefany.eu> References: <1445376356.31026.15.camel@stefany.eu> <20151021073253.GH3084@hendrix.redhat.com> <1445976510.2763.22.camel@stefany.eu> Message-ID: <20151028080724.GA3480@hendrix> On Tue, Oct 27, 2015 at 09:08:30PM +0100, Martin ?tefany wrote: > On St, 2015-10-21 at 09:32 +0200, Jakub Hrozek wrote: > > On Tue, Oct 20, 2015 at 11:25:56PM +0200, Martin ?tefany wrote: > > > Hello, > > > > > > did anybody manage to get FreeIPA admin user (member of admins > > > group, > > > full sudo access, etc.) to be also Cockpit user with administrative > > > privileges? I've already figured out that it's closely related to > > > Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... > > > I > > > was not able to get a working configuration. > > > > > > Some version / configuration details: > > > $ cat /etc/centos-release > > > CentOS Linux release 7.1.1503 (Core) > > > > > > $ rpm -q ipa-client > > > ipa-client-4.1.0-18.el7.centos.4.x86_64 > > > > > > $ rpm -q cockpit # from sgallagh's COPR repository > > > cockpit-0.80-1.el7.centos.x86_64 > > > > > > $ rpm -q polkit > > > polkit-0.112-5.el7.x86_64 > > > > > > $ sudo ls /etc/polkit-1/rules.d/ > > > 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules > > > > > > $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules > > > polkit.addAdminRule(function(action, subject) { > > > return ["unix-group:admins", "unix-group:wheel"]; > > > }); > > > > > > $ sudo ls /etc/polkit-1/localauthority.conf.d/ > > > 40-custom.conf > > > > > > $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf > > > [Configuration] > > > AdminIdentities=unix-group:admins;unix-group:wheel > > > > > > $ ipa user-show martin | grep groups > > > Member of groups: trust admins, ipausers, admins, ... > > > > > > Cockpit logs me in automatically using Kerberos (GSSAPI), but I > > > can't > > > perform administrative tasks, cannot see journald, etc. > > > > > > One thing that I thought to cause the issue is that pkexec is asking > > > me > > > select user first, instead of asking/not asking for password: > > > $ pkexec cockpit-bridge > > > ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === > > > Authentication is needed to run `/usr/bin/cockpit-bridge' as the > > > super > > > user > > > Multiple identities can be used for authentication: > > > 1. Martin ?tefany (martin) > > > 2. ... > > > 3. ... > > > Choose identity to authenticate as (1-3): 1 > > > Password: > > > ==== AUTHENTICATION COMPLETE === > > > cockpit-bridge: no option specified > > > > > > and documentation claims that sudo / pkexec should not ask for > > > password > > > for particular user, but 1. I don't like that idea; 2. I have > > > regular > > > 1000:1000 user in wheel group for whom everything works just fine - > > > sudo > > > and pkexec ask for password as expected, and still in cockpit admin > > > stuff works as expected. > > > > Can you add the admin user to the wheel group on the Cockpit machine? > > > > But in general I think you're looking for: > > https://sourceware.org/glibc/wiki/Proposals/GroupMerging > > first round of patches is ready, although it still needs to go through > > upstream review (IIRC). > > > > Hello Jakub, > > adding specific user to local wheel group works, thank you. But it also > requires local intervention on the system(s), and on per-user basis. > > Only limitation detail I see now with PolicyKit is that user is granted > full admin rights via pkexec either when custom /etc/polkit-1/rules.d/40 > -freeipa.rules is defined or when glibc group merging is merged. If I > understand https://fedorahosted.org/freeipa/ticket/5350 correctly, this > will be sort-of addressed based on hostgroups, but it will still give > more control over the system than sudo would do, won't it? You'd get all the rights that the wheel group gives you. IPA #5350 also describes merging of a different group into local wheel/adm, but that's not implemented yet. From s.kieske at mittwald.de Wed Oct 28 13:06:37 2015 From: s.kieske at mittwald.de (Sven Kieske) Date: Wed, 28 Oct 2015 14:06:37 +0100 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <5627A93D.7070703@redhat.com> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5627A93D.7070703@redhat.com> Message-ID: <5630C85D.6000402@mittwald.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 21/10/15 17:03, Ludwig Krispenz wrote: > It looks like it is accessing memory, which was freed in a > pre-bind plugin, this could be the issue tracked in > https://fedorahosted.org/389/ticket/48188 are you sure that we hit this bug or might it also be something else? - -- Mit freundlichen Gr??en / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K?nigsberger Stra?e 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch?ftsf?hrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus en Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWMMhdAAoJEMby9TMDAbQRJMMP/1ViLN5epfxEeqQnAYJ0t77Z EYgJr+2QeBFswosv1xKwAXnY2/fUjyArwgHjg7RnIlm7QSE7bYg9mOI/hOu62Ya5 pXIMIjmlO8HFpx/9xKyfYHkfUX9Q5opYDkmTv9WiqQSc4Iw7yFl41P99GLEdGKtB sVtNeuhJnsHx6WjJ2VgESSzGEPnUHHsGtmKqgHKAvFo9uaNdHosSLy/zdOVSljdD J+gEbPTWS5ngaLTsRSOhttGuaWX/BPiNEzw9S+yas+/PZeutD08bgOPtLtKjqnAu PYk9NrYqTQu1UYMu1x1ZnZ0EzuyJ06ZSdStB3Mb9r4QloMWhCdhsYaZKjs+SNCvE dBGzpJ8Cst52jBEGeDSG34GqkVh7oXjl4veL+Fl2SamLV1wpDCUT+TpExO3wzEo3 WoGzpxah1MGn1QAFFYXwq6WDX1rZgniwreQ08dBgzKkjQ0kaFxy8taQzxgc4cTTx 9fRPrS/NtUcC98Wb58pRZpFtF4Pc+dj3IPofQpdRDoF3wjTkOKcUVsbazDWPrNJf Pxv1sJeEMZcuQQ1FxmWu66v/+1wSgoHeUsTkqXpb8sfA/9szxmEsIBFJjudUKF8/ 2HwrQe1ofNsRXWtMAM47+7gC1BC86P+tjaMnl7/5xXRDFt92RJB4vCiuN+jf8TJC pDqMV0GXr2bO5tAxvbka =Nv3u -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Oct 28 13:44:38 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Oct 2015 09:44:38 -0400 Subject: [Freeipa-users] Wrong time / constantly expired passwords In-Reply-To: References: <562FE286.4050401@redhat.com> Message-ID: <5630D146.9040300@redhat.com> urgrue wrote: > Didn't realize it was GMT, so OK that's not the issue. Any suggestions > on how to debug it? Everything looks OK, but passwords are just > perma-expired at all times. Need more info on what you're seeing and how the passwords are being changed. rob > > > On Tue, Oct 27, 2015, 21:45 Rob Crittenden > wrote: > > urgrue wrote: > > Hi, > > On a new install, I'm being forced a password reset on every > login. Not > > sure why but this doesn't look right: > > > > # date > > Tue Oct 27 21:02:57 CET 2015 > > > > # ipa user-status blah1 > > > > Last successful authentication: 2015-10-27T19:34:53Z > > Last failed authentication: 2015-10-27T19:34:20Z > > Time now: 2015-10-27T20:03:00Z > > > > Where is it getting this wrong time from? > > What's wrong with the time? CET is one hour behind GMT right? That is > reflected by the difference between the output of date and "Time now". > > Passwords administratively reset must be set by the user during the > first authentication. If the password needs further reset then yeah, > something is wrong, but the above looks ok. > > rob > From rcritten at redhat.com Wed Oct 28 13:50:46 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Oct 2015 09:50:46 -0400 Subject: [Freeipa-users] Sync IPA and AD while using external CA In-Reply-To: References: Message-ID: <5630D2B6.7080506@redhat.com> mitra dehghan wrote: > hello, > I want to implement and IPA server and Sync it with my 2012 ms ad. While > things go well using an internal CA in each server, I came across kind > of problem when I want integrate solution with my PKI which is already > serving the AD server. > I can install IPA with --external-ca switch. but when it comes to Sync. > agreement it says "TLS error -8179:Peer's Certificate issuer is not > recognized." > > The architecture is: > - There is a root CA named contoso.com > - There is a subordinate CA named local.dc > - The certificates of AD and IPA server are both issued by local.dc > - IPA's certificate is issued based on the CSR file generated by > ipa-server-install > - I have copied both certificates in /etc/openldap/certs directory and > the rest was same as what i did in the internal CA scenario. > > while the FreeIPA docs say both servers must have internal CA's i need > to integrate solution with available PKI. > I would be glad hear suggestions if this scenario is applicable and what > is wrong there. > thank you 389-ds doesn't use /etc/openldap/certs. What cert are you passing in when creating the winsync agreement using ipa-replica-manage? You may need/want to add these certs to the IPA 389-ds NSS database prior to setting up the agreement. rob From wdh at dds.nl Wed Oct 28 16:05:49 2015 From: wdh at dds.nl (Winfried de Heiden) Date: Wed, 28 Oct 2015 17:05:49 +0100 Subject: [Freeipa-users] rest api Message-ID: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> Hi all, In order for an external application to communicate with IPA and/or modify on (free)Ipa, we want to use the JSON API. Where can I find documentation how to use this API? Thankz! Winny -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 28 16:12:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Oct 2015 12:12:16 -0400 Subject: [Freeipa-users] rest api In-Reply-To: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> References: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> Message-ID: <5630F3E0.8030103@redhat.com> Winfried de Heiden wrote: > Hi all, > > In order for an external application to communicate with IPA and/or > modify on (free)Ipa, we want to use the JSON API. > > Where can I find documentation how to use this API? > > Thankz! > > Winny > > IPA doesn't use REST. You can get an idea about how to use the API at https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ If you add the -vv option to the ipa command-line you can see the API in action: % ipa -vv user-show admin rob From abokovoy at redhat.com Wed Oct 28 16:13:59 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 28 Oct 2015 18:13:59 +0200 Subject: [Freeipa-users] rest api In-Reply-To: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> References: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> Message-ID: <20151028161359.GB4627@redhat.com> On Wed, 28 Oct 2015, Winfried de Heiden wrote: >Hi all, > > In order for an external application to communicate with IPA and/or modify >on (free)Ipa, we want to use the JSON API. > > Where can I find documentation how to use this API? Read my blog post: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ FreeIPA 4.2 includes an API browser in Web UI. -- / Alexander Bokovoy From james.masson at jmips.co.uk Wed Oct 28 16:36:45 2015 From: james.masson at jmips.co.uk (James Masson) Date: Wed, 28 Oct 2015 16:36:45 +0000 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <562E509A.8030506@redhat.com> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> Message-ID: <5630F99D.2080402@jmips.co.uk> On 26/10/15 16:11, Martin Kosek wrote: > On 10/26/2015 04:05 PM, James Masson wrote: >> >> >> On 19/10/15 21:06, Rob Crittenden wrote: >>> James Masson wrote: >>>> >>>> Hi list, >>>> >>>> I successfully have IPA working with CA certs signed by an upstream Dogtag. >>>> >>>> Now I'm trying to use a CA cert signed by a different type of CA - Vault. >>>> >>>> Setup fails, using the same 2 step IPA setup process as used with >>>> upstream Dogtag. I've also tried the external-ca-type option. >>>> >>>> Likely, IPA doesn't like the certificate - however, I can't pinpoint why. >>> >>> I'm guessing you don't include the entire CA certchain of Vault. Dogtag >>> is failing to startup because it can't verify its own cert chain: >>> >>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>> CAPresence: CA is present >>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>> SystemCertsVerification: system certs verification failure >>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>> SelfTestSubsystem: The CRITICAL self test plugin called >>> selftests.container.instance.SystemCertsVerification running at startup >>> FAILED! >>> >>> rob >>> >> >> >> Hi Rob, >> >> Thanks for the reply. >> >> I do present the IPA installer with both the CA and the IPA cert - the IPAs >> python-based install code is happy with the cert chain, but the Java based >> dogtag code chokes on it. >> >> OpenSSL is happy with it too. >> >> ##### >> [root at foo ~]# openssl verify ipa.crt >> ipa.crt: O = LOCAL, CN = Certificate Authority >> error 20 at 0 depth lookup:unable to get local issuer certificate >> >> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >> ipa.crt: OK >> ### >> >> Any hints on how to reproduce this with more debug output? I'd like to know >> exactly what Dogtag doesn't like about the certificate. >> >> thanks >> >> James M > > Let me CC at least Jan Ch. and David, they may be able to help and should also > make sure FreeIPA gets better in validating the certs, as appropriate. > Any thoughts guys? James M From urgrue at gmail.com Wed Oct 28 18:15:29 2015 From: urgrue at gmail.com (urgrue) Date: Wed, 28 Oct 2015 19:15:29 +0100 Subject: [Freeipa-users] Wrong time / constantly expired passwords In-Reply-To: <5630D146.9040300@redhat.com> References: <562FE286.4050401@redhat.com> <5630D146.9040300@redhat.com> Message-ID: Here are some examples: [root at mule ~]# ipa user-status freddie ----------------------- Account disabled: False ----------------------- Server: mule.bulb Failed logins: 0 Last successful authentication: 2015-10-28T09:03:48Z Last failed authentication: 2015-10-28T09:03:40Z Time now: 2015-10-28T18:05:51Z ---------------------------- Number of entries returned 1 ---------------------------- [root at mule ~]# ipa user-show freddie User login: freddie First name: fred Last name: orispaa Home directory: /home/freddie Login shell: /bin/sh UID: 50001 GID: 50001 Account disabled: False Password: True Member of groups: admins, ipausers Indirect Member of Sudo rule: allow_all Kerberos keys available: True SSH public key fingerprint: DA:54:C4:27:3A:23:00:AE:AE:60:B7:1B:E1:E4:03:C5 freddie at mule (ssh-rsa) With SSH: [root at mule ~]$ ssh freddie at mule freddie at mule's password: Password expired. Change your password now. Last login: Wed Oct 28 10:03:44 2015 from 127.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user freddie. Current Password: New password: Retype new password: passwd: Authentication token is no longer valid; new one required Connection to mule closed. (Now if I login again, the same process repeats, except the password has indeed changes) With su the output is less informative: [jj at mule ~]$ su - freddie Password: Password expired. Change your password now. Current Password: New password: Retype new password: su: incorrect password (the password was correct and it HAS changed even though the output implies I entered the wrong current password). Doing kinit: -sh-4.1$ id uid=50001(freddie) gid=50001(freddie) groups=50001(freddie),50000(admins) -sh-4.1$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_50001) -sh-4.1$ kinit Password for freddie at BULB: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials -sh-4.1$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_50001) (again the password HAS changed) In case it's of any relevance, note that root has no issue with kerberos credentials: [root at mule ~]# kinit admin Password for admin at BULB: [root at mule ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at BULB Valid starting Expires Service principal 10/28/15 19:14:56 10/29/15 19:14:53 krbtgt/BULB at BULB On Wed, Oct 28, 2015 at 2:44 PM, Rob Crittenden wrote: > urgrue wrote: > > Didn't realize it was GMT, so OK that's not the issue. Any suggestions > > on how to debug it? Everything looks OK, but passwords are just > > perma-expired at all times. > > Need more info on what you're seeing and how the passwords are being > changed. > > rob > > > > > > > On Tue, Oct 27, 2015, 21:45 Rob Crittenden > > wrote: > > > > urgrue wrote: > > > Hi, > > > On a new install, I'm being forced a password reset on every > > login. Not > > > sure why but this doesn't look right: > > > > > > # date > > > Tue Oct 27 21:02:57 CET 2015 > > > > > > # ipa user-status blah1 > > > > > > Last successful authentication: 2015-10-27T19:34:53Z > > > Last failed authentication: 2015-10-27T19:34:20Z > > > Time now: 2015-10-27T20:03:00Z > > > > > > Where is it getting this wrong time from? > > > > What's wrong with the time? CET is one hour behind GMT right? That is > > reflected by the difference between the output of date and "Time > now". > > > > Passwords administratively reset must be set by the user during the > > first authentication. If the password needs further reset then yeah, > > something is wrong, but the above looks ok. > > > > rob > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.linux at mypenguin.net.au Wed Oct 28 23:06:15 2015 From: craig.linux at mypenguin.net.au (craig.linux at mypenguin.net.au) Date: Thu, 29 Oct 2015 10:06:15 +1100 Subject: [Freeipa-users] anonymous LDAP attributes with IPA ipa-server-4.1 In-Reply-To: References: <20151028023223.GB16680@mypenguin.net.au> Message-ID: <20151028230615.GA26656@mypenguin.net.au> Thanks it worked! For those also intersted in the settings; Permission: ldap_anonymous Bind Type Rule: anonymous Granted Rights: (I used) "read","search","compare" Subtree: cn=users,cn=accounts,dc=example,dc=com Extra target filter: (&(objectclass=Person)(|(uid=*)(givenName=*))) Target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com Effective Attributes: gecos, mail, mobile, telephoneNumber, uidNumber cheers, Craig On Wed, Oct 28, 2015 at 11:18:29AM +0530, Prashant Bapat wrote: > ?Refer this doc > [1]https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#server-access-controls? > On 28 October 2015 at 11:11, Prashant Bapat <[2]prashant at apigee.com> > wrote: > > Making attributes anonymously readable is very simple. You need to look > into RBAC and define the permissions/privileges you need.? > On 28 October 2015 at 08:02, <[3]craig.linux at mypenguin.net.au> wrote: > > Hi, > > We have recently updated from IPA 3 to IPA 4.1 and one of the changes > in > security is what attributes are available for the anonymous LDAP > queries. > > Does anyone know how to edit the anonymous LDAP settings so > that the following are available? > > mail: [4]craig at example.com > postalCode: 3000 > street: 1 Home Parade > mobile: 0000-000-000 > telephoneNumber: 03-0000-0000 > > Note: We have many different types of LDAP clients here and even > though > using encrypted BIND's did work from ldapsearch queries, I couldn't > get > them to consistently work from our email clients. > > Regards, > > Craig > -- > Manage your subscription for the Freeipa-users mailing list: > [5]https://www.redhat.com/mailman/listinfo/freeipa-users > Go to [6]http://freeipa.org for more info on the project > > References > > Visible links > 1. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#server-access-controls > 2. mailto:prashant at apigee.com > 3. mailto:craig.linux at mypenguin.net.au > 4. mailto:craig at example.com > 5. https://www.redhat.com/mailman/listinfo/freeipa-users > 6. http://freeipa.org/ From lkrispen at redhat.com Thu Oct 29 08:48:59 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 29 Oct 2015 09:48:59 +0100 Subject: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts In-Reply-To: <5630C85D.6000402@mittwald.de> References: <560D4BFA.2040303@mittwald.de> <560D8EE7.8080004@redhat.com> <5627A93D.7070703@redhat.com> <5630C85D.6000402@mittwald.de> Message-ID: <5631DD7B.6090807@redhat.com> On 10/28/2015 02:06 PM, Sven Kieske wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On 21/10/15 17:03, Ludwig Krispenz wrote: >> It looks like it is accessing memory, which was freed in a >> pre-bind plugin, this could be the issue tracked in >> https://fedorahosted.org/389/ticket/48188 > are you sure that we hit this bug or might it also be something else? I have no proof, but from what I see in the data I think it very likely this issue. > > - -- > Mit freundlichen Gr??en / Regards > > Sven Kieske > > Systemadministrator > Mittwald CM Service GmbH & Co. KG > K?nigsberger Stra?e 6 > 32339 Espelkamp > T: +495772 293100 > F: +495772 293333 > https://www.mittwald.de > Gesch?ftsf?hrer: Robert Meyer > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhaus > en > Komplement?rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad > Oeynhausen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBAgAGBQJWMMhdAAoJEMby9TMDAbQRJMMP/1ViLN5epfxEeqQnAYJ0t77Z > EYgJr+2QeBFswosv1xKwAXnY2/fUjyArwgHjg7RnIlm7QSE7bYg9mOI/hOu62Ya5 > pXIMIjmlO8HFpx/9xKyfYHkfUX9Q5opYDkmTv9WiqQSc4Iw7yFl41P99GLEdGKtB > sVtNeuhJnsHx6WjJ2VgESSzGEPnUHHsGtmKqgHKAvFo9uaNdHosSLy/zdOVSljdD > J+gEbPTWS5ngaLTsRSOhttGuaWX/BPiNEzw9S+yas+/PZeutD08bgOPtLtKjqnAu > PYk9NrYqTQu1UYMu1x1ZnZ0EzuyJ06ZSdStB3Mb9r4QloMWhCdhsYaZKjs+SNCvE > dBGzpJ8Cst52jBEGeDSG34GqkVh7oXjl4veL+Fl2SamLV1wpDCUT+TpExO3wzEo3 > WoGzpxah1MGn1QAFFYXwq6WDX1rZgniwreQ08dBgzKkjQ0kaFxy8taQzxgc4cTTx > 9fRPrS/NtUcC98Wb58pRZpFtF4Pc+dj3IPofQpdRDoF3wjTkOKcUVsbazDWPrNJf > Pxv1sJeEMZcuQQ1FxmWu66v/+1wSgoHeUsTkqXpb8sfA/9szxmEsIBFJjudUKF8/ > 2HwrQe1ofNsRXWtMAM47+7gC1BC86P+tjaMnl7/5xXRDFt92RJB4vCiuN+jf8TJC > pDqMV0GXr2bO5tAxvbka > =Nv3u > -----END PGP SIGNATURE----- > From pspacek at redhat.com Thu Oct 29 08:48:44 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 Oct 2015 09:48:44 +0100 Subject: [Freeipa-users] Cockpit with (Free)IPA admin users In-Reply-To: <1445981169.2763.23.camel@stefany.eu> References: <1445376356.31026.15.camel@stefany.eu> <562F8EA5.5090207@redhat.com> <1445981169.2763.23.camel@stefany.eu> Message-ID: <5631DD6C.5040000@redhat.com> Thank you very much! Petr^2 Spacek On 27.10.2015 22:26, Martin ?tefany wrote: > On Ut, 2015-10-27 at 15:48 +0100, Petr Spacek wrote: >> On 20.10.2015 23:25, Martin ?tefany wrote: >>> Hello, >>> >>> did anybody manage to get FreeIPA admin user (member of admins >>> group, >>> full sudo access, etc.) to be also Cockpit user with administrative >>> privileges? I've already figured out that it's closely related to >>> Polkit, but since FreeIPA and Polkit are not fully 'friendly' yet... >>> I >>> was not able to get a working configuration. >>> >>> Some version / configuration details: >>> $ cat /etc/centos-release >>> CentOS Linux release 7.1.1503 (Core) >>> >>> $ rpm -q ipa-client >>> ipa-client-4.1.0-18.el7.centos.4.x86_64 >>> >>> $ rpm -q cockpit # from sgallagh's COPR repository >>> cockpit-0.80-1.el7.centos.x86_64 >>> >>> $ rpm -q polkit >>> polkit-0.112-5.el7.x86_64 >>> >>> $ sudo ls /etc/polkit-1/rules.d/ >>> 40-freeipa.rules 49-polkit-pkla-compat.rules 50-default.rules >>> >>> $ sudo cat /etc/polkit-1/rules.d/40-freeipa.rules >>> polkit.addAdminRule(function(action, subject) { >>> return ["unix-group:admins", "unix-group:wheel"]; >>> }); >>> >>> $ sudo ls /etc/polkit-1/localauthority.conf.d/ >>> 40-custom.conf >>> >>> $ sudo cat /etc/polkit-1/localauthority.conf.d/40-custom.conf >>> [Configuration] >>> AdminIdentities=unix-group:admins;unix-group:wheel >>> >>> $ ipa user-show martin | grep groups >>> Member of groups: trust admins, ipausers, admins, ... >>> >>> Cockpit logs me in automatically using Kerberos (GSSAPI), but I >>> can't >>> perform administrative tasks, cannot see journald, etc. >>> >>> One thing that I thought to cause the issue is that pkexec is asking >>> me >>> select user first, instead of asking/not asking for password: >>> $ pkexec cockpit-bridge >>> ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === >>> Authentication is needed to run `/usr/bin/cockpit-bridge' as the >>> super >>> user >>> Multiple identities can be used for authentication: >>> 1. Martin ?tefany (martin) >>> 2. ... >>> 3. ... >>> Choose identity to authenticate as (1-3): 1 >>> Password: >>> ==== AUTHENTICATION COMPLETE === >>> cockpit-bridge: no option specified >>> >>> and documentation claims that sudo / pkexec should not ask for >>> password >>> for particular user, but 1. I don't like that idea; 2. I have >>> regular >>> 1000:1000 user in wheel group for whom everything works just fine - >>> sudo >>> and pkexec ask for password as expected, and still in cockpit admin >>> stuff works as expected. >> >> I have seen your answer in the ticket >> https://fedorahosted.org/freeipa/ticket/3203#comment:6 >> >> Could you create a very short and concise how-to to >> http://www.freeipa.org/page/HowTos , please? >> >> Your Fedora login should allow you to create a new wiki page and to >> link it to >> http://www.freeipa.org/page/HowTos . >> >> Thank you for your time! >> > > Hello Petr, > > sure, done =) > > http://www.freeipa.org/page/Howto/FreeIPA_PolicyKit > > Thank you! > > Martin > -- Petr Spacek @ Red Hat From yks0000 at gmail.com Thu Oct 29 10:33:43 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 29 Oct 2015 16:03:43 +0530 Subject: [Freeipa-users] Multiple Reverse (PTR) Zone Message-ID: Hi, We are working on to create another DC and extending our existing FreeIPA. Our current environment has subnet as 172.16.32.0/16. In another DC we have 10.242.96.0/20. On FreeIPA master I have created a PTR Zone with 242.10.in-addr.arpa. , However, on registering the DC2 Client with FreeIPA Master it says "Hostname not found in DNS" Our Domain is same across DC, the only change is Subnet. Forward Zone is working fine. Below are Regestration Logs: [root at dr-ipadns-1002 ~]# ipa-client-install --mkhomedir --no-ntp Discovery was successful! Hostname: dr-ipadns-1002.klikpay.int Realm: KLIKPAY.INT DNS Domain: klikpay.int IPA Server: ipa-inf-prd-ng2-02.klikpay.int BaseDN: dc=klikpay,dc=int Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at KLIKPAY.INT: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=KLIKPAY.INT Issuer: CN=Certificate Authority,O=KLIKPAY.INT Valid From: Fri Aug 14 11:39:47 2015 UTC Valid Until: Tue Aug 14 11:39:47 2035 UTC Enrolled in IPA realm KLIKPAY.INT Attempting to get host TGT... Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm KLIKPAY.INT trying https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml Forwarding 'env' to server u'https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' *Hostname (dr-ipadns-1002.klikpay.int ) not found in DNS* Failed to update DNS records. Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Forwarding 'host_mod' to server u' https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' SSSD enabled Configuring klikpay.int as NIS domain Configured /etc/openldap/ldap.conf Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Client configuration complete. [root at dr-ipadns-1002 ~]# ip r 10.242.96.0/20 dev eth0 proto kernel scope link src 10.242.96.3 169.254.0.0/16 dev eth0 scope link metric 1002 default via 10.242.96.1 dev eth0 [root at dr-ipadns-1002 ~]# >From IPA: [root at ipa-inf-prd-ng2-01 ~]# ipa dnszone-show 242.10.in-addr.arpa Zone name: 242.10.in-addr.arpa. Active zone: TRUE Authoritative nameserver: ipa-inf-prd-ng2-01.klikpay.int. Administrator e-mail address: hostmaster SOA serial: 1446111284 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root at ipa-inf-prd-ng2-01 ~]# Please suggest as what I am missing. *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Oct 29 12:03:36 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 Oct 2015 13:03:36 +0100 Subject: [Freeipa-users] Multiple Reverse (PTR) Zone In-Reply-To: References: Message-ID: <56320B18.3090106@redhat.com> On 29.10.2015 11:33, Yogesh Sharma wrote: > Hi, > > We are working on to create another DC and extending our existing FreeIPA. > > Our current environment has subnet as 172.16.32.0/16. In another DC we have > 10.242.96.0/20. > > On FreeIPA master I have created a PTR Zone with 242.10.in-addr.arpa. , > However, on registering the DC2 Client with FreeIPA Master it says > "Hostname not found in DNS" This message tells you that "hostname" (i.e. what you see in output of command "hostname") does not have A/AAAA record in DNS. It has nothing to do with PTR records. Message "Failed to update DNS records." is usually caused by misconfigured DNS zones. Please see https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR for advice how to configure DNS zones to accept dynamic updates. I hope this helps. Petr^2 Spacek > Our Domain is same across DC, the only change is Subnet. > > Forward Zone is working fine. > > > Below are Regestration Logs: > > [root at dr-ipadns-1002 ~]# ipa-client-install --mkhomedir --no-ntp > Discovery was successful! > Hostname: dr-ipadns-1002.klikpay.int > Realm: KLIKPAY.INT > DNS Domain: klikpay.int > IPA Server: ipa-inf-prd-ng2-02.klikpay.int > BaseDN: dc=klikpay,dc=int > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at KLIKPAY.INT: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=KLIKPAY.INT > Issuer: CN=Certificate Authority,O=KLIKPAY.INT > Valid From: Fri Aug 14 11:39:47 2015 UTC > Valid Until: Tue Aug 14 11:39:47 2035 UTC > > Enrolled in IPA realm KLIKPAY.INT > Attempting to get host TGT... > Created /etc/ipa/default.conf > New SSSD config will be created > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm KLIKPAY.INT > trying https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml > Forwarding 'env' to server u'https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' > *Hostname (dr-ipadns-1002.klikpay.int ) > not found in DNS* > Failed to update DNS records. > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to server u' > https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' > SSSD enabled > Configuring klikpay.int as NIS domain > Configured /etc/openldap/ldap.conf > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Client configuration complete. > > [root at dr-ipadns-1002 ~]# ip r > 10.242.96.0/20 dev eth0 proto kernel scope link src 10.242.96.3 > 169.254.0.0/16 dev eth0 scope link metric 1002 > default via 10.242.96.1 dev eth0 > [root at dr-ipadns-1002 ~]# > > >>From IPA: > > [root at ipa-inf-prd-ng2-01 ~]# ipa dnszone-show 242.10.in-addr.arpa > Zone name: 242.10.in-addr.arpa. > Active zone: TRUE > Authoritative nameserver: ipa-inf-prd-ng2-01.klikpay.int. > Administrator e-mail address: hostmaster > SOA serial: 1446111284 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > Allow query: any; > Allow transfer: none; > [root at ipa-inf-prd-ng2-01 ~]# > > > > Please suggest as what I am missing. -- Petr^2 Spacek From th at casalogic.dk Thu Oct 29 13:11:09 2015 From: th at casalogic.dk (Troels Hansen) Date: Thu, 29 Oct 2015 14:11:09 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> Message-ID: <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> Hmm, weird. I ran ipa-adtrust-install and it says it said it had user without SID's, and I told it to generete SID's. However, I still can't see them on the user. a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. ldapsearch -Y GSSAPI uid=th ipaNTHash ....... # th, users, compat, casalogic.lan dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan # th, users, accounts, casalogic.lan dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan ..... Samba however starts fine now, but unable to find any users: pdbedit -Lv pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll wrote: > To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the > ipa-adtrust-install --add-sids, even though I was not setting up a trust. It > would be nice if there was a way to generate these values another way, maybe > there is but I missed it. > --Joshua D Doll > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Oct 29 14:26:04 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 Oct 2015 15:26:04 +0100 Subject: [Freeipa-users] FreeIPA public demo upgraded to version 4.2 Message-ID: <56322C7C.4060600@redhat.com> Hello everyone, The FreeIPA Public Demo [1] was upgraded from version 4.1 to 4.2.2, running on Fedora 23. Please feel free to try all the new and shiny features, from Certificate Profiles or User Certificates to new User Life Cycle Management or API Browser. To see the full list of changes, you can see the FreeIPA 4.2.0 release notes [2]. To see a more condensed view on what is new, you can also see the article I wrote for Red Hat Portal (open to public) [3]. Enjoy! Please let me know if you have any suggestions for the demo or issues playing with it. Thank you! [1] http://www.freeipa.org/page/Demo [2] http://www.freeipa.org/page/Releases/4.2.0 [3] https://access.redhat.com/solutions/1986213 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From joshua.doll at gmail.com Thu Oct 29 14:27:53 2015 From: joshua.doll at gmail.com (Joshua Doll) Date: Thu, 29 Oct 2015 14:27:53 +0000 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> Message-ID: Are you using the correct principal for the ldapsearch? Did you grant it permissions to view those attributes? --Joshua D Doll On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen wrote: > Hmm, weird. > I ran ipa-adtrust-install and it says it said it had user without SID's, > and I told it to generete SID's. > However, I still can't see them on the user. > a IPA-db doesn't reveal them being generated and I can't look them up via > LDAP. > > ldapsearch -Y GSSAPI uid=th ipaNTHash > ....... > # th, users, compat, casalogic.lan > dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > # th, users, accounts, casalogic.lan > dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > ..... > > Samba however starts fine now, but unable to find any users: > pdbedit -Lv > pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain > casalogic.lan > > > > ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll > wrote: > > > > To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run > the ipa-adtrust-install --add-sids, even though I was not setting up a > trust. It would be nice if there was a way to generate these values another > way, maybe there is but I missed it. > > --Joshua D Doll > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Thu Oct 29 14:37:29 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 29 Oct 2015 20:07:29 +0530 Subject: [Freeipa-users] Multiple Reverse (PTR) Zone In-Reply-To: <56320B18.3090106@redhat.com> References: <56320B18.3090106@redhat.com> Message-ID: Sure Petr. Will go through it. Thanks for Sharing. *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Thu, Oct 29, 2015 at 5:33 PM, Petr Spacek wrote: > On 29.10.2015 11:33, Yogesh Sharma wrote: > > Hi, > > > > We are working on to create another DC and extending our existing > FreeIPA. > > > > Our current environment has subnet as 172.16.32.0/16. In another DC we > have > > 10.242.96.0/20. > > > > On FreeIPA master I have created a PTR Zone with 242.10.in-addr.arpa. , > > However, on registering the DC2 Client with FreeIPA Master it says > > "Hostname not found in DNS" > > This message tells you that "hostname" (i.e. what you see in output of > command > "hostname") does not have A/AAAA record in DNS. It has nothing to do with > PTR > records. > > Message "Failed to update DNS records." is usually caused by misconfigured > DNS > zones. > > Please see > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR > for advice how to configure DNS zones to accept dynamic updates. > > I hope this helps. > Petr^2 Spacek > > > Our Domain is same across DC, the only change is Subnet. > > > > Forward Zone is working fine. > > > > > > Below are Regestration Logs: > > > > [root at dr-ipadns-1002 ~]# ipa-client-install --mkhomedir --no-ntp > > Discovery was successful! > > Hostname: dr-ipadns-1002.klikpay.int > > Realm: KLIKPAY.INT > > DNS Domain: klikpay.int > > IPA Server: ipa-inf-prd-ng2-02.klikpay.int > > BaseDN: dc=klikpay,dc=int > > > > Continue to configure the system with these values? [no]: yes > > User authorized to enroll computers: admin > > Synchronizing time with KDC... > > Password for admin at KLIKPAY.INT: > > Successfully retrieved CA cert > > Subject: CN=Certificate Authority,O=KLIKPAY.INT > > Issuer: CN=Certificate Authority,O=KLIKPAY.INT > > Valid From: Fri Aug 14 11:39:47 2015 UTC > > Valid Until: Tue Aug 14 11:39:47 2035 UTC > > > > Enrolled in IPA realm KLIKPAY.INT > > Attempting to get host TGT... > > Created /etc/ipa/default.conf > > New SSSD config will be created > > Configured sudoers in /etc/nsswitch.conf > > Configured /etc/sssd/sssd.conf > > Configured /etc/krb5.conf for IPA realm KLIKPAY.INT > > trying https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml > > Forwarding 'env' to server u' > https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' > > *Hostname (dr-ipadns-1002.klikpay.int >) > > not found in DNS* > > Failed to update DNS records. > > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > > Forwarding 'host_mod' to server u' > > https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' > > SSSD enabled > > Configuring klikpay.int as NIS domain > > Configured /etc/openldap/ldap.conf > > Configured /etc/ssh/ssh_config > > Configured /etc/ssh/sshd_config > > Client configuration complete. > > > > [root at dr-ipadns-1002 ~]# ip r > > 10.242.96.0/20 dev eth0 proto kernel scope link src 10.242.96.3 > > 169.254.0.0/16 dev eth0 scope link metric 1002 > > default via 10.242.96.1 dev eth0 > > [root at dr-ipadns-1002 ~]# > > > > > >>From IPA: > > > > [root at ipa-inf-prd-ng2-01 ~]# ipa dnszone-show 242.10.in-addr.arpa > > Zone name: 242.10.in-addr.arpa. > > Active zone: TRUE > > Authoritative nameserver: ipa-inf-prd-ng2-01.klikpay.int. > > Administrator e-mail address: hostmaster > > SOA serial: 1446111284 > > SOA refresh: 3600 > > SOA retry: 900 > > SOA expire: 1209600 > > SOA minimum: 3600 > > Allow query: any; > > Allow transfer: none; > > [root at ipa-inf-prd-ng2-01 ~]# > > > > > > > > Please suggest as what I am missing. > > > -- > Petr^2 Spacek > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clark at nbs-system.com Thu Oct 29 14:55:45 2015 From: clark at nbs-system.com (Jean 'clark' EYMERIT) Date: Thu, 29 Oct 2015 15:55:45 +0100 Subject: [Freeipa-users] FreeIPA dogtag pkinit Message-ID: <56323371.5020800@nbs-system.com> Hello, I search a way to use pkinit (http://web.mit.edu/kerberos/krb5-devel/doc/admin/pkinit.html) with FreeIPA (even without dogtag). Can someone give me a howto for this ? On the official documentation and the ML archive, I only find some references about the disabled feature because of the dogtag incompatibility. Some links after my search : https://github.com/encukou/freeipa/blob/master/ipalib/plugins/pkinit.py https://www.redhat.com/archives/freeipa-devel/2010-November/msg00348.html https://www.redhat.com/archives/freeipa-devel/2011-January/msg00906.html The only intersting thing I know, it's this doc to create FreeIPA server without Dogtag : https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/creating-server.html Thanks you in advance for any information on the subject. -- Jean Eymerit From th at casalogic.dk Thu Oct 29 18:43:46 2015 From: th at casalogic.dk (Troels Hansen) Date: Thu, 29 Oct 2015 19:43:46 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> Message-ID: <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> I should think so: On IPA server. ipa role-show 'CIFS server' Role name: CIFS server Privileges: CIFS server privilege Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN ipa privilege-show 'CIFS server privilege' Privilege name: CIFS server privilege Permissions: CIFS test, CIFS server can read user passwords Granting privilege to roles: CIFS server ipa permission-show 'CIFS server can read user passwords' Permission name: CIFS server can read user passwords Granted rights: read, search, compare Effective attributes: ipaNTHash, ipaNTSecurityIdentifier Bind rule type: permission Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan Type: user Granted to Privilege: CIFS server privilege Indirect Member of roles: CIFS server ipa-getkeytab -s kenai.casalogic.lan -p cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab samba.keytab copied to samba server. on samba server (tinkerbell): kdestroy -A kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash SASL/GSSAPI authentication started SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=th # requesting: ipaNTHash # # th, users, compat, casalogic.lan dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan # th, users, accounts, casalogic.lan dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll wrote: Are you using the correct principal for the ldapsearch? Did you grant it permissions to view those attributes? --Joshua D Doll On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen < th at casalogic.dk > wrote: BQ_BEGIN Hmm, weird. I ran ipa-adtrust-install and it says it said it had user without SID's, and I told it to generete SID's. However, I still can't see them on the user. a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. ldapsearch -Y GSSAPI uid=th ipaNTHash ....... # th, users, compat, casalogic.lan dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan # th, users, accounts, casalogic.lan dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan ..... Samba however starts fine now, but unable to find any users: pdbedit -Lv pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain casalogic.lan ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll < joshua.doll at gmail.com > wrote: BQ_BEGIN To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the ipa-adtrust-install --add-sids, even though I was not setting up a trust. It would be nice if there was a way to generate these values another way, maybe there is but I missed it. --Joshua D Doll -- 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 BQ_END -- 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 BQ_END -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.doll at gmail.com Thu Oct 29 18:45:32 2015 From: joshua.doll at gmail.com (Joshua Doll) Date: Thu, 29 Oct 2015 18:45:32 +0000 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> Message-ID: What about as directory manager? --Joshua D Doll On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen wrote: > I should think so: > > On IPA server. > > ipa role-show 'CIFS server' > Role name: CIFS server > Privileges: CIFS server privilege > Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN > > ipa privilege-show 'CIFS server privilege' > Privilege name: CIFS server privilege > Permissions: CIFS test, CIFS server can read user passwords > Granting privilege to roles: CIFS server > > ipa permission-show 'CIFS server can read user passwords' > Permission name: CIFS server can read user passwords > Granted rights: read, search, compare > Effective attributes: ipaNTHash, ipaNTSecurityIdentifier > Bind rule type: permission > Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan > Type: user > Granted to Privilege: CIFS server privilege > Indirect Member of roles: CIFS server > > ipa-getkeytab -s kenai.casalogic.lan -p > cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab > > samba.keytab copied to samba server. > > on samba server (tinkerbell): > kdestroy -A > kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan > ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash > > SASL/GSSAPI authentication started > SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: uid=th > # requesting: ipaNTHash > # > > > # th, users, compat, casalogic.lan > dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > # th, users, accounts, casalogic.lan > dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > # search result > search: 4 > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > > > ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll > wrote: > > Are you using the correct principal for the ldapsearch? Did you grant it > permissions to view those attributes? > --Joshua D Doll > On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen wrote: > >> Hmm, weird. >> I ran ipa-adtrust-install and it says it said it had user without SID's, >> and I told it to generete SID's. >> However, I still can't see them on the user. >> a IPA-db doesn't reveal them being generated and I can't look them up via >> LDAP. >> >> ldapsearch -Y GSSAPI uid=th ipaNTHash >> ....... >> # th, users, compat, casalogic.lan >> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >> >> # th, users, accounts, casalogic.lan >> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >> >> ..... >> >> Samba however starts fine now, but unable to find any users: >> pdbedit -Lv >> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain >> casalogic.lan >> >> >> >> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll >> wrote: >> >> >> >> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run >> the ipa-adtrust-install --add-sids, even though I was not setting up a >> trust. It would be nice if there was a way to generate these values another >> way, maybe there is but I missed it. >> >> --Joshua D Doll >> >> >> -- >> 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 > > > -- > 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 > > > -- > > Med venlig hilsen > > *Troels Hansen* > > Systemkonsulent > > Casalogic A/S > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos > og meget mere. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Thu Oct 29 19:09:49 2015 From: th at casalogic.dk (Troels Hansen) Date: Thu, 29 Oct 2015 20:09:49 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> Message-ID: <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> Same result... ldapsearch -h kenai.casalogic.lan -D 'cn=Directory Manager' -x -W uid=th ipaNTHash Enter LDAP Password: # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: uid=th # requesting: ipaNTHash # # th, users, compat, casalogic.lan dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan # th, users, accounts, casalogic.lan dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 ----- On Oct 29, 2015, at 7:45 PM, Joshua Doll wrote: > What about as directory manager? > --Joshua D Doll > On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen < th at casalogic.dk > wrote: >> I should think so: >> On IPA server. >> ipa role-show 'CIFS server' >> Role name: CIFS server >> Privileges: CIFS server privilege >> Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >> ipa privilege-show 'CIFS server privilege' >> Privilege name: CIFS server privilege >> Permissions: CIFS test, CIFS server can read user passwords >> Granting privilege to roles: CIFS server >> ipa permission-show 'CIFS server can read user passwords' >> Permission name: CIFS server can read user passwords >> Granted rights: read, search, compare >> Effective attributes: ipaNTHash, ipaNTSecurityIdentifier >> Bind rule type: permission >> Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan >> Type: user >> Granted to Privilege: CIFS server privilege >> Indirect Member of roles: CIFS server >> ipa-getkeytab -s kenai.casalogic.lan -p >> cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab >> samba.keytab copied to samba server. >> on samba server (tinkerbell): >> kdestroy -A >> kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan >> ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash >> SASL/GSSAPI authentication started >> SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: uid=th >> # requesting: ipaNTHash >> # >> # th, users, compat, casalogic.lan >> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >> # th, users, accounts, casalogic.lan >> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >> # search result >> search: 4 >> result: 0 Success >> # numResponses: 3 >> # numEntries: 2 >> ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll < joshua.doll at gmail.com > wrote: >>> Are you using the correct principal for the ldapsearch? Did you grant it >>> permissions to view those attributes? >>> --Joshua D Doll >>> On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen < th at casalogic.dk > wrote: >>>> Hmm, weird. >>>> I ran ipa-adtrust-install and it says it said it had user without SID's, and I >>>> told it to generete SID's. >>>> However, I still can't see them on the user. >>>> a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. >>>> ldapsearch -Y GSSAPI uid=th ipaNTHash >>>> ....... >>>> # th, users, compat, casalogic.lan >>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >>>> # th, users, accounts, casalogic.lan >>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >>>> ..... >>>> Samba however starts fine now, but unable to find any users: >>>> pdbedit -Lv >>>> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain >>>> casalogic.lan >>>> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll < joshua.doll at gmail.com > wrote: >>>>> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the >>>>> ipa-adtrust-install --add-sids, even though I was not setting up a trust. It >>>>> would be nice if there was a way to generate these values another way, maybe >>>>> there is but I missed it. >>>>> --Joshua D Doll >>>>> -- >>>>> 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 >>> -- >>> 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 >> -- >> Med venlig hilsen >> Troels Hansen >> Systemkonsulent >> Casalogic A/S >> T (+45) 70 20 10 63 >> M (+45) 22 43 71 57 >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.doll at gmail.com Thu Oct 29 19:16:51 2015 From: joshua.doll at gmail.com (Joshua Doll) Date: Thu, 29 Oct 2015 19:16:51 +0000 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> Message-ID: Hmm.. well I'm at a loss then. I had to only run the ipa-adtrust-install --add-sids. I did notice when I was setting this up recently that I had to run the adtrust-install command whenever I added new users or groups. I don't know if it was just me being impatient or a limitation. Another thing I noticed that is different between our two setups is I couldn't get this setup to work on a separate host, I am running samba on the same host as my ipa service. --Joshua D Doll On Thu, Oct 29, 2015 at 3:09 PM Troels Hansen wrote: > Same result... > > ldapsearch -h kenai.casalogic.lan -D 'cn=Directory Manager' -x -W uid=th > ipaNTHash > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: uid=th > # requesting: ipaNTHash > # > > # th, users, compat, casalogic.lan > dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > # th, users, accounts, casalogic.lan > dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > # search result > search: 2 > > result: 0 Success > > # numResponses: 3 > # numEntries: 2 > > ----- On Oct 29, 2015, at 7:45 PM, Joshua Doll > wrote: > > What about as directory manager? > > --Joshua D Doll > > On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen wrote: > >> I should think so: >> >> On IPA server. >> >> ipa role-show 'CIFS server' >> Role name: CIFS server >> Privileges: CIFS server privilege >> Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >> >> ipa privilege-show 'CIFS server privilege' >> Privilege name: CIFS server privilege >> Permissions: CIFS test, CIFS server can read user passwords >> Granting privilege to roles: CIFS server >> >> ipa permission-show 'CIFS server can read user passwords' >> Permission name: CIFS server can read user passwords >> Granted rights: read, search, compare >> Effective attributes: ipaNTHash, ipaNTSecurityIdentifier >> Bind rule type: permission >> Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan >> Type: user >> Granted to Privilege: CIFS server privilege >> Indirect Member of roles: CIFS server >> >> ipa-getkeytab -s kenai.casalogic.lan -p >> cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab >> >> samba.keytab copied to samba server. >> >> on samba server (tinkerbell): >> kdestroy -A >> kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan >> ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash >> >> SASL/GSSAPI authentication started >> SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: uid=th >> # requesting: ipaNTHash >> # >> >> >> # th, users, compat, casalogic.lan >> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >> >> # th, users, accounts, casalogic.lan >> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >> >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 3 >> # numEntries: 2 >> >> >> >> ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll >> wrote: >> >> Are you using the correct principal for the ldapsearch? Did you grant it >> permissions to view those attributes? >> --Joshua D Doll >> On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen wrote: >> >>> Hmm, weird. >>> I ran ipa-adtrust-install and it says it said it had user without SID's, >>> and I told it to generete SID's. >>> However, I still can't see them on the user. >>> a IPA-db doesn't reveal them being generated and I can't look them up >>> via LDAP. >>> >>> ldapsearch -Y GSSAPI uid=th ipaNTHash >>> ....... >>> # th, users, compat, casalogic.lan >>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >>> >>> # th, users, accounts, casalogic.lan >>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >>> >>> ..... >>> >>> Samba however starts fine now, but unable to find any users: >>> pdbedit -Lv >>> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain >>> casalogic.lan >>> >>> >>> >>> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll >>> wrote: >>> >>> >>> >>> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to >>> run the ipa-adtrust-install --add-sids, even though I was not setting up a >>> trust. It would be nice if there was a way to generate these values another >>> way, maybe there is but I missed it. >>> >>> --Joshua D Doll >>> >>> >>> -- >>> 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 >> >> >> -- >> 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 >> >> >> -- >> >> Med venlig hilsen >> >> *Troels Hansen* >> >> Systemkonsulent >> >> Casalogic A/S >> >> T (+45) 70 20 10 63 >> >> M (+45) 22 43 71 57 >> >> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos >> og meget mere. >> > > -- > 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 > > > -- > > Med venlig hilsen > > *Troels Hansen* > > Systemkonsulent > > Casalogic A/S > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos > og meget mere. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Oct 29 19:54:56 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 Oct 2015 20:54:56 +0100 Subject: [Freeipa-users] rest api In-Reply-To: <20151028161359.GB4627@redhat.com> References: <20151028170549.Horde.8ixYfARLyhdWMPJdlUMRe0A@webmailnew.dds.nl> <20151028161359.GB4627@redhat.com> Message-ID: <56327990.2010506@redhat.com> On 10/28/2015 05:13 PM, Alexander Bokovoy wrote: > On Wed, 28 Oct 2015, Winfried de Heiden wrote: >> Hi all, >> >> In order for an external application to communicate with IPA and/or modify >> on (free)Ipa, we want to use the JSON API. >> >> Where can I find documentation how to use this API? > Read my blog post: > https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ > > FreeIPA 4.2 includes an API browser in Web UI. Yup. If you do not have 4.2 yet, you can also see the FreeIPA 4.2 API Browser in our Public Demo: https://ipa.demo1.freeipa.org/ipa/ui/#/p/apibrowser/type=command Martin From mkosek at redhat.com Thu Oct 29 20:10:02 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 29 Oct 2015 21:10:02 +0100 Subject: [Freeipa-users] anonymous LDAP attributes with IPA ipa-server-4.1 In-Reply-To: <20151028230615.GA26656@mypenguin.net.au> References: <20151028023223.GB16680@mypenguin.net.au> <20151028230615.GA26656@mypenguin.net.au> Message-ID: <56327D1A.3030602@redhat.com> On 10/29/2015 12:06 AM, craig.linux at mypenguin.net.au wrote: > Thanks it worked! > For those also intersted in the settings; > > Permission: ldap_anonymous > Bind Type Rule: anonymous > Granted Rights: (I used) "read","search","compare" > Subtree: cn=users,cn=accounts,dc=example,dc=com > Extra target filter: (&(objectclass=Person)(|(uid=*)(givenName=*))) > Target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com > Effective Attributes: > gecos, mail, mobile, telephoneNumber, uidNumber > > cheers, > > Craig This works. However, the "right way" here would be changing Bind Type Rule of default permission "System: Read User Addressbook Attributes" from "all" (default to new installation of FreeIPA 4.0) to "anonymous". This is the permission that holds extended attributes like this one: # ipa permission-show 'System: Read User Addressbook Attributes' Permission name: System: Read User Addressbook Attributes Granted rights: read, compare, search Effective attributes: audio, businesscategory, carlicense, departmentnumber, destinationindicator, employeenumber, employeetype, facsimiletelephonenumber, homephone, homepostaladdress, inetuserhttpurl, inetuserstatus, internationalisdnnumber, jpegphoto, l, labeleduri, mail, mobile, o, ou, pager, photo, physicaldeliveryofficename, postaladdress, postalcode, postofficebox, preferreddeliverymethod, preferredlanguage, registeredaddress, roomnumber, secretary, seealso, st, street, telephonenumber, teletexterminalidentifier, telexnumber, usercertificate, usersmimecertificate, x121address, x500uniqueidentifier Default attributes: postofficebox, registeredaddress, jpegphoto, physicaldeliveryofficename, homepostaladdress, labeleduri, photo, postalcode, street, x121address, st, telephonenumber, facsimiletelephonenumber, teletexterminalidentifier, usercertificate, mail, internationalisdnnumber, seealso, x500uniqueidentifier, employeetype, businesscategory, preferredlanguage, preferreddeliverymethod, roomnumber, carlicense, telexnumber, postaladdress, pager, destinationindicator, departmentnumber, mobile, inetuserhttpurl, l, o, inetuserstatus, employeenumber, usersmimecertificate, ou, audio, homephone, secretary Bind rule type: all Subtree: cn=users,cn=accounts,dc=rhel72 Type: user This approach will help you avoid extra read permission and keep your permission updated by FreeIPA updated, if needed (when new addressbook attribute is added for example). > > > > > On Wed, Oct 28, 2015 at 11:18:29AM +0530, Prashant Bapat wrote: >> ?Refer this doc >> [1]https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#server-access-controls? >> On 28 October 2015 at 11:11, Prashant Bapat <[2]prashant at apigee.com> >> wrote: >> >> Making attributes anonymously readable is very simple. You need to look >> into RBAC and define the permissions/privileges you need. >> On 28 October 2015 at 08:02, <[3]craig.linux at mypenguin.net.au> wrote: >> >> Hi, >> >> We have recently updated from IPA 3 to IPA 4.1 and one of the changes >> in >> security is what attributes are available for the anonymous LDAP >> queries. >> >> Does anyone know how to edit the anonymous LDAP settings so >> that the following are available? >> >> mail: [4]craig at example.com >> postalCode: 3000 >> street: 1 Home Parade >> mobile: 0000-000-000 >> telephoneNumber: 03-0000-0000 >> >> Note: We have many different types of LDAP clients here and even >> though >> using encrypted BIND's did work from ldapsearch queries, I couldn't >> get >> them to consistently work from our email clients. >> >> Regards, >> >> Craig >> -- >> Manage your subscription for the Freeipa-users mailing list: >> [5]https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to [6]http://freeipa.org for more info on the project >> >> References >> >> Visible links >> 1. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#server-access-controls >> 2. mailto:prashant at apigee.com >> 3. mailto:craig.linux at mypenguin.net.au >> 4. mailto:craig at example.com >> 5. https://www.redhat.com/mailman/listinfo/freeipa-users >> 6. http://freeipa.org/ > From th at casalogic.dk Fri Oct 30 09:53:47 2015 From: th at casalogic.dk (Troels Hansen) Date: Fri, 30 Oct 2015 10:53:47 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> Message-ID: <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> Well, I think the problem here being that I miss the attributes. One "funny" thing being that apprently, some users have had ipantuserattrs objectclass and a ipaNTSecurityIdentifier SID added. Some don't (including mine). Tried adding a new user, just to test, and this gets created with a ipaNTSecurityIdentifier, however, my old users still don't. I guess I jute need a way to have IPA add ipantuserattrs and ipaNTSecurityIdentifier to my existing users. when running ipa-adtrust-install it finds 85 users without SID, and I install the SID plugin (which is just 2 LDIF's), but this still doesn't do anything. ----- On Oct 29, 2015, at 8:16 PM, Joshua Doll wrote: > Hmm.. well I'm at a loss then. I had to only run the ipa-adtrust-install > --add-sids. I did notice when I was setting this up recently that I had to run > the adtrust-install command whenever I added new users or groups. I don't know > if it was just me being impatient or a limitation. Another thing I noticed that > is different between our two setups is I couldn't get this setup to work on a > separate host, I am running samba on the same host as my ipa service. > --Joshua D Doll > On Thu, Oct 29, 2015 at 3:09 PM Troels Hansen < th at casalogic.dk > wrote: >> Same result... >> ldapsearch -h kenai.casalogic.lan -D 'cn=Directory Manager' -x -W uid=th >> ipaNTHash >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: uid=th >> # requesting: ipaNTHash >> # >> # th, users, compat, casalogic.lan >> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >> # th, users, accounts, casalogic.lan >> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >> # search result >> search: 2 >> result: 0 Success >> # numResponses: 3 >> # numEntries: 2 >> ----- On Oct 29, 2015, at 7:45 PM, Joshua Doll < joshua.doll at gmail.com > wrote: >>> What about as directory manager? >>> --Joshua D Doll >>> On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen < th at casalogic.dk > wrote: >>>> I should think so: >>>> On IPA server. >>>> ipa role-show 'CIFS server' >>>> Role name: CIFS server >>>> Privileges: CIFS server privilege >>>> Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >>>> ipa privilege-show 'CIFS server privilege' >>>> Privilege name: CIFS server privilege >>>> Permissions: CIFS test, CIFS server can read user passwords >>>> Granting privilege to roles: CIFS server >>>> ipa permission-show 'CIFS server can read user passwords' >>>> Permission name: CIFS server can read user passwords >>>> Granted rights: read, search, compare >>>> Effective attributes: ipaNTHash, ipaNTSecurityIdentifier >>>> Bind rule type: permission >>>> Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan >>>> Type: user >>>> Granted to Privilege: CIFS server privilege >>>> Indirect Member of roles: CIFS server >>>> ipa-getkeytab -s kenai.casalogic.lan -p >>>> cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab >>>> samba.keytab copied to samba server. >>>> on samba server (tinkerbell): >>>> kdestroy -A >>>> kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan >>>> ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash >>>> SASL/GSSAPI authentication started >>>> SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base (default) with scope subtree >>>> # filter: uid=th >>>> # requesting: ipaNTHash >>>> # >>>> # th, users, compat, casalogic.lan >>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >>>> # th, users, accounts, casalogic.lan >>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >>>> # search result >>>> search: 4 >>>> result: 0 Success >>>> # numResponses: 3 >>>> # numEntries: 2 >>>> ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll < joshua.doll at gmail.com > wrote: >>>>> Are you using the correct principal for the ldapsearch? Did you grant it >>>>> permissions to view those attributes? >>>>> --Joshua D Doll >>>>> On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen < th at casalogic.dk > wrote: >>>>>> Hmm, weird. >>>>>> I ran ipa-adtrust-install and it says it said it had user without SID's, and I >>>>>> told it to generete SID's. >>>>>> However, I still can't see them on the user. >>>>>> a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. >>>>>> ldapsearch -Y GSSAPI uid=th ipaNTHash >>>>>> ....... >>>>>> # th, users, compat, casalogic.lan >>>>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan >>>>>> # th, users, accounts, casalogic.lan >>>>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan >>>>>> ..... >>>>>> Samba however starts fine now, but unable to find any users: >>>>>> pdbedit -Lv >>>>>> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain >>>>>> casalogic.lan >>>>>> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll < joshua.doll at gmail.com > wrote: >>>>>>> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the >>>>>>> ipa-adtrust-install --add-sids, even though I was not setting up a trust. It >>>>>>> would be nice if there was a way to generate these values another way, maybe >>>>>>> there is but I missed it. >>>>>>> --Joshua D Doll >>>>>>> -- >>>>>>> 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 >>>>> -- >>>>> 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 >>>> -- >>>> Med venlig hilsen >>>> Troels Hansen >>>> Systemkonsulent >>>> Casalogic A/S >>>> T (+45) 70 20 10 63 >>>> M (+45) 22 43 71 57 >>>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>>> meget mere. >>> -- >>> 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 >> -- >> Med venlig hilsen >> Troels Hansen >> Systemkonsulent >> Casalogic A/S >> T (+45) 70 20 10 63 >> M (+45) 22 43 71 57 >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >> meget mere. > -- > 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 -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 30 10:02:39 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 12:02:39 +0200 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030100239.GM8374@redhat.com> On Fri, 30 Oct 2015, Troels Hansen wrote: >Well, I think the problem here being that I miss the attributes. One >"funny" thing being that apprently, some users have had ipantuserattrs >objectclass and a ipaNTSecurityIdentifier SID added. Some don't >(including mine). Tried adding a new user, just to test, and this gets >created with a ipaNTSecurityIdentifier, however, my old users still >don't. I guess I jute need a way to have IPA add ipantuserattrs and >ipaNTSecurityIdentifier to my existing users. Not sure what you expect. Modifying attributes for existing users takes time so we don't do it automatically. When you run ipa-adtrust-install, it does ask you to run a task that does the work of generating SIDs and adding needed attributes/object classes. However, ipaNTHash will not be there until either of two events happens: - user changes password; - user authenticates with Kerberos against Samba running on IPA master. > >when running ipa-adtrust-install it finds 85 users without SID, and I >install the SID plugin (which is just 2 LDIF's), but this still doesn't >do anything. *you* install the SID plugin or ipa-adtrust-install adds two plugins and then runs a task to generate SIDs? > >----- On Oct 29, 2015, at 8:16 PM, Joshua Doll wrote: > >> Hmm.. well I'm at a loss then. I had to only run the ipa-adtrust-install >> --add-sids. I did notice when I was setting this up recently that I had to run >> the adtrust-install command whenever I added new users or groups. I don't know >> if it was just me being impatient or a limitation. Another thing I noticed that >> is different between our two setups is I couldn't get this setup to work on a >> separate host, I am running samba on the same host as my ipa service. > >> --Joshua D Doll > >> On Thu, Oct 29, 2015 at 3:09 PM Troels Hansen < th at casalogic.dk > wrote: > >>> Same result... > >>> ldapsearch -h kenai.casalogic.lan -D 'cn=Directory Manager' -x -W uid=th >>> ipaNTHash >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base (default) with scope subtree >>> # filter: uid=th >>> # requesting: ipaNTHash >>> # > >>> # th, users, compat, casalogic.lan >>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > >>> # th, users, accounts, casalogic.lan >>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > >>> # search result >>> search: 2 > >>> result: 0 Success > >>> # numResponses: 3 >>> # numEntries: 2 > >>> ----- On Oct 29, 2015, at 7:45 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > >>>> What about as directory manager? > >>>> --Joshua D Doll > >>>> On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen < th at casalogic.dk > wrote: > >>>>> I should think so: > >>>>> On IPA server. > >>>>> ipa role-show 'CIFS server' >>>>> Role name: CIFS server >>>>> Privileges: CIFS server privilege >>>>> Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN > >>>>> ipa privilege-show 'CIFS server privilege' >>>>> Privilege name: CIFS server privilege >>>>> Permissions: CIFS test, CIFS server can read user passwords >>>>> Granting privilege to roles: CIFS server > >>>>> ipa permission-show 'CIFS server can read user passwords' >>>>> Permission name: CIFS server can read user passwords >>>>> Granted rights: read, search, compare >>>>> Effective attributes: ipaNTHash, ipaNTSecurityIdentifier >>>>> Bind rule type: permission >>>>> Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan >>>>> Type: user >>>>> Granted to Privilege: CIFS server privilege >>>>> Indirect Member of roles: CIFS server > >>>>> ipa-getkeytab -s kenai.casalogic.lan -p >>>>> cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab > >>>>> samba.keytab copied to samba server. > >>>>> on samba server (tinkerbell): >>>>> kdestroy -A >>>>> kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan >>>>> ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash > >>>>> SASL/GSSAPI authentication started >>>>> SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN >>>>> SASL SSF: 56 >>>>> SASL data security layer installed. >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base (default) with scope subtree >>>>> # filter: uid=th >>>>> # requesting: ipaNTHash >>>>> # > >>>>> # th, users, compat, casalogic.lan >>>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > >>>>> # th, users, accounts, casalogic.lan >>>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > >>>>> # search result >>>>> search: 4 >>>>> result: 0 Success > >>>>> # numResponses: 3 >>>>> # numEntries: 2 > >>>>> ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > >>>>>> Are you using the correct principal for the ldapsearch? Did you grant it >>>>>> permissions to view those attributes? >>>>>> --Joshua D Doll >>>>>> On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen < th at casalogic.dk > wrote: > >>>>>>> Hmm, weird. >>>>>>> I ran ipa-adtrust-install and it says it said it had user without SID's, and I >>>>>>> told it to generete SID's. >>>>>>> However, I still can't see them on the user. >>>>>>> a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. > >>>>>>> ldapsearch -Y GSSAPI uid=th ipaNTHash >>>>>>> ....... >>>>>>> # th, users, compat, casalogic.lan >>>>>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > >>>>>>> # th, users, accounts, casalogic.lan >>>>>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > >>>>>>> ..... > >>>>>>> Samba however starts fine now, but unable to find any users: >>>>>>> pdbedit -Lv >>>>>>> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain >>>>>>> casalogic.lan > >>>>>>> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > >>>>>>>> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the >>>>>>>> ipa-adtrust-install --add-sids, even though I was not setting up a trust. It >>>>>>>> would be nice if there was a way to generate these values another way, maybe >>>>>>>> there is but I missed it. > >>>>>>>> --Joshua D Doll > >>>>>>>> -- >>>>>>>> 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 >>>>>> -- >>>>>> 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 > >>>>> -- > >>>>> Med venlig hilsen > >>>>> Troels Hansen > >>>>> Systemkonsulent > >>>>> Casalogic A/S > >>>>> T (+45) 70 20 10 63 > >>>>> M (+45) 22 43 71 57 > >>>>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>>>> meget mere. > >>>> -- >>>> 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 > >>> -- > >>> Med venlig hilsen > >>> Troels Hansen > >>> Systemkonsulent > >>> Casalogic A/S > >>> T (+45) 70 20 10 63 > >>> M (+45) 22 43 71 57 > >>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og >>> meget mere. > >> -- >> 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 > >-- > >Med venlig hilsen > >Troels Hansen > >Systemkonsulent > >Casalogic A/S > >T (+45) 70 20 10 63 > >M (+45) 22 43 71 57 > >Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. >-- >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 -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 30 10:28:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 12:28:42 +0200 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030102842.GP8374@redhat.com> Please answer to the list. On Fri, 30 Oct 2015, Troels Hansen wrote: >> Not sure what you expect. >> >> Modifying attributes for existing users takes time so we don't do it >> automatically. When you run ipa-adtrust-install, it does ask you to run >> a task that does the work of generating SIDs and adding needed >> attributes/object classes. >> >> However, ipaNTHash will not be there until either of two events happens: >> - user changes password; >> - user authenticates with Kerberos against Samba running on IPA master. > >No, I'm aware that the NTHash won't be there untill the user changes password. >I would however suppose that objectClass ipaNTUserAttrs being added and a ipaNTSecurityIdentifier being added to all of my users. >Its added to most objects, but I still need 85 users/objects where its not added, out of a total of ~500 (told by adtrust install script yesterday). >Its been 14 hours since I ran it, but still need the remaining, and I have no idear why its not added. You can check the task status. See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ how you can organize a task yourself or check the output from existing task. The task that is run by the installer has DN cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config You can use /usr/share/ipa/ipa-sidgen-task-run.ldif as a basis to add a task file. -- / Alexander Bokovoy From sbose at redhat.com Fri Oct 30 10:29:39 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 30 Oct 2015 11:29:39 +0100 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <88551992.7739348.1446124269205.JavaMail.zimbra@casalogic.dk> <1336217845.7788607.1446144226502.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030102939.GD27323@p.redhat.com> On Fri, Oct 30, 2015 at 10:53:47AM +0100, Troels Hansen wrote: > Well, I think the problem here being that I miss the attributes. > One "funny" thing being that apprently, some users have had ipantuserattrs objectclass and a ipaNTSecurityIdentifier SID added. Some don't (including mine). > Tried adding a new user, just to test, and this gets created with a ipaNTSecurityIdentifier, however, my old users still don't. > I guess I jute need a way to have IPA add ipantuserattrs and ipaNTSecurityIdentifier to my existing users. > > when running ipa-adtrust-install it finds 85 users without SID, and I install the SID plugin (which is just 2 LDIF's), but this still doesn't do anything. Did you run ipa-adtrust-install with the '--add-sids' option? About ipaNTHash, this is not created by ipa-adtrust-install or any other tool. For the integrated smbd the NT hash is derived from a suitable Kerberos key by adding a magic keyword to the ipaNTHash attribute. You can try to do this manually with the following steps: - The principal used by the internal smdb has the right permissions to add the attribute: kinit -k -t /etc/samba/samba.keytab cifs/ipa.server at IPA.DOMAIN - write the magic keyword MagicRegen into the ipaNTHash attribute of the user ldapmodify -Y GSSAPI -H ldap://ipa-devel.ipa.devel << END dn: uid=ipa_user,cn=users,cn=accounts,dc=ipa,dc=domain changetype: modify add: ipaNTHash ipaNTHash: MagicRegen END If a suitable Kerberos key was available the user object now has the ipaNTHash attribute set with the right NT hash value. HTH bye, Sumit > > ----- On Oct 29, 2015, at 8:16 PM, Joshua Doll wrote: > > > Hmm.. well I'm at a loss then. I had to only run the ipa-adtrust-install > > --add-sids. I did notice when I was setting this up recently that I had to run > > the adtrust-install command whenever I added new users or groups. I don't know > > if it was just me being impatient or a limitation. Another thing I noticed that > > is different between our two setups is I couldn't get this setup to work on a > > separate host, I am running samba on the same host as my ipa service. > > > --Joshua D Doll > > > On Thu, Oct 29, 2015 at 3:09 PM Troels Hansen < th at casalogic.dk > wrote: > > >> Same result... > > >> ldapsearch -h kenai.casalogic.lan -D 'cn=Directory Manager' -x -W uid=th > >> ipaNTHash > >> Enter LDAP Password: > >> # extended LDIF > >> # > >> # LDAPv3 > >> # base (default) with scope subtree > >> # filter: uid=th > >> # requesting: ipaNTHash > >> # > > >> # th, users, compat, casalogic.lan > >> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > >> # th, users, accounts, casalogic.lan > >> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > >> # search result > >> search: 2 > > >> result: 0 Success > > >> # numResponses: 3 > >> # numEntries: 2 > > >> ----- On Oct 29, 2015, at 7:45 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > > >>> What about as directory manager? > > >>> --Joshua D Doll > > >>> On Thu, Oct 29, 2015 at 2:43 PM Troels Hansen < th at casalogic.dk > wrote: > > >>>> I should think so: > > >>>> On IPA server. > > >>>> ipa role-show 'CIFS server' > >>>> Role name: CIFS server > >>>> Privileges: CIFS server privilege > >>>> Member services: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN > > >>>> ipa privilege-show 'CIFS server privilege' > >>>> Privilege name: CIFS server privilege > >>>> Permissions: CIFS test, CIFS server can read user passwords > >>>> Granting privilege to roles: CIFS server > > >>>> ipa permission-show 'CIFS server can read user passwords' > >>>> Permission name: CIFS server can read user passwords > >>>> Granted rights: read, search, compare > >>>> Effective attributes: ipaNTHash, ipaNTSecurityIdentifier > >>>> Bind rule type: permission > >>>> Subtree: cn=users,cn=accounts,dc=casalogic,dc=lan > >>>> Type: user > >>>> Granted to Privilege: CIFS server privilege > >>>> Indirect Member of roles: CIFS server > > >>>> ipa-getkeytab -s kenai.casalogic.lan -p > >>>> cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN -k /tmp/samba.keytab > > >>>> samba.keytab copied to samba server. > > >>>> on samba server (tinkerbell): > >>>> kdestroy -A > >>>> kinit -kt /etc/samba/samba.keytab cifs/tinkerbell.casalogic.lan > >>>> ldapsearch -h kenai.casalogic.lan -Y GSSAPI uid=th ipaNTHash > > >>>> SASL/GSSAPI authentication started > >>>> SASL username: cifs/tinkerbell.casalogic.lan at CASALOGIC.LAN > >>>> SASL SSF: 56 > >>>> SASL data security layer installed. > >>>> # extended LDIF > >>>> # > >>>> # LDAPv3 > >>>> # base (default) with scope subtree > >>>> # filter: uid=th > >>>> # requesting: ipaNTHash > >>>> # > > >>>> # th, users, compat, casalogic.lan > >>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > >>>> # th, users, accounts, casalogic.lan > >>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > >>>> # search result > >>>> search: 4 > >>>> result: 0 Success > > >>>> # numResponses: 3 > >>>> # numEntries: 2 > > >>>> ----- On Oct 29, 2015, at 3:27 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > > >>>>> Are you using the correct principal for the ldapsearch? Did you grant it > >>>>> permissions to view those attributes? > >>>>> --Joshua D Doll > >>>>> On Thu, Oct 29, 2015 at 9:14 AM Troels Hansen < th at casalogic.dk > wrote: > > >>>>>> Hmm, weird. > >>>>>> I ran ipa-adtrust-install and it says it said it had user without SID's, and I > >>>>>> told it to generete SID's. > >>>>>> However, I still can't see them on the user. > >>>>>> a IPA-db doesn't reveal them being generated and I can't look them up via LDAP. > > >>>>>> ldapsearch -Y GSSAPI uid=th ipaNTHash > >>>>>> ....... > >>>>>> # th, users, compat, casalogic.lan > >>>>>> dn: uid=th,cn=users,cn=compat,dc=casalogic,dc=lan > > >>>>>> # th, users, accounts, casalogic.lan > >>>>>> dn: uid=th,cn=users,cn=accounts,dc=casalogic,dc=lan > > >>>>>> ..... > > >>>>>> Samba however starts fine now, but unable to find any users: > >>>>>> pdbedit -Lv > >>>>>> pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain > >>>>>> casalogic.lan > > >>>>>> ----- On Oct 27, 2015, at 3:46 PM, Joshua Doll < joshua.doll at gmail.com > wrote: > > >>>>>>> To get the ipaNTHash and ipaNTSecurityIdentifier attributes, I had to run the > >>>>>>> ipa-adtrust-install --add-sids, even though I was not setting up a trust. It > >>>>>>> would be nice if there was a way to generate these values another way, maybe > >>>>>>> there is but I missed it. > > >>>>>>> --Joshua D Doll > > >>>>>>> -- > >>>>>>> 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 > >>>>> -- > >>>>> 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 > > >>>> -- > > >>>> Med venlig hilsen > > >>>> Troels Hansen > > >>>> Systemkonsulent > > >>>> Casalogic A/S > > >>>> T (+45) 70 20 10 63 > > >>>> M (+45) 22 43 71 57 > > >>>> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > >>>> meget mere. > > >>> -- > >>> 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 > > >> -- > > >> Med venlig hilsen > > >> Troels Hansen > > >> Systemkonsulent > > >> Casalogic A/S > > >> T (+45) 70 20 10 63 > > >> M (+45) 22 43 71 57 > > >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og > >> meget mere. > > > -- > > 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 > > -- > > Med venlig hilsen > > Troels Hansen > > Systemkonsulent > > Casalogic A/S > > T (+45) 70 20 10 63 > > M (+45) 22 43 71 57 > > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > -- > 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 From yks0000 at gmail.com Fri Oct 30 10:38:04 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 30 Oct 2015 16:08:04 +0530 Subject: [Freeipa-users] Multiple Reverse (PTR) Zone In-Reply-To: References: <56320B18.3090106@redhat.com> Message-ID: Thanks it is resolved. *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Thu, Oct 29, 2015 at 8:07 PM, Yogesh Sharma wrote: > Sure Petr. Will go through it. Thanks for Sharing. > > *Best Regards,* > > *__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > > On Thu, Oct 29, 2015 at 5:33 PM, Petr Spacek wrote: > >> On 29.10.2015 11:33, Yogesh Sharma wrote: >> > Hi, >> > >> > We are working on to create another DC and extending our existing >> FreeIPA. >> > >> > Our current environment has subnet as 172.16.32.0/16. In another DC we >> have >> > 10.242.96.0/20. >> > >> > On FreeIPA master I have created a PTR Zone with 242.10.in-addr.arpa. , >> > However, on registering the DC2 Client with FreeIPA Master it says >> > "Hostname not found in DNS" >> >> This message tells you that "hostname" (i.e. what you see in output of >> command >> "hostname") does not have A/AAAA record in DNS. It has nothing to do with >> PTR >> records. >> >> Message "Failed to update DNS records." is usually caused by >> misconfigured DNS >> zones. >> >> Please see >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR >> for advice how to configure DNS zones to accept dynamic updates. >> >> I hope this helps. >> Petr^2 Spacek >> >> > Our Domain is same across DC, the only change is Subnet. >> > >> > Forward Zone is working fine. >> > >> > >> > Below are Regestration Logs: >> > >> > [root at dr-ipadns-1002 ~]# ipa-client-install --mkhomedir --no-ntp >> > Discovery was successful! >> > Hostname: dr-ipadns-1002.klikpay.int >> > Realm: KLIKPAY.INT >> > DNS Domain: klikpay.int >> > IPA Server: ipa-inf-prd-ng2-02.klikpay.int >> > BaseDN: dc=klikpay,dc=int >> > >> > Continue to configure the system with these values? [no]: yes >> > User authorized to enroll computers: admin >> > Synchronizing time with KDC... >> > Password for admin at KLIKPAY.INT: >> > Successfully retrieved CA cert >> > Subject: CN=Certificate Authority,O=KLIKPAY.INT >> > Issuer: CN=Certificate Authority,O=KLIKPAY.INT >> > Valid From: Fri Aug 14 11:39:47 2015 UTC >> > Valid Until: Tue Aug 14 11:39:47 2035 UTC >> > >> > Enrolled in IPA realm KLIKPAY.INT >> > Attempting to get host TGT... >> > Created /etc/ipa/default.conf >> > New SSSD config will be created >> > Configured sudoers in /etc/nsswitch.conf >> > Configured /etc/sssd/sssd.conf >> > Configured /etc/krb5.conf for IPA realm KLIKPAY.INT >> > trying https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml >> > Forwarding 'env' to server u' >> https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' >> > *Hostname (dr-ipadns-1002.klikpay.int < >> http://dr-ipadns-1002.klikpay.int>) >> > not found in DNS* >> > Failed to update DNS records. >> > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> > Forwarding 'host_mod' to server u' >> > https://ipa-inf-prd-ng2-02.klikpay.int/ipa/xml' >> > SSSD enabled >> > Configuring klikpay.int as NIS domain >> > Configured /etc/openldap/ldap.conf >> > Configured /etc/ssh/ssh_config >> > Configured /etc/ssh/sshd_config >> > Client configuration complete. >> > >> > [root at dr-ipadns-1002 ~]# ip r >> > 10.242.96.0/20 dev eth0 proto kernel scope link src 10.242.96.3 >> > 169.254.0.0/16 dev eth0 scope link metric 1002 >> > default via 10.242.96.1 dev eth0 >> > [root at dr-ipadns-1002 ~]# >> > >> > >> >>From IPA: >> > >> > [root at ipa-inf-prd-ng2-01 ~]# ipa dnszone-show 242.10.in-addr.arpa >> > Zone name: 242.10.in-addr.arpa. >> > Active zone: TRUE >> > Authoritative nameserver: ipa-inf-prd-ng2-01.klikpay.int. >> > Administrator e-mail address: hostmaster >> > SOA serial: 1446111284 >> > SOA refresh: 3600 >> > SOA retry: 900 >> > SOA expire: 1209600 >> > SOA minimum: 3600 >> > Allow query: any; >> > Allow transfer: none; >> > [root at ipa-inf-prd-ng2-01 ~]# >> > >> > >> > >> > Please suggest as what I am missing. >> >> >> -- >> Petr^2 Spacek >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Fri Oct 30 10:54:08 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 30 Oct 2015 16:24:08 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: Message-ID: Additionally, On Replica UI, I am getting below Error Message: IPA Error 4301: CertificateOperationError Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* On Fri, Oct 30, 2015 at 4:16 PM, Yogesh Sharma wrote: > Team, > > Noticed that user created on IPA Master are not replicating on Replica. > > Also, we create a new Zone in Master, However we do not see the same in > replica server. > > > Below is the information: > > From Master: > > [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-02.klikpay.int: replica > last init status: None > last init ended: None > last update status: -1 Unable to acquire replicaLDAP error: Can't > contact LDAP server > last update ended: None > [root at ipa-inf-prd-ng2-01 ~]# > > > > From Replica: > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-02.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-01.klikpay.int: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental update > succeeded > last update ended: 2015-10-30 10:36:25+00:00 > [root at ipa-inf-prd-ng2-02 ~]# > > > Though it says it is replicated (last update ended), We are not seeing new > users and the new DNS Zone which we created > > > I also tried force replication, though I can not see the new Changes: > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= > meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > [root at ipa-inf-prd-ng2-02 ~]# > > > Once I do re-initialization, it gives "Can't Contact LDAP Server" > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize --from > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= > meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > > [ipa-inf-prd-ng2-01.klikpay.int] reports: Update failed! Status: [-1 - > LDAP error: Can't contact LDAP server] > > > > > *Best Regards,* > > *__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Fri Oct 30 11:28:34 2015 From: th at casalogic.dk (Troels Hansen) Date: Fri, 30 Oct 2015 12:28:34 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151030102842.GP8374@redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> Message-ID: <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> Hi Alexander, sorry for the last update directly to you, this was not intended. Anyway, shouldn't I be able to check the status of task added by ipa-adtrust-install directly by just issuing a: ldapsearch -D "cn=Directory Manager" -W -b 'cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config' All I get is: Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ----- On Oct 30, 2015, at 11:28 AM, Alexander Bokovoy abokovoy at redhat.com wrote: > Please answer to the list. > > On Fri, 30 Oct 2015, Troels Hansen wrote: >>> Not sure what you expect. >>> >>> Modifying attributes for existing users takes time so we don't do it >>> automatically. When you run ipa-adtrust-install, it does ask you to run >>> a task that does the work of generating SIDs and adding needed >>> attributes/object classes. >>> >>> However, ipaNTHash will not be there until either of two events happens: >>> - user changes password; >>> - user authenticates with Kerberos against Samba running on IPA master. >> >>No, I'm aware that the NTHash won't be there untill the user changes password. >>I would however suppose that objectClass ipaNTUserAttrs being added and a >>ipaNTSecurityIdentifier being added to all of my users. >>Its added to most objects, but I still need 85 users/objects where its not >>added, out of a total of ~500 (told by adtrust install script yesterday). >>Its been 14 hours since I ran it, but still need the remaining, and I have no >>idear why its not added. > You can check the task status. > > See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ > how you can organize a task yourself or check the output from existing task. > > The task that is run by the installer has DN > cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config > You can use /usr/share/ipa/ipa-sidgen-task-run.ldif as a basis to add a > task file. > -- > / Alexander Bokovoy -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From abokovoy at redhat.com Fri Oct 30 11:40:42 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 13:40:42 +0200 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20270367.7792686.1446145789662.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030114042.GQ8374@redhat.com> On Fri, 30 Oct 2015, Troels Hansen wrote: >Hi Alexander, sorry for the last update directly to you, this was not intended. > >Anyway, shouldn't I be able to check the status of task added by ipa-adtrust-install directly by just issuing a: > >ldapsearch -D "cn=Directory Manager" -W -b 'cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config' > >All I get is: > >Enter LDAP Password: ># extended LDIF ># ># LDAPv3 ># base with scope subtree ># filter: (objectclass=*) ># requesting: ALL ># > ># search result >search: 2 >result: 0 Success > ># numResponses: 1 This means the task has finished already. You can run a new one to see if it reports something detailed about the DNs it couldn't process. -- / Alexander Bokovoy From th at casalogic.dk Fri Oct 30 12:37:25 2015 From: th at casalogic.dk (Troels Hansen) Date: Fri, 30 Oct 2015 13:37:25 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151030114042.GQ8374@redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> Message-ID: <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> > This means the task has finished already. > > You can run a new one to see if it reports something detailed about the > DNs it couldn't process. > Hmm, this is weird: I have created a task: 10-task-sidgen-run.update containing: dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config add:objectclass:top,extensibleObject add:cn:$TIME-$FQDN-$LIBARCH add:basedn:"cn=accounts,$SUFFIX" add:ttl:3600 add:delay:0 However, when I add it with debug enabled I get: ........ ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: Final value after applying updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: dn: cn=1446208552-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: cn: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: 1446208552-kenai.casalogic.lan-64 ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: objectclass: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: top ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: extensibleObject ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: basedn: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: cn=accounts,dc=casalogic,dc=lan ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: delay: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: 0 ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: ttl: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: 3600 ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: scope: ipa.ipaserver.install.ldapupdate.LDAPUpdate: DEBUG: sub ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Constraint violation: ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The ipa-ldap-updater command was successful but I can't why I should get a constraint violation? Am I missing something? tried with a filter, without ttl, delay etc. nsslapd-basedn instead of basedn, but no luck. Am I missing something? As a test, I tried creating the tesk from your example, and this runs fine. -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From mbasti at redhat.com Fri Oct 30 12:42:55 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Oct 2015 13:42:55 +0100 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: Message-ID: <563365CF.2010106@redhat.com> On 30.10.2015 11:54, Yogesh Sharma wrote: > Additionally, On Replica UI, I am getting below Error Message: > > > IPA Error 4301: CertificateOperationError > > Certificate operation cannot be completed: Unable to communicate with > CMS (Not Found) > Hello, can you check /var/log/httpd/error_log if there is a detailed info? Martin > > /Best Regards,/ > /__________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: > www.initd.in / > / > / > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ > > > > > > On Fri, Oct 30, 2015 at 4:16 PM, Yogesh Sharma > wrote: > > Team, > > Noticed that user created on IPA Master are not replicating on > Replica. > > Also, we create a new Zone in Master, However we do not see the > same in replica server. > > > Below is the information: > > From Master: > > [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-02.klikpay.int > : replica > last init status: None > last init ended: None > last update status: -1 Unable to acquire replicaLDAP error: > Can't contact LDAP server > last update ended: None > [root at ipa-inf-prd-ng2-01 ~]# > > > > From Replica: > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-02.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-01.klikpay.int > : replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2015-10-30 10:36:25+00:00 > [root at ipa-inf-prd-ng2-02 ~]# > > > Though it says it is replicated (last update ended), We are not > seeing new users and the new DNS Zone which we created > > > I also tried force replication, though I can not see the new Changes: > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > [root at ipa-inf-prd-ng2-02 ~]# > > > Once I do re-initialization, it gives "Can't Contact LDAP Server" > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize > --from ipa-inf-prd-ng2-01.klikpay.int > > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > > [ipa-inf-prd-ng2-01.klikpay.int > ] reports: Update failed! > Status: [-1 - LDAP error: Can't contact LDAP server] > > > > > /Best Regards,/ > /__________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: > www.initd.in / > / > / > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 30 12:48:34 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 14:48:34 +0200 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <706503702.7910303.1446198827420.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030124834.GR8374@redhat.com> On Fri, 30 Oct 2015, Troels Hansen wrote: > >> This means the task has finished already. >> >> You can run a new one to see if it reports something detailed about the >> DNs it couldn't process. >> > > >Hmm, this is weird: > >I have created a task: >10-task-sidgen-run.update > >containing: > >dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config >add:objectclass:top,extensibleObject >add:cn:$TIME-$FQDN-$LIBARCH >add:basedn:"cn=accounts,$SUFFIX" >add:ttl:3600 >add:delay:0 I think it should be add:nsslapd-basedn: cn=accounts,$SUFFIX not add:basedn:"cn=accounts,$SUFFIX" this is what sidgen task expects and it returns constraint violation error if parameters are wrong: str = fetch_attr(e, "nsslapd-basedn", NULL); if (str == NULL) { LOG_FATAL("Missing nsslapd-basedn!\n"); *returncode = LDAP_CONSTRAINT_VIOLATION; ret = SLAPI_DSE_CALLBACK_ERROR; goto done; } -- / Alexander Bokovoy From yks0000 at gmail.com Fri Oct 30 10:46:20 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 30 Oct 2015 16:16:20 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS Message-ID: Team, Noticed that user created on IPA Master are not replicating on Replica. Also, we create a new Zone in Master, However we do not see the same in replica server. Below is the information: >From Master: [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v ipa-inf-prd-ng2-01.klikpay.int Directory Manager password: ipa-inf-prd-ng2-02.klikpay.int: replica last init status: None last init ended: None last update status: -1 Unable to acquire replicaLDAP error: Can't contact LDAP server last update ended: None [root at ipa-inf-prd-ng2-01 ~]# >From Replica: [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v ipa-inf-prd-ng2-02.klikpay.int Directory Manager password: ipa-inf-prd-ng2-01.klikpay.int: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2015-10-30 10:36:25+00:00 [root at ipa-inf-prd-ng2-02 ~]# Though it says it is replicated (last update ended), We are not seeing new users and the new DNS Zone which we created I also tried force replication, though I can not see the new Changes: [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from ipa-inf-prd-ng2-01.klikpay.int Directory Manager password: ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping tree,cn=config [root at ipa-inf-prd-ng2-02 ~]# Once I do re-initialization, it gives "Can't Contact LDAP Server" [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize --from ipa-inf-prd-ng2-01.klikpay.int Directory Manager password: ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn= meToipa-inf-prd-ng2-02.klikpay.int,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping tree,cn=config [ipa-inf-prd-ng2-01.klikpay.int] reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP server] *Best Regards,* *__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Fri Oct 30 13:19:31 2015 From: th at casalogic.dk (Troels Hansen) Date: Fri, 30 Oct 2015 14:19:31 +0100 (CET) Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <20151030124834.GR8374@redhat.com> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> Message-ID: <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> > I think it should be > add:nsslapd-basedn: cn=accounts,$SUFFIX > not > add:basedn:"cn=accounts,$SUFFIX" > > this is what sidgen task expects and it returns constraint violation > error if parameters are wrong: > > str = fetch_attr(e, "nsslapd-basedn", NULL); > if (str == NULL) { > LOG_FATAL("Missing nsslapd-basedn!\n"); > *returncode = LDAP_CONSTRAINT_VIOLATION; > ret = SLAPI_DSE_CALLBACK_ERROR; > goto done; > } > I think you are right. Don't know what I have tested, but it brings me a different error, that I didn't see before: ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations error: ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The ipa-ldap-updater command was successful Where did you find the source for the sidgen task? I could try looking at at it myself, but can't find it. -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From rcritten at redhat.com Fri Oct 30 13:35:17 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 09:35:17 -0400 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: References: Message-ID: <56337215.6000808@redhat.com> Yogesh Sharma wrote: > Team, > > Noticed that user created on IPA Master are not replicating on Replica. > > Also, we create a new Zone in Master, However we do not see the same in > replica server. You need to figure out why ipa-inf-prd-ng2-01.klikpay.int can't contact port 389 on ipa-inf-prd-ng2-02.klikpay.int. It may be someone threw up a firewall without telling you, or someone tweaked the rules on either of those boxes. Doing re-init, force-sync, etc is always going to fail if one can't talk to the other. rob > > > Below is the information: > > From Master: > > [root at ipa-inf-prd-ng2-01 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-02.klikpay.int : > replica > last init status: None > last init ended: None > last update status: -1 Unable to acquire replicaLDAP error: Can't > contact LDAP server > last update ended: None > [root at ipa-inf-prd-ng2-01 ~]# > > > > From Replica: > > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage list -v > ipa-inf-prd-ng2-02.klikpay.int > Directory Manager password: > > ipa-inf-prd-ng2-01.klikpay.int : > replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2015-10-30 10:36:25+00:00 > [root at ipa-inf-prd-ng2-02 ~]# > > > Though it says it is replicated (last update ended), We are not seeing > new users and the new DNS Zone which we created > > > I also tried force replication, though I can not see the new Changes: > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage force-sync --from > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > [root at ipa-inf-prd-ng2-02 ~]# > > > Once I do re-initialization, it gives "Can't Contact LDAP Server" > > [root at ipa-inf-prd-ng2-02 ~]# ipa-replica-manage re-initialize --from > ipa-inf-prd-ng2-01.klikpay.int > Directory Manager password: > > ipa: INFO: Setting agreement cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meToipa-inf-prd-ng2-02.klikpay.int > ,cn=replica,cn=dc\=klikpay\,dc\=int,cn=mapping > tree,cn=config > > [ipa-inf-prd-ng2-01.klikpay.int ] > reports: Update failed! Status: [-1 - LDAP error: Can't contact LDAP > server] > > > > > /Best Regards,/ > /__________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: www.initd.in > / > / > / > /RHCE, VCE-CIA, RACKSPACE CLOUD U Certified/ > > > > From rcritten at redhat.com Fri Oct 30 13:36:43 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 09:36:43 -0400 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: <563365CF.2010106@redhat.com> References: <563365CF.2010106@redhat.com> Message-ID: <5633726B.5080805@redhat.com> Martin Basti wrote: > > > On 30.10.2015 11:54, Yogesh Sharma wrote: >> Additionally, On Replica UI, I am getting below Error Message: >> >> >> IPA Error 4301: CertificateOperationError >> >> Certificate operation cannot be completed: Unable to communicate with >> CMS (Not Found) >> > Hello, can you check /var/log/httpd/error_log if there is a detailed info? Apache proxies CA requests. Not Found generally means that the CA is not running or the CA web app wasn't registered. Check the pki logs in /var/log/pki. rob From rcritten at redhat.com Fri Oct 30 13:42:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 09:42:26 -0400 Subject: [Freeipa-users] Wrong time / constantly expired passwords In-Reply-To: References: <562FE286.4050401@redhat.com> <5630D146.9040300@redhat.com> Message-ID: <563373C2.2090909@redhat.com> urgrue wrote: > Here are some examples: > > [root at mule ~]# ipa user-status freddie > ----------------------- > Account disabled: False > ----------------------- > Server: mule.bulb > Failed logins: 0 > Last successful authentication: 2015-10-28T09:03:48Z > Last failed authentication: 2015-10-28T09:03:40Z > Time now: 2015-10-28T18:05:51Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at mule ~]# ipa user-show freddie > User login: freddie > First name: fred > Last name: orispaa > Home directory: /home/freddie > Login shell: /bin/sh > UID: 50001 > GID: 50001 > Account disabled: False > Password: True > Member of groups: admins, ipausers > Indirect Member of Sudo rule: allow_all > Kerberos keys available: True > SSH public key fingerprint: > DA:54:C4:27:3A:23:00:AE:AE:60:B7:1B:E1:E4:03:C5 > freddie at mule (ssh-rsa) > > With SSH: > > [root at mule ~]$ ssh freddie at mule > freddie at mule's password: > Password expired. Change your password now. > Last login: Wed Oct 28 10:03:44 2015 from 127.0.0.1 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user freddie. > Current Password: > New password: > Retype new password: > passwd: Authentication token is no longer valid; new one required > Connection to mule closed. > > (Now if I login again, the same process repeats, except the password has > indeed changes) > > With su the output is less informative: > [jj at mule ~]$ su - freddie > Password: > Password expired. Change your password now. > Current Password: > New password: > Retype new password: > su: incorrect password > > (the password was correct and it HAS changed even though the output > implies I entered the wrong current password). > > Doing kinit: > > -sh-4.1$ id > uid=50001(freddie) gid=50001(freddie) groups=50001(freddie),50000(admins) > -sh-4.1$ klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_50001) > -sh-4.1$ kinit > Password for freddie at BULB: > Password expired. You must change it now. > Enter new password: > Enter it again: > kinit: Password has expired while getting initial credentials > -sh-4.1$ klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_50001) > > (again the password HAS changed) > > In case it's of any relevance, note that root has no issue with kerberos > credentials: > [root at mule ~]# kinit admin > Password for admin at BULB: > [root at mule ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at BULB > > Valid starting Expires Service principal > 10/28/15 19:14:56 10/29/15 19:14:53 krbtgt/BULB at BULB I don't see this as root vs other users, you are using a different principal. This makes me wonder if the password policy is strange. You might also want to kinit as freddie and go through the password reset again, then search LDAP for freddie's password expiration: $ ldapsearch -Y GSSAPI -s base -b uid=freddie,cn=users,cn=accounts,dc=example,dc=com krbPasswordExpiration And check out freddie's password policy: $ ipa pwpolicy-show --user freddie rob > > > > On Wed, Oct 28, 2015 at 2:44 PM, Rob Crittenden > wrote: > > urgrue wrote: > > Didn't realize it was GMT, so OK that's not the issue. Any suggestions > > on how to debug it? Everything looks OK, but passwords are just > > perma-expired at all times. > > Need more info on what you're seeing and how the passwords are being > changed. > > rob > > > > > > > On Tue, Oct 27, 2015, 21:45 Rob Crittenden > > >> wrote: > > > > urgrue wrote: > > > Hi, > > > On a new install, I'm being forced a password reset on every > > login. Not > > > sure why but this doesn't look right: > > > > > > # date > > > Tue Oct 27 21:02:57 CET 2015 > > > > > > # ipa user-status blah1 > > > > > > Last successful authentication: 2015-10-27T19:34:53Z > > > Last failed authentication: 2015-10-27T19:34:20Z > > > Time now: 2015-10-27T20:03:00Z > > > > > > Where is it getting this wrong time from? > > > > What's wrong with the time? CET is one hour behind GMT right? > That is > > reflected by the difference between the output of date and > "Time now". > > > > Passwords administratively reset must be set by the user > during the > > first authentication. If the password needs further reset then > yeah, > > something is wrong, but the above looks ok. > > > > rob > > > > From rcritten at redhat.com Fri Oct 30 13:47:39 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 09:47:39 -0400 Subject: [Freeipa-users] Sync IPA and AD while using external CA In-Reply-To: References: <5630D2B6.7080506@redhat.com> Message-ID: <563374FB.7030302@redhat.com> Please keep responses on the list mitra dehghan wrote: > Thank you for your response. > -First of all in section 15.5.1 of Red hat Enterprise Linux 6 Identity > Management guide it says to copy both ad and IPA certificates in > /etc/openldap/certs and i did the same. of course it worked when i was > using internal CAs. Ok, it doesn't hurt anything, but for the purposes of ipa-replica-manage it is a no-op. > - I pass ad certificate in ipa-replica-manage command via --cacert switch. Yes but which cert did you provider, the root CA contoso.com or the subordinate CA local.dc? > - After all I would be glad if you could give me more info about NSS > database. Is that kind of substitute for /etc/openldap/certs? would you > please give me more details about configurations needed for that? The crypto library that 389-ds uses is NSS. This uses a database to store certificates and keys rather than discrete files. The certutil tool is used to manage this file (there is a brief man page). ipa-replica-manage will add the AD cert to 389-ds for you, but you can add certs manually and I think it might help in this case: # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "contoso.com CA" -t CT,, -a -i /path/to/contoso.pem # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "local.dc CA" -t CT,, -a -i /path/to/localdc.pem The -n option specifies a "nickname" to use for the certificate. You can use pretty much anything you want but being descriptive helps. rob > > > > On Wed, Oct 28, 2015 at 5:20 PM, Rob Crittenden > wrote: > > mitra dehghan wrote: > > hello, > > I want to implement and IPA server and Sync it with my 2012 ms ad. > While > > things go well using an internal CA in each server, I came across kind > > of problem when I want integrate solution with my PKI which is already > > serving the AD server. > > I can install IPA with --external-ca switch. but when it comes to > Sync. > > agreement it says "TLS error -8179:Peer's Certificate issuer is not > > recognized." > > > > The architecture is: > > - There is a root CA named contoso.com > > > - There is a subordinate CA named local.dc > > - The certificates of AD and IPA server are both issued by local.dc > > - IPA's certificate is issued based on the CSR file generated by > > ipa-server-install > > - I have copied both certificates in /etc/openldap/certs directory and > > the rest was same as what i did in the internal CA scenario. > > > > while the FreeIPA docs say both servers must have internal CA's i need > > to integrate solution with available PKI. > > I would be glad hear suggestions if this scenario is applicable > and what > > is wrong there. > > thank you > > 389-ds doesn't use /etc/openldap/certs. > > What cert are you passing in when creating the winsync agreement using > ipa-replica-manage? > > You may need/want to add these certs to the IPA 389-ds NSS database > prior to setting up the agreement. > > rob > > > > > -- > m-dehghan From rcritten at redhat.com Fri Oct 30 13:52:10 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 09:52:10 -0400 Subject: [Freeipa-users] IPA with external CA signed certs In-Reply-To: <5630F99D.2080402@jmips.co.uk> References: <561FC1D8.7040807@jmips.co.uk> <56254D39.3000303@redhat.com> <562E412E.6030504@jmips.co.uk> <562E509A.8030506@redhat.com> <5630F99D.2080402@jmips.co.uk> Message-ID: <5633760A.7050000@redhat.com> James Masson wrote: > > > On 26/10/15 16:11, Martin Kosek wrote: >> On 10/26/2015 04:05 PM, James Masson wrote: >>> >>> >>> On 19/10/15 21:06, Rob Crittenden wrote: >>>> James Masson wrote: >>>>> >>>>> Hi list, >>>>> >>>>> I successfully have IPA working with CA certs signed by an upstream >>>>> Dogtag. >>>>> >>>>> Now I'm trying to use a CA cert signed by a different type of CA - >>>>> Vault. >>>>> >>>>> Setup fails, using the same 2 step IPA setup process as used with >>>>> upstream Dogtag. I've also tried the external-ca-type option. >>>>> >>>>> Likely, IPA doesn't like the certificate - however, I can't >>>>> pinpoint why. >>>> >>>> I'm guessing you don't include the entire CA certchain of Vault. Dogtag >>>> is failing to startup because it can't verify its own cert chain: >>>> >>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>> CAPresence: CA is present >>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>> SystemCertsVerification: system certs verification failure >>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1] >>>> SelfTestSubsystem: The CRITICAL self test plugin called >>>> selftests.container.instance.SystemCertsVerification running at startup >>>> FAILED! >>>> >>>> rob >>>> >>> >>> >>> Hi Rob, >>> >>> Thanks for the reply. >>> >>> I do present the IPA installer with both the CA and the IPA cert - >>> the IPAs >>> python-based install code is happy with the cert chain, but the Java >>> based >>> dogtag code chokes on it. >>> >>> OpenSSL is happy with it too. >>> >>> ##### >>> [root at foo ~]# openssl verify ipa.crt >>> ipa.crt: O = LOCAL, CN = Certificate Authority >>> error 20 at 0 depth lookup:unable to get local issuer certificate >>> >>> [root at foo ~]# openssl verify -CAfile vaultca.crt ipa.crt >>> ipa.crt: OK >>> ### >>> >>> Any hints on how to reproduce this with more debug output? I'd like >>> to know >>> exactly what Dogtag doesn't like about the certificate. >>> >>> thanks >>> >>> James M >> >> Let me CC at least Jan Ch. and David, they may be able to help and >> should also >> make sure FreeIPA gets better in validating the certs, as appropriate. >> > > Any thoughts guys? I cc'd one of the dogtag guys to see if he knows. You might also try using certutil to validate the certificates, it might give you some hints to what is going on. I'm assuming your certdb (it can vary by version) is in /var/lib/pki/pki-tomcat/alias certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list of certificates installed. You can verify each one to see what is going on. The -u flag specfies usage. See the certutil man page for a full set of options. For example: # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-ca' certutil: certificate is valid rob From sbose at redhat.com Fri Oct 30 14:02:56 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 30 Oct 2015 15:02:56 +0100 Subject: [Freeipa-users] FreeIPA dogtag pkinit In-Reply-To: <56323371.5020800@nbs-system.com> References: <56323371.5020800@nbs-system.com> Message-ID: <20151030140256.GA981@p.redhat.com> On Thu, Oct 29, 2015 at 03:55:45PM +0100, Jean 'clark' EYMERIT wrote: > Hello, > > I search a way to use pkinit > (http://web.mit.edu/kerberos/krb5-devel/doc/admin/pkinit.html) with > FreeIPA (even without dogtag). > > Can someone give me a howto for this ? I can follow the steps described in the MIT pkinit instructions from above. Besides creating the needed certificates you only have to modify krb5.conf on the IPA server and client. The kadmin steps are not needed here because pre-authentication is already requeired for all IPA users. > > On the official documentation and the ML archive, I only find some > references about the disabled feature because of the dogtag incompatibility. yes, this was mainly done because there are special requirements on the certificates as can been seen from the MIT document, which where hard to meet to at the time. With the latest version of FreeIPA we now have certificate profiles which should allow an automatic pkinit setup in future versions of IPA. My plan is to check what is needed here during the next weeks. HTH bye, Sumit > > Some links after my search : > https://github.com/encukou/freeipa/blob/master/ipalib/plugins/pkinit.py > https://www.redhat.com/archives/freeipa-devel/2010-November/msg00348.html > https://www.redhat.com/archives/freeipa-devel/2011-January/msg00906.html > > The only intersting thing I know, it's this doc to create FreeIPA server > without Dogtag : > https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/creating-server.html > > Thanks you in advance for any information on the subject. > > -- > Jean Eymerit > > > -- > 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 From abokovoy at redhat.com Fri Oct 30 14:19:53 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 30 Oct 2015 16:19:53 +0200 Subject: [Freeipa-users] FreeIPA and Samba4 In-Reply-To: <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> References: <349584507.7504720.1445954033510.JavaMail.zimbra@casalogic.dk> <20151030100239.GM8374@redhat.com> <204710737.7910917.1446200538283.JavaMail.zimbra@casalogic.dk> <20151030102842.GP8374@redhat.com> <1975552361.7912045.1446204514766.JavaMail.zimbra@casalogic.dk> <20151030114042.GQ8374@redhat.com> <1314787676.7913179.1446208645219.JavaMail.zimbra@casalogic.dk> <20151030124834.GR8374@redhat.com> <1474746706.7914109.1446211171202.JavaMail.zimbra@casalogic.dk> Message-ID: <20151030141953.GU8374@redhat.com> On Fri, 30 Oct 2015, Troels Hansen wrote: > > > >> I think it should be >> add:nsslapd-basedn: cn=accounts,$SUFFIX >> not >> add:basedn:"cn=accounts,$SUFFIX" >> >> this is what sidgen task expects and it returns constraint violation >> error if parameters are wrong: >> >> str = fetch_attr(e, "nsslapd-basedn", NULL); >> if (str == NULL) { >> LOG_FATAL("Missing nsslapd-basedn!\n"); >> *returncode = LDAP_CONSTRAINT_VIOLATION; >> ret = SLAPI_DSE_CALLBACK_ERROR; >> goto done; >> } >> > >I think you are right. >Don't know what I have tested, but it brings me a different error, that I didn't see before: > >ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} >ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations error: >ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The ipa-ldap-updater command was successful > >Where did you find the source for the sidgen task? I could try looking at at it myself, but can't find it. You can check it here: https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221 -- / Alexander Bokovoy From yks0000 at gmail.com Fri Oct 30 16:21:58 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 30 Oct 2015 21:51:58 +0530 Subject: [Freeipa-users] IPA Replication not working for User and DNS In-Reply-To: <5633726B.5080805@redhat.com> References: <563365CF.2010106@redhat.com> <5633726B.5080805@redhat.com> Message-ID: Thanks Rob & Martin. I will check in Logs. However when I checked last time I noticed that "pki-tomcat" service was not present in ipactl status output on replica server. Connectivity between master (ipa-inf-prd-ng2-01) and slave (02) is their , able to do telnet/nc on 389 686 from slave to master and vice versa. -Yogesh Sharma (Sent from my HTC) On 30-Oct-2015 7:06 pm, "Rob Crittenden" wrote: > Martin Basti wrote: > > > > > > On 30.10.2015 11:54, Yogesh Sharma wrote: > >> Additionally, On Replica UI, I am getting below Error Message: > >> > >> > >> IPA Error 4301: CertificateOperationError > >> > >> Certificate operation cannot be completed: Unable to communicate with > >> CMS (Not Found) > >> > > Hello, can you check /var/log/httpd/error_log if there is a detailed > info? > > Apache proxies CA requests. Not Found generally means that the CA is not > running or the CA web app wasn't registered. Check the pki logs in > /var/log/pki. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Gronde at fincen.gov Fri Oct 30 18:03:25 2015 From: Christopher.Gronde at fincen.gov (Gronde, Christopher (Contractor)) Date: Fri, 30 Oct 2015 18:03:25 +0000 Subject: [Freeipa-users] Exporting ipa LDAP DB Message-ID: <2909CC7109523F4BA968E7A201471B7718286ED2@hqexdb01.hqfincen.gov> We have had huge issues with our ipa servers which has left some of our applications offline. We want to stand up a temporary OpenLDAP server to transfer the users to until we can get IPA back online. Is there a way to export the ipa LDAP DB so that I can migrate the users into openldap? V/r Chris Gronde (CTR) Navstar, INC. Linux Systems Administrator Network Monitoring Engineer Financial Crimes Enforcement Network (FinCEN) Technology Solutions and Services Division (TSSD) Tel: 703-905-3578 Cell: 571-318-7743 Office: 2041K -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Fri Oct 30 18:56:14 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 30 Oct 2015 19:56:14 +0100 Subject: [Freeipa-users] could anybody give an update on the multitenancy status for freeipa ? Message-ID: Hello all, It has been a while since I asked this before. Multitenancy was put in the freezer back then in favor of this nice project : https://fedorahosted.org/ipsilon/wiki/Releases/v1.0.0 errrr 1.0.2 Darn...I failed to pay attention a little and suddenly 1.1.1 is peeking around the corner already. Now that ipsilon has reached 1.0.0, is there a change regarding the possibility for multitenancy ? http://www.freeipa.org/page/V3/Multitenancy Cheers Rob Verduijn From rcritten at redhat.com Fri Oct 30 19:14:27 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 15:14:27 -0400 Subject: [Freeipa-users] could anybody give an update on the multitenancy status for freeipa ? In-Reply-To: References: Message-ID: <5633C193.6060803@redhat.com> Rob Verduijn wrote: > Hello all, > > It has been a while since I asked this before. > > Multitenancy was put in the freezer back then in favor of this nice project : > https://fedorahosted.org/ipsilon/wiki/Releases/v1.0.0 errrr 1.0.2 > Darn...I failed to pay attention a little and suddenly 1.1.1 is > peeking around the corner already. > > Now that ipsilon has reached 1.0.0, is there a change regarding the > possibility for multitenancy ? > http://www.freeipa.org/page/V3/Multitenancy I'm not sure how Ipsilon releases and IPA multitenancy are inter-related. rob From rcritten at redhat.com Fri Oct 30 19:27:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2015 15:27:26 -0400 Subject: [Freeipa-users] Exporting ipa LDAP DB In-Reply-To: <2909CC7109523F4BA968E7A201471B7718286ED2@hqexdb01.hqfincen.gov> References: <2909CC7109523F4BA968E7A201471B7718286ED2@hqexdb01.hqfincen.gov> Message-ID: <5633C49E.706@redhat.com> Gronde, Christopher (Contractor) wrote: > We have had huge issues with our ipa servers which has left some of our > applications offline. We want to stand up a temporary OpenLDAP server > to transfer the users to until we can get IPA back online. Is there a > way to export the ipa LDAP DB so that I can migrate the users into openldap? A pretty drastic step that could open another can of worms, but you'd want to do something like: # service service dirsrv stop EXAMPLE-COM # /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif -n userRoot The output will contain a pointer to the LDIF it produces. Be forewarned it is going to contain a slew of IPA and 389-ds specific elements you'll need to filter out. Also be very careful with this file as it not only contains the user password hashes for all your users but also the Kerberos master key. rob > > > > V/r > > Chris Gronde (CTR) > > Navstar, INC. > > Linux Systems Administrator > > Network Monitoring Engineer > > Financial Crimes Enforcement Network (FinCEN) > > Technology Solutions and Services Division (TSSD) > > Tel: 703-905-3578 > > Cell: 571-318-7743 > > Office: 2041K > > > > > From rob.verduijn at gmail.com Fri Oct 30 19:34:47 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 30 Oct 2015 20:34:47 +0100 Subject: [Freeipa-users] could anybody give an update on the multitenancy status for freeipa ? In-Reply-To: <5633C193.6060803@redhat.com> References: <5633C193.6060803@redhat.com> Message-ID: 2015-10-30 20:14 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: >> Hello all, >> >> It has been a while since I asked this before. >> >> Multitenancy was put in the freezer back then in favor of this nice project : >> https://fedorahosted.org/ipsilon/wiki/Releases/v1.0.0 errrr 1.0.2 >> Darn...I failed to pay attention a little and suddenly 1.1.1 is >> peeking around the corner already. >> >> Now that ipsilon has reached 1.0.0, is there a change regarding the >> possibility for multitenancy ? >> http://www.freeipa.org/page/V3/Multitenancy > > I'm not sure how Ipsilon releases and IPA multitenancy are inter-related. > > rob > The answer from Dimitri in this mailthread from some time ago is why I thought so. https://www.redhat.com/archives/freeipa-users/2015-February/msg00339.html Rob Verduijn From rcritten at redhat.com Sat Oct 31 04:25:01 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 31 Oct 2015 00:25:01 -0400 Subject: [Freeipa-users] could anybody give an update on the multitenancy status for freeipa ? In-Reply-To: References: <5633C193.6060803@redhat.com> Message-ID: <5634429D.90003@redhat.com> Rob Verduijn wrote: > 2015-10-30 20:14 GMT+01:00 Rob Crittenden : >> Rob Verduijn wrote: >>> Hello all, >>> >>> It has been a while since I asked this before. >>> >>> Multitenancy was put in the freezer back then in favor of this nice project : >>> https://fedorahosted.org/ipsilon/wiki/Releases/v1.0.0 errrr 1.0.2 >>> Darn...I failed to pay attention a little and suddenly 1.1.1 is >>> peeking around the corner already. >>> >>> Now that ipsilon has reached 1.0.0, is there a change regarding the >>> possibility for multitenancy ? >>> http://www.freeipa.org/page/V3/Multitenancy >> >> I'm not sure how Ipsilon releases and IPA multitenancy are inter-related. >> >> rob >> > > The answer from Dimitri in this mailthread from some time ago is why I > thought so. > https://www.redhat.com/archives/freeipa-users/2015-February/msg00339.html I think IPA to IPA trusts is mostly what he meant. I'm still not sure how SAML is related to multi-tenancy. Watch https://fedorahosted.org/freeipa/ticket/4867 for movement on IPA to IPA trust. rob From mitra.dehghan at gmail.com Sat Oct 31 08:07:55 2015 From: mitra.dehghan at gmail.com (mitra dehghan) Date: Sat, 31 Oct 2015 11:37:55 +0330 Subject: [Freeipa-users] Sync IPA and AD while using external CA In-Reply-To: <563374FB.7030302@redhat.com> References: <5630D2B6.7080506@redhat.com> <563374FB.7030302@redhat.com> Message-ID: Dear Rob, Thanks for your response: > Yes but which cert did you provider, the root CA contoso.com or the subordinate CA local.dc? Actually I was using active directory's certificate with --cacert switch in ipa-replica-manage Thanks to info you gave me about NSS I changed the approach. first: using certutil, I manually added root CA (contoso.com) and subordinate(local.dc) certificates in /etc/dirsrv/slapd-REALM database # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "contoso.com CA" -t CT,, -a -i /path/to/contoso.pem # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "local.dc CA" -t CT,, -a -i /path/to/localdc.pem then, following same approach, I added Active directory's certificate to the same db. # certutil -A -d /etc/dirsrv/slapd-YOUR-REALM -n "active directory CA" -t ,, -a -i /path/to/ad.cer Note: since the original certificates were in .cer format and its same as .pem I just renamed certificates to .pem Now my db has 5 certificates in: a) root CA certificate (contoso.com) b) Subordinate CA (local.dc): issued to local.dc by contoso.com c) Active directory CA (ad): issued to active directory by local.dc d)IPA certificate:issued to IPA server by local.dc e)localhost certificate: issued to localhost by IPA server 's internal CA. finally I ran ipa-replica-manage: - using contoso.com CA in --cacert it says TLS error -8179: Peer's Certificate issuer is not recognized -using local.dc CA in --cacert it says TLS error -8157: Certificate extension not found. -using Active Directory CA in --cacert it says TLS error -8179: Peer's Certificate issuer is not recognized I would be glad if you help me more with this issue! On Fri, Oct 30, 2015 at 5:17 PM, Rob Crittenden wrote: > Please keep responses on the list > > mitra dehghan wrote: > > Thank you for your response. > > -First of all in section 15.5.1 of Red hat Enterprise Linux 6 Identity > > Management guide it says to copy both ad and IPA certificates in > > /etc/openldap/certs and i did the same. of course it worked when i was > > using internal CAs. > > Ok, it doesn't hurt anything, but for the purposes of ipa-replica-manage > it is a no-op. > > > > - I pass ad certificate in ipa-replica-manage command via --cacert > switch. > > Yes but which cert did you provider, the root CA contoso.com or the > subordinate CA local.dc? > > > - After all I would be glad if you could give me more info about NSS > > database. Is that kind of substitute for /etc/openldap/certs? would you > > please give me more details about configurations needed for that? > > The crypto library that 389-ds uses is NSS. This uses a database to > store certificates and keys rather than discrete files. The certutil > tool is used to manage this file (there is a brief man page). > > ipa-replica-manage will add the AD cert to 389-ds for you, but you can > add certs manually and I think it might help in this case: > > # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "contoso.com CA" -t > CT,, -a -i /path/to/contoso.pem > # certutil -A -d /etc/dirsrc/slapd-YOUR-REALM -n "local.dc CA" -t CT,, > -a -i /path/to/localdc.pem > > The -n option specifies a "nickname" to use for the certificate. You can > use pretty much anything you want but being descriptive helps. > > rob > > > > > > > > > On Wed, Oct 28, 2015 at 5:20 PM, Rob Crittenden > > wrote: > > > > mitra dehghan wrote: > > > hello, > > > I want to implement and IPA server and Sync it with my 2012 ms ad. > > While > > > things go well using an internal CA in each server, I came across > kind > > > of problem when I want integrate solution with my PKI which is > already > > > serving the AD server. > > > I can install IPA with --external-ca switch. but when it comes to > > Sync. > > > agreement it says "TLS error -8179:Peer's Certificate issuer is not > > > recognized." > > > > > > The architecture is: > > > - There is a root CA named contoso.com > > > > > - There is a subordinate CA named local.dc > > > - The certificates of AD and IPA server are both issued by local.dc > > > - IPA's certificate is issued based on the CSR file generated by > > > ipa-server-install > > > - I have copied both certificates in /etc/openldap/certs directory > and > > > the rest was same as what i did in the internal CA scenario. > > > > > > while the FreeIPA docs say both servers must have internal CA's i > need > > > to integrate solution with available PKI. > > > I would be glad hear suggestions if this scenario is applicable > > and what > > > is wrong there. > > > thank you > > > > 389-ds doesn't use /etc/openldap/certs. > > > > What cert are you passing in when creating the winsync agreement > using > > ipa-replica-manage? > > > > You may need/want to add these certs to the IPA 389-ds NSS database > > prior to setting up the agreement. > > > > rob > > > > > > > > > > -- > > m-dehghan > > -- m-dehghan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Sat Oct 31 17:54:28 2015 From: fujisan43 at gmail.com (Fujisan) Date: Sat, 31 Oct 2015 18:54:28 +0100 Subject: [Freeipa-users] What is the recommended procedure for upgrading clients and servers to F23? Message-ID: Hi there, F23 is coming out very soon and I'm wondering what machine I should upgrade first, the spa clients or the ipa servers? In other words, can the ipa system work with ipa client upgraded to 4.2 and the servers still at 4.1.4? Or do I have to upgrade the servers first? And should I upgrade to freeipa 4.2 first and then upgrade the machines to F23? Regards, Fuji. -------------- next part -------------- An HTML attachment was scrubbed... URL: