[Freeipa-users] Trusted Realm Across IPA Servers

[Eldo Joseph]

Hi All,
I have requirement to access the service under different IPA servers, can some 
one help me on this... 
IPA Servers are running on V3. 
-Eldo--- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Forest trust and AD child domain

[Manuel Lopes]

Hi Sumit,

Thank you very much for the prompt reply

[root@support1 ~]# ipa trustdomain-find windows.com
  Domain name: windows.com
  Domain NetBIOS name: WINDOWS
  Domain Security Identifier: S-1-5-21-1701591335-3855227394-3044674468
  Domain enabled: True

  Domain name: acme.windows.com
  Domain NetBIOS name: ACME
  Domain Security Identifier: S-1-5-21-1215373191-1991333051-3772904882
  Domain enabled: True

Number of entries returned 2


[root@support1 ~]# ipa trust-fetch-domains windows.com
---
No new trust domains were found
---

Number of entries returned 0


Regards
Le 11 déc. 2014 20:08, "Sumit Bose" > a écrit :

> On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
> >  Hello,
> >
> >
> > We have been following the AD integration guide for IPAv3:
> > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> >
> >
> >
> > Our setup is:
> >
> > • 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
> >  as Forest Root Domain and acme.windows.com
> >  as transitive child domain
> >
> > • RHEL7 as IPA server with domain: linux.com
> > 
> >
> >
> >
> > We have established a forest trust between windows.com and linux.com and
> > everything seems OK from an IPA perspective.
> >
> >
> >
> > We can work with Kerberos tickets without any issue from “windows” domain
> > or his child domain “acme”. (kinit, kvno…)
> >
> >
> >
> > When we use samba tools, the following command is working fine.
> >
> > *[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> >
> > *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> >
> >
> >
> > But, the same command against the acme domain returns an error.
> >
> > *[root@support1 ]# wbinfo -n 'ACME\Domain Admins'*
> >
> > *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> >
> > *Could not lookup name ACME\Domain Admins*
> >
> >
> >
> > Same problem with the following command:
> >
> > *[root@support1]# ipa group-add-member ad_users_external --external
> > "ACME\Domain Users"*
> >
> > *[member user]:*
> >
> > *[member group]:*
> >
> > *  Group name: ad_users_external*
> >
> > *  Description: AD users external map*
> >
> > *  External member: *
> >
> > *  Member of groups: ad_users*
> >
> > *  Failed members:*
> >
> > *member user:*
> >
> > *member group: ACME\Domain Users: Cannot find specified domain or
> > server name*
> >
> > *-*
> >
> > *Number of members added 0*
> >
> >
> >
> >
> >
> > Any help would be appreciated
>
> Does
>
> ipa trustdomain-find windows.com
>
> show acme.windows.com as well ?
>
> Does
>
> ipa trust-fetch-domains ad.devel
>
> help to retrieve the child domain?
>
> Please note that if acme.windows.com now shows up you might have to wait
> 1-2 minutes until SSSD's negative caches are flushed and the new domains
> is discovered by SSSD, as an alternative you can just restart SSSD.
>
> HTH
>
> bye,
> Sumit
>
> >
> >
> >
> > Regards
>
> > --
> > 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

Re: [Freeipa-users] Host based 2FA ?

[Dmitri Pal]

On 12/11/2014 06:32 PM, free...@pettyvices.com wrote:


I'd like to be able to require 2FA on *certain* hosts and allow just 
passwords on others.


It seems you can check both "passwords" and "2FA" under the user.

I was hoping I could create a HBAC such that certain hosts would only 
allow 2FA, but I can't see an obvious way to do that.


Is it possible?  Help on how would be great.  If not, feature request?

thanks,

-t


We have several tickets:

https://fedorahosted.org/freeipa/ticket/433

https://fedorahosted.org/freeipa/ticket/3659

https://fedorahosted.org/freeipa/ticket/4498

If you see https://fedorahosted.org/freeipa/ticket/4498#comment:6 we 
discussed this use case.
And I was about to fork it as said but then I realized that there is not 
good way on the KDC to determine the host you are coming from.

So IMO it should be a policy decision on SSSD.
There are two options:
- short term solution: allow SSSD to have a local overwrite to require 
OTP if server offers different options.
- longer term solution: actually have a per host policy that is 
centrally managed that is fetched per host and enforced by SSSD.


Before filing tickets I would like to hear opinions on the matter.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Host based 2FA ?

[freeipa]

I'd like to be able to require 2FA on *certain* hosts and allow just 
passwords on others.


It seems you can check both "passwords" and "2FA" under the user.

I was hoping I could create a HBAC such that certain hosts would only 
allow 2FA, but I can't see an obvious way to do that.


Is it possible?  Help on how would be great.  If not, feature request?

thanks,

-t

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] Forest trust and AD child domain

[Sumit Bose]

On Thu, Dec 11, 2014 at 06:45:49PM +0100, Manuel Lopes wrote:
>  Hello,
> 
> 
> We have been following the AD integration guide for IPAv3:
> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
> 
> 
> 
> Our setup is:
> 
> • 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
>  as Forest Root Domain and acme.windows.com
>  as transitive child domain
> 
> • RHEL7 as IPA server with domain: linux.com
> 
> 
> 
> 
> We have established a forest trust between windows.com and linux.com and
> everything seems OK from an IPA perspective.
> 
> 
> 
> We can work with Kerberos tickets without any issue from “windows” domain
> or his child domain “acme”. (kinit, kvno…)
> 
> 
> 
> When we use samba tools, the following command is working fine.
> 
> *[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*
> 
> *S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*
> 
> 
> 
> But, the same command against the acme domain returns an error.
> 
> *[root@support1 ]# wbinfo -n 'ACME\Domain Admins'*
> 
> *failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*
> 
> *Could not lookup name ACME\Domain Admins*
> 
> 
> 
> Same problem with the following command:
> 
> *[root@support1]# ipa group-add-member ad_users_external --external
> "ACME\Domain Users"*
> 
> *[member user]:*
> 
> *[member group]:*
> 
> *  Group name: ad_users_external*
> 
> *  Description: AD users external map*
> 
> *  External member: *
> 
> *  Member of groups: ad_users*
> 
> *  Failed members:*
> 
> *member user:*
> 
> *member group: ACME\Domain Users: Cannot find specified domain or
> server name*
> 
> *-*
> 
> *Number of members added 0*
> 
> 
> 
> 
> 
> Any help would be appreciated

Does

ipa trustdomain-find windows.com

show acme.windows.com as well ?

Does

ipa trust-fetch-domains ad.devel

help to retrieve the child domain?

Please note that if acme.windows.com now shows up you might have to wait
1-2 minutes until SSSD's negative caches are flushed and the new domains
is discovered by SSSD, as an alternative you can just restart SSSD.

HTH

bye,
Sumit

> 
> 
> 
> Regards

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go To http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Forest trust and AD child domain

[Manuel Lopes]

 Hello,


We have been following the AD integration guide for IPAv3:
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup



Our setup is:

• 2 domain controllers with Windows 2008 R2 AD DC -> windows.com
 as Forest Root Domain and acme.windows.com
 as transitive child domain

• RHEL7 as IPA server with domain: linux.com




We have established a forest trust between windows.com and linux.com and
everything seems OK from an IPA perspective.



We can work with Kerberos tickets without any issue from “windows” domain
or his child domain “acme”. (kinit, kvno…)



When we use samba tools, the following command is working fine.

*[root@support1 ]# wbinfo -n 'WINDOWS\Domain Admins'*

*S-1-5-21-1701591335-3855227394-3044674468-512 SID_DOM_GROUP (2)*



But, the same command against the acme domain returns an error.

*[root@support1 ]# wbinfo -n 'ACME\Domain Admins'*

*failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND*

*Could not lookup name ACME\Domain Admins*



Same problem with the following command:

*[root@support1]# ipa group-add-member ad_users_external --external
"ACME\Domain Users"*

*[member user]:*

*[member group]:*

*  Group name: ad_users_external*

*  Description: AD users external map*

*  External member: *

*  Member of groups: ad_users*

*  Failed members:*

*member user:*

*member group: ACME\Domain Users: Cannot find specified domain or
server name*

*-*

*Number of members added 0*





Any help would be appreciated



Regards
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

[Freeipa-users] Replica re-initialization

[Matt Chesler]

I have a cluster of four IPA masters that should be performing fully meshed
replication.  I discovered yesterday that a recently created user only
existed on a single master.  After looking through all four masters, it
appears that several recent updates only exist on one of the masters.  I do
not see any replication errors in any of the logs, but I'm not 100% sure
how far back this issue goes.  I do believe the one master with up-to-date
data is a reliable representation of what the LDAP directory should look
like.  I ran a reinitialize command (ipa-replica-manage re-initialize
--from reliable-server.fqdn) on two of the out-of-date masters yesterday
around 4pm EST.  It's now a little after 12pm EST and the "Update in
progress" message is still scrolling by once a second on both terminals.
I'd greatly appreciate suggestions about a) how to determine the status of
the reinitialize command and b) any other ideas about how to resolve this
issue and monitor for it better in the future.  Thanks in advance for your
help!

Thanks,

Matt
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached

[Ade Lee]

On Tue, 2014-12-09 at 23:52 +0100, chymian wrote:
> Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee:
> 
> > On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> 
> > > hey people,
> 
> > > 
> 
> > > after a successful install of ipa 4.0.5-2 on jessie, the named
> services started flawless during setup. see attached log, Installation
> summary (line 3107)
> 
> > > but after reboot, it refuses to start. (did this install a couple
> times, on vanilla jessie)
> 
> > > 
> 
> > > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but
> not the admin-services on https://ipa.eb8.lan/ca/ee/ca and
> https://ipa.eb8.lan/ca/agent/ca.
> 
> > > 
> 
> > > 
> 
> > > $ systemctl status pki-tomcatd@pki-tomcat.service
> 
> > > ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
> 
> > > Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled)
> 
> > > Active: failed (Result: resources)
> 
> > > 
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server
> pki-tomcat...
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files:
> No such file or directory
> 
> > > Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd@pki-tomcat.service
> failed to run 'start-pre' task: No such file or directory
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server
> pki-tomcat.
> 
> > > Dez 08 20:40:13 ipa systemd[1]: Unit
> pki-tomcatd@pki-tomcat.service entered failed state.
> 
> > > 
> 
> > > 
> 
> > 
> 
> > Is dogtag actually running? ps -ef |grep java
> 
>  
> 
> it shows:
> 
> pkiuser 676 1 0 13:25 ? 00:00:26 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties
>  -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
> -DRESTEASY_LIB=/usr/share/java/ 
> -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath 
> /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-juli.jar
>  -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 
> -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp 
> org.apache.catalina.startup.Bootstrap start
> 
>  
> 
> is it ment to be, that the dogtag-pki package it’s self is not
> installed, just the dogtag-pki-server-theme is
> 
> and a couple pki-packages… pki-base, pki-ca, pki-server, pki-tools?
> 
>  
Ok, so as far as I can see, the dogtag CA is in fact up and operational.
The systemctl error messages are probably a result of the systemd unit
scripts not yet being used.

We clearly see that the IPA RA and Jar signing certs are issued with no
problems.  I do notice a few attempts to reach the agent pages which
result in failed authentication.  My guess is that you are trying to
access these pages using the browser and are not providing the agent
cert.

As you have the dogtag-pki-server-theme package installed, you should be
able to reach the UI.  But ..

-- If you try to access the dogtag UI pages through port 80 and 443,
then you are going through the apache instance for IPA.  This instance
talks to Dogtag on the back-end using AJP, and has a proxy configuration
file that only permits certain URL paths to go through.

-- If you want to access the Dogtag UI pages, you need to access
https://host:8443/... or http://host:8080/...

To access the agent pages, you need to import the IPA RA agent
certificate into your browser (and trust the CA cert).  That cert/key is
in the IPA HTTP certdb.  You will need to extract it from there as a p12
file and import it into your browser.

Ade
> 
>  
> 
> > 
> 
> > You could try restarting it - 
> 
> > systemctl restart pki-tomcatd@pki-tomcat.service
> 
>  
> 
> fails with same log-msg.
> 
>  
> 
> > 
> 
> > The logs should be found in the journal --> 
> 
> > journalctl -u pki-tomcatd@pki-tomcat.service
> 
>  
> 
> same as above.
> 
>  
> 
> > 
> 
> > Other debug logs should be found under /var/log/pki/pki-tomcat/.
> Please
> 
> > provide a tar of that directory.
> 
>  
> 
> attached
> 
>  
> 
> > I am curious what the unit file looks like: On Fedora, its
> 
> >
> at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service
> 
>  
> 
> lrwxrwxrwx 1 pkiuser pkiuser 40 Dez 8 20:22
> pki-tomcatd@pki-tomcat.service
> -> /lib/systemd/system/pki-tomcatd@.service
> 
> root@ipa /etc/systemd/system/pki-tomcatd.target.wants
> 
> $ cat pki-tomcatd@pki-tomcat.service
> 
> [Unit]
> 
> Description=PKI Tomcat Server %i
> 
> After=pki-tomcatd.target network.target
> 
> PartOf=pki-tomcatd.target
> 
>  
> 
> [Service]
> 
> Type=simple
> 
> EnvironmentFile=/etc/tomcat/tomcat.conf
> 
> Environment="NAME=%i"
> 
> EnvironmentFile=-/etc/default/%i
> 
> ExecStartPre=/usr/bin/pkidaemon start %i
> 
> ExecStart=/usr/libexec/tomcat/server start
> 
> ExecStop=/usr/libexec/tomcat/server stop
> 
> SuccessExitStatus=143
> 
> User=pkiuser
> 
> Group=pkiuser
> 
>  
> 
> [Install]
> 
> WantedBy=multi-user.target
> 
>  
> 
>  
> 
> > which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does
> that
> 
> >

Re: [Freeipa-users] freeipa / sudo

[Dmitri Pal]

On 12/11/2014 08:08 AM, Martin Kosek wrote:

On 12/11/2014 01:57 PM, Chris Card wrote:

On 12/11/2014 09:42 AM, Chris Card wrote:

On 12/10/2014 04:54 PM, Chris Card wrote:



On 12/10/2014 12:57 PM, Chris Card wrote:

thanks Martin,

I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa 
server and a freeipa client machine.
I've set up a user with ssh keys, and can successfully ssh onto the client 
machine.
I'm trying to setup sudo rules so that if the user is in a given user group, then the 
user can run "sudo su -" on the client to become root.



[root@fedora21-freeipa log]# ipa hostgroup-show
Host-group: cog
Host-group: cog
Member hosts: ipaclient21.testdomain21.com
Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
Rule name: All
Enabled: TRUE
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: cog_rw
Host Groups: cog
Sudo Option: !authenticate

but this setup doesn't work, i.e. even though the user is in the user group and 
the client machine is in the host group, sudo su - fails. Is this a bug, or 
have I missed something?

Chris




With FreeIPA 4.1.1, client sudo integration should be automatically configured,
so it should just work, including hostgroups. In your case, I would start with
investigating

http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

If that does not help, I bet SSSD devs will ask for logs.


I've done the troubleshooting steps:

[root@ipaclient21 log]# nisdomainname
testdomain21.com
[root@ipaclient21 log]# getent netgroup cog
cog (ipaclient21.testdomain21.com,-,testdomain21.com)

I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, 
but I'm not sure if that's the right file (it didn't exist before).
I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in 
/var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but 
I created /etc/sssd.conf with a line

Debug sudo /var/log/sudo_debug all@debug

and I saw this in the debug output:

Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
Dec 10 15:42:57 sudo[10046] val[0]=+cog
Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

The problem is that the hostname command on the client was returning a short 
hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when 
I forced the hostname to be the FQDN the sudo command worked.


The short hostname comes from the fact that the client machine is an openstack 
instance, and that appears to be a feature of openstack instances :(


So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
this is the case, I am not sure what we could do, sudo somehow needs to learn
the FQDN.


I can set up the instance so that hostname -f returns the FQDN, but the only way I can get 
hostname to return the FQDN is if I explicitly run "hostname "; 
unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.


I found that simply editing /etc/hostname and rebooting didn't work, because 
cloud-init resets the hostname. But if I create the instance with a cloud-init 
script to set the hostname to the FQDN, and then reboot the instance after 
creation, /etc/hostname contains the FQDN and hostname returns the FQDN.

Chris

Ah, right. I just remembered I also need to set it up with cloud-init. This is
the config I use for the FreeIPA demo:

#cloud-config: FreeIPA cloud configuration
hostname: ipa.demo1.freeipa.org
fqdn: ipa.demo1.freeipa.org
manage_etc_hosts: false


Is it worth a howto? Seems like  a valuable piece of info...


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 4.1.2 - NEED HELP WITH 2FA/OTP!!!

[thierry bordaz]

On 12/11/2014 08:56 AM, Niranjan M.R wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/09/2014 11:14 PM, thierry bordaz wrote:

On 12/09/2014 04:07 PM, thierry bordaz wrote:

On 12/09/2014 11:15 AM, thierry bordaz wrote:

On 12/09/2014 10:48 AM, Niranjan M.R wrote:

On 12/09/2014 02:57 PM, thierry bordaz wrote:

Hello,

Niranjan, may I have access to your test machine.


It's a vm on my laptop. I am trying to reproduce on another VM
to which i can give access. I will provide the details of this VM as soon
as possible.

Mean while i am providing ns-slapd access logs, ipa-logs and pkispawn logs.

Something curious is that the installer is waiting for DS to restart but it is 
looking like DS has not received the terminaison signal.

2014-12-09T09:37:49Z DEBUG Waiting for CA to start...
...
2014-12-09T09:42:45Z DEBUG Waiting for CA to start...


[09/Dec/2014:04:37:41 -0500] - Warning: Adding configuration attribute 
"nsslapd-security"

<< here we should expect a restart of DS >>

First why DS did not receive the restart order and then as it is still running 
(DS looks idle) what does the install is waiting for.

 At the end of  the CS configuration, the installer configure ssl DS,  
restart DS it and then reach the ldap to retrieve the CA status. It fails

 pki/pki-tomcat/localhost.2014-12-09.log
 Dec 09, 2014 4:37:49 AM org.apache.catalina.core.StandardWrapperValve 
invoke
 SEVERE: Servlet.service() for servlet [caGetStatus] in context with path 
[/ca] threw exception
 java.io.IOException: CS server is not ready to serve.
 at 
com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299)
 at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57)
 at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193)
 at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
 at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
 at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
 at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
 at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
 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)

 Its fails to reach DS because:
 0.localhost-startStop-1 - [09/Dec/2014:04:37:49 EST] [8] [3] In Ldap 
(bound) connection pool to host  port 636, Cannot connect to LDAP
 server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL 
Socket (-1)

 Having not been able to restart DS, the secure port is not enabled so the 
CA failure after 5min was normal.

 So the remaining question was why the DS service resta

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 01:57 PM, Chris Card wrote:
>> On 12/11/2014 09:42 AM, Chris Card wrote:
>>>
 On 12/10/2014 04:54 PM, Chris Card wrote:
>
>
>>
>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>> thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the 
 client machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run "sudo su -" on the client to become root.
>> 
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris



>>>
>>> With FreeIPA 4.1.1, client sudo integration should be automatically 
>>> configured,
>>> so it should just work, including hostgroups. In your case, I would 
>>> start with
>>> investigating
>>>
>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>
>>> If that does not help, I bet SSSD devs will ask for logs.
>>>
>> I've done the troubleshooting steps:
>>
>> [root@ipaclient21 log]# nisdomainname
>> testdomain21.com
>> [root@ipaclient21 log]# getent netgroup cog
>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>
>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
>> machine, but I'm not sure if that's the right file (it didn't exist 
>> before).
>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
>> stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
>> messages.
>
> I worked out how to set up debug for sudo. sudoers_debug is deprecated 
> now, but I created /etc/sssd.conf with a line
>
> Debug sudo /var/log/sudo_debug all@debug
>
> and I saw this in the debug output:
>
> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
> Dec 10 15:42:57 sudo[10046] val[0]=+cog
> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := 
> false
> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>
> The problem is that the hostname command on the client was returning a 
> short hostname, ipaclient21, instead of a FQDN, 
> ipaclient21.testdomain21.com and when I forced the hostname to be the 
> FQDN the sudo command worked.
>
>
> The short hostname comes from the fact that the client machine is an 
> openstack instance, and that appears to be a feature of openstack 
> instances :(


 So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
 this is the case, I am not sure what we could do, sudo somehow needs to 
 learn
 the FQDN.

>>> I can set up the instance so that hostname -f returns the FQDN, but the 
>>> only way I can get hostname to return the FQDN is if I explicitly run 
>>> "hostname "; unfortunately this doesn't survive a reboot.
>>
>> You should be able to just set the hostname to /etc/hostname (for older
>> platforms, it may also be in /etc/sysconfig/network) and it should survive 
>> the
>> reboot. I do not think that OpenStack really cares that much what hostname 
>> did
>> you set up in the system after the VM is created.
>>
>> At least my OpenStack VM with the FreeIPA demo works this way.
>>
> I found that simply editing /etc/hostname and rebooting didn't work, because 
> cloud-init resets the hostname. But if I create the instance with a 
> cloud-init script to set the hostname to the FQDN, and then reboot the 
> instance after creation, /etc/hostname contains the FQDN and hostname returns 
> the FQDN.
> 
> Chris

Ah, right. I just remembered I also need 

Re: [Freeipa-users] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached

[chymian]

> Am Dienstag, 9. Dezember 2014, 23:52:08 schrieb chymian:
> 
> Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee:
> > On Tue, 2014-12-09 at 13:54 +0100, chymian wrote:
> > > hey people,
> > > 
> > > after a successful install of ipa 4.0.5-2 on jessie, the named services
> > > started flawless during setup. see attached log, Installation summary
> > > (line 3107) but after reboot, it refuses to start. (did this install a
> > > couple times, on vanilla jessie)
> > > 
> > > I can reach & work with Dogtag https://ipa.eb8.lan:8443/ca, but not the
> > > admin-services on https://ipa.eb8.lan/ca/ee/ca and
> > > https://ipa.eb8.lan/ca/agent/ca.
> > > 
> > > 
> > > $ systemctl status pki-tomcatd@pki-tomcat.service
> > > ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
> > > 
> > >Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled)
> > >Active: failed (Result: resources)
> > > 
> > > Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> > > Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No
> > > such file or directory Dez 08 20:40:13 ipa systemd[1]:
> > > pki-tomcatd@pki-tomcat.service failed to run 'start-pre' task: No such
> > > file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI
> > > Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit
> > > pki-tomcatd@pki-tomcat.service entered failed state.> > 
> > Is dogtag actually running?  ps -ef |grep java
> 
> it shows:
> pkiuser676 1  0 13:25 ?00:00:26
> /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.proper
> ties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -DRESTEASY_LIB=/usr/share/java/
> -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath
> /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-jul
> i.jar -Dcatalina.base=/var/lib/pki/pki-tomcat
> -Dcatalina.home=/usr/share/tomcat7
> -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp
> org.apache.catalina.startup.Bootstrap start
> 
> is it ment to be, that the dogtag-pki package it’s self is not installed,
> just the dogtag-pki-server-theme is and a couple pki-packages… pki-base,
> pki-ca, pki-server, pki-tools?
> 
> > You could try restarting it -
> > systemctl restart pki-tomcatd@pki-tomcat.service
> 
> fails with same log-msg.
> 
> > The logs should be found in the journal -->
> > journalctl -u pki-tomcatd@pki-tomcat.service
> 
> same as above.
> 
> > Other debug logs should be found under /var/log/pki/pki-tomcat/.  Please
> > provide a tar of that directory.
> 
> attached
> 
> > I am curious what the unit file looks like:  On Fedora, its
> > at
> > /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.servi
> > ce> 
> lrwxrwxrwx 1 pkiuser pkiuser 40 Dez  8 20:22 pki-tomcatd@pki-tomcat.service
> -> /lib/systemd/system/pki-tomcatd@.service root@ipa
> /etc/systemd/system/pki-tomcatd.target.wants
> $ cat pki-tomcatd@pki-tomcat.service
> [Unit]
> Description=PKI Tomcat Server %i
> After=pki-tomcatd.target network.target
> PartOf=pki-tomcatd.target
> 
> [Service]
> Type=simple
> EnvironmentFile=/etc/tomcat/tomcat.conf
> Environment="NAME=%i"
> EnvironmentFile=-/etc/default/%i
> ExecStartPre=/usr/bin/pkidaemon start %i
> ExecStart=/usr/libexec/tomcat/server start
> ExecStop=/usr/libexec/tomcat/server stop
> SuccessExitStatus=143
> User=pkiuser
> Group=pkiuser
> 
> [Install]
> WantedBy=multi-user.target
> 
> > which points to an EnvironmentFile /etc/tomcat/tomcat.conf.  Does that
> > file exist?
> 
> there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it.
> 
> this is what was installed:
> 
> ii  libtomcat7-java  7.0.56-1
> ii  libtomcatjss-java7.1.1-2
> ii  tomcat7-common   7.0.56-1
> ii  tomcat7-user 7.0.56-1
> 
> and if I would install tomcat7, it would give me an /etc/tomcat7 – not a
> /etc/tomcat
> 
> and, here on debian, there is no such dir. /usr/libexec.
> seems that the unitfile is more a centos one.
> 
> 
> but:
> 
> systemctl status pki-tomcatd.service
> ● pki-tomcatd.service - LSB: Start pki-tomcatd at boot time
> 
>Loaded: loaded (/etc/init.d/pki-tomcatd)
>Active: active (running) since Di 2014-12-09 13:25:12 CET; 10h ago
>CGroup:
>/user.slice/user-0.slice/session-5.scope/system.slice/pki-tomcatd.servic
>e>
>└─676 /usr/lib/jvm/default-java/bin/java
>-Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/log
>ging.properties -Djava.util.log...> 
> Dez 09 13:25:12 ipa pki-tomcatd[484]: .
> Dez 09 13:25:12 ipa systemd[1]: Started LSB: Start pki-tomcatd at boot time.
> 
> 
> which is started with a /etc/init.d/pki-tomcatd script, not
> systemd-unit-file – yet.> 
> > Ade
> 
> thx,
> guenter


hello ade,
what happens next?
is there anything I can provide?

should I open a bug with debian/freeIPA

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

> On 12/11/2014 09:42 AM, Chris Card wrote:
>>
>>> On 12/10/2014 04:54 PM, Chris Card wrote:


>
>> On 12/10/2014 12:57 PM, Chris Card wrote:
> thanks Martin,
>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
>>> freeipa server and a freeipa client machine.
>>> I've set up a user with ssh keys, and can successfully ssh onto the 
>>> client machine.
>>> I'm trying to setup sudo rules so that if the user is in a given user 
>>> group, then the user can run "sudo su -" on the client to become root.
> 
>>> [root@fedora21-freeipa log]# ipa hostgroup-show
>>> Host-group: cog
>>> Host-group: cog
>>> Member hosts: ipaclient21.testdomain21.com
>>> Member of Sudo rule: All
>>> [root@fedora21-freeipa log]# ipa sudorule-show All
>>> Rule name: All
>>> Enabled: TRUE
>>> Command category: all
>>> RunAs User category: all
>>> RunAs Group category: all
>>> User Groups: cog_rw
>>> Host Groups: cog
>>> Sudo Option: !authenticate
>>>
>>> but this setup doesn't work, i.e. even though the user is in the user 
>>> group and the client machine is in the host group, sudo su - fails. Is 
>>> this a bug, or have I missed something?
>>>
>>> Chris
>>>
>>>
>>>
>>
>> With FreeIPA 4.1.1, client sudo integration should be automatically 
>> configured,
>> so it should just work, including hostgroups. In your case, I would 
>> start with
>> investigating
>>
>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>
>> If that does not help, I bet SSSD devs will ask for logs.
>>
> I've done the troubleshooting steps:
>
> [root@ipaclient21 log]# nisdomainname
> testdomain21.com
> [root@ipaclient21 log]# getent netgroup cog
> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>
> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
> machine, but I'm not sure if that's the right file (it didn't exist 
> before).
> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
> stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
> messages.

 I worked out how to set up debug for sudo. sudoers_debug is deprecated 
 now, but I created /etc/sssd.conf with a line

 Debug sudo /var/log/sudo_debug all@debug

 and I saw this in the debug output:

 Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog
 Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
 Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

 The problem is that the hostname command on the client was returning a 
 short hostname, ipaclient21, instead of a FQDN, 
 ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN 
 the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack 
 instances :(
>>>
>>>
>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>>> this is the case, I am not sure what we could do, sudo somehow needs to 
>>> learn
>>> the FQDN.
>>>
>> I can set up the instance so that hostname -f returns the FQDN, but the only 
>> way I can get hostname to return the FQDN is if I explicitly run "hostname 
>> "; unfortunately this doesn't survive a reboot.
>
> You should be able to just set the hostname to /etc/hostname (for older
> platforms, it may also be in /etc/sysconfig/network) and it should survive the
> reboot. I do not think that OpenStack really cares that much what hostname did
> you set up in the system after the VM is created.
>
> At least my OpenStack VM with the FreeIPA demo works this way.
>
I found that simply editing /etc/hostname and rebooting didn't work, because 
cloud-init resets the hostname. But if I create the instance with a cloud-init 
script to set the hostname to the FQDN, and then reboot the instance after 
creation, /etc/hostname contains the FQDN and hostname returns the FQDN.

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

Re: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]

[Martin Kosek]

On 12/10/2014 08:20 PM, Dmitri Pal wrote:
> On 12/10/2014 06:55 AM, Gianluca Cecchi wrote:
>> On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek > > wrote:
>>
>> On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
>> > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi
>> mailto:gianluca.cec...@gmail.com>>
>> > wrote:
>> >
>> >> OK. I will check requirements to write into The wiki
>> >>
>>
>>
>> Hello,
>> now I was able to login and I created this draft page, you can check and feel
>> free to review...
>> http://www.freeipa.org/page/HowTo/vsphere5_integration
> I scanned the page.
> Looks good. Thanks a lot!
> 
> I hope someone with the similar use case can verify the steps.
> 

+1, thanks! I see the page is already linked from

http://www.freeipa.org/page/HowTos#Virtualization

so we are covered on that front.

Martin

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]

[Gianluca Cecchi]

On Thu, Dec 11, 2014 at 10:19 AM, Petr Spacek  wrote:

>
> Link to the how-to was added to:
> http://www.freeipa.org/page/HowTos#Virtualization
>
> --
> Petr^2 Spacek
>
>
>
thanks!
Gianluca
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 09:42 AM, Chris Card wrote:
> 
>> On 12/10/2014 04:54 PM, Chris Card wrote:
>>>
>>>

> On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
>> freeipa server and a freeipa client machine.
>> I've set up a user with ssh keys, and can successfully ssh onto the 
>> client machine.
>> I'm trying to setup sudo rules so that if the user is in a given user 
>> group, then the user can run "sudo su -" on the client to become root.
 
>> [root@fedora21-freeipa log]# ipa hostgroup-show
>> Host-group: cog
>> Host-group: cog
>> Member hosts: ipaclient21.testdomain21.com
>> Member of Sudo rule: All
>> [root@fedora21-freeipa log]# ipa sudorule-show All
>> Rule name: All
>> Enabled: TRUE
>> Command category: all
>> RunAs User category: all
>> RunAs Group category: all
>> User Groups: cog_rw
>> Host Groups: cog
>> Sudo Option: !authenticate
>>
>> but this setup doesn't work, i.e. even though the user is in the user 
>> group and the client machine is in the host group, sudo su - fails. Is 
>> this a bug, or have I missed something?
>>
>> Chris
>>
>>
>>
>
> With FreeIPA 4.1.1, client sudo integration should be automatically 
> configured,
> so it should just work, including hostgroups. In your case, I would start 
> with
> investigating
>
> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>
> If that does not help, I bet SSSD devs will ask for logs.
>
 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
 machine, but I'm not sure if that's the right file (it didn't exist 
 before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
 stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
 messages.
>>>
>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, 
>>> but I created /etc/sssd.conf with a line
>>>
>>> Debug sudo /var/log/sudo_debug all@debug
>>>
>>> and I saw this in the debug output:
>>>
>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>>
>>> The problem is that the hostname command on the client was returning a 
>>> short hostname, ipaclient21, instead of a FQDN, 
>>> ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN 
>>> the sudo command worked.
>>>
>>>
>>> The short hostname comes from the fact that the client machine is an 
>>> openstack instance, and that appears to be a feature of openstack instances 
>>> :(
>>
>>
>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
>> this is the case, I am not sure what we could do, sudo somehow needs to learn
>> the FQDN.
>>
> I can set up the instance so that hostname -f returns the FQDN, but the only 
> way I can get hostname to return the FQDN is if I explicitly run "hostname 
> "; unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.

Martin

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Re: [Freeipa-users] vSphere 5.1 and FreeIPA 3.3 on CentOS 7 finally works! [How I did it...]

[Petr Spacek]

On 10.12.2014 20:20, Dmitri Pal wrote:
> On 12/10/2014 06:55 AM, Gianluca Cecchi wrote:
>> On Tue, Dec 9, 2014 at 10:50 AM, Martin Kosek > > wrote:
>>
>> On 12/09/2014 12:50 AM, Gianluca Cecchi wrote:
>> > On Mon, Dec 8, 2014 at 7:17 PM, Gianluca Cecchi
>> mailto:gianluca.cec...@gmail.com>>
>> > wrote:
>> >
>> >> OK. I will check requirements to write into The wiki
>> >>
>>
>>
>> Hello,
>> now I was able to login and I created this draft page, you can check and
>> feel free to review...
>> http://www.freeipa.org/page/HowTo/vsphere5_integration
> I scanned the page.
> Looks good. Thanks a lot!
> 
> I hope someone with the similar use case can verify the steps.

Link to the how-to was added to:
http://www.freeipa.org/page/HowTos#Virtualization

-- 
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

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

> On 12/10/2014 04:54 PM, Chris Card wrote:
>>
>>
>>>
 On 12/10/2014 12:57 PM, Chris Card wrote:
>>> thanks Martin,
> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
> freeipa server and a freeipa client machine.
> I've set up a user with ssh keys, and can successfully ssh onto the 
> client machine.
> I'm trying to setup sudo rules so that if the user is in a given user 
> group, then the user can run "sudo su -" on the client to become root.
>>> 
> [root@fedora21-freeipa log]# ipa hostgroup-show
> Host-group: cog
> Host-group: cog
> Member hosts: ipaclient21.testdomain21.com
> Member of Sudo rule: All
> [root@fedora21-freeipa log]# ipa sudorule-show All
> Rule name: All
> Enabled: TRUE
> Command category: all
> RunAs User category: all
> RunAs Group category: all
> User Groups: cog_rw
> Host Groups: cog
> Sudo Option: !authenticate
>
> but this setup doesn't work, i.e. even though the user is in the user 
> group and the client machine is in the host group, sudo su - fails. Is 
> this a bug, or have I missed something?
>
> Chris
>
>
>

 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would start 
 with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

>>> I've done the troubleshooting steps:
>>>
>>> [root@ipaclient21 log]# nisdomainname
>>> testdomain21.com
>>> [root@ipaclient21 log]# getent netgroup cog
>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>
>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
>>> machine, but I'm not sure if that's the right file (it didn't exist before).
>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff 
>>> in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>
>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, 
>> but I created /etc/sssd.conf with a line
>>
>> Debug sudo /var/log/sudo_debug all@debug
>>
>> and I saw this in the debug output:
>>
>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>
>> The problem is that the hostname command on the client was returning a short 
>> hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and 
>> when I forced the hostname to be the FQDN the sudo command worked.
>>
>>
>> The short hostname comes from the fact that the client machine is an 
>> openstack instance, and that appears to be a feature of openstack instances 
>> :(
>
>
> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
> this is the case, I am not sure what we could do, sudo somehow needs to learn
> the FQDN.
>
I can set up the instance so that hostname -f returns the FQDN, but the only 
way I can get hostname to return the FQDN is if I explicitly run "hostname 
"; unfortunately this doesn't survive a reboot.

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