Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

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.

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

[Dmitri Pal]

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.

--
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] can't register new clients

[Megan .]

Ok, Thank you for the information.

During the restore i ran into
https://fedorahosted.org/freeipa/ticket/4726 and sudo -u apache
kdestroy fixed it.  I think there was also something else minor that i
was able to fix by running a command differently.

I had two clients that I HAD to get online due to a deadline, so i
manually configured the clients using
(http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html)
and they work fine now.

I have a third client that I'm working with where i have some more
time.  This one is on the same VLAN as the directory server, so that
eliminates and network related issues as a possibility.


I ran

openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt

against the ca.crt that was left from the failed install and it looks
fine.  I might try to regenerate the certificate and see if that helps
although it looks like a real pain for verso 3 according to
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0


[root@walker ipa]# openssl s_client -host dir1.example.com -port 443
-CAfile ca.crt
CONNECTED(0003)
depth=1 O = example.com, CN = Certificate Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/O=example.com/CN=dir1.example.com
   i:/O=example.com/CN=Certificate Authority
 1 s:/O=example.com/CN=Certificate Authority
   i:/O=example.com/CN=Certificate Authority
---
Server certificate
-BEGIN CERTIFICATE-
Masdfasdf more stuff here
-END CERTIFICATE-
subject=/O=example.com/CN=dir1.example.com
issuer=/O=example.com/CN=Certificate Authority
---
No client certificate CA names sent
---
SSL handshake has read 2095 bytes and written 591 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.1
Cipher: AES128-SHA
Session-ID:
22BBDF13AA4DDFFF7562A624D0A6B1B35BCE727FD59AFF1572B4928851DFB91B
Session-ID-ctx:
Master-Key:
9EF37866161FD89469DD5631744051123456788F5C035CB8F5E8A85F9B2FAAE96698F48559D1338C42B4F20FC
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1418237923
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---



301 Moved Permanently

Moved Permanently
The document has moved https://dir1.example.com/ipa/ui";>here.

Apache/2.2.15 (CentOS) Server at dir1.example.com Port 443

closed

On Wed, Dec 10, 2014 at 3:19 AM, Martin Kosek  wrote:
> On 12/09/2014 03:57 PM, Megan . wrote:
>> This is happening with all new clients.  I had to rebuild the LDAP
>> server onto new hardware and the network team put us on a new VLAN.
>> so my physical server and IP changed.  I was previously able to
>> register clients, but after all of the changes, i can no longer
>> register them.  At this point i'm not sure if there is a network issue
>> or something wrong with the IPA server.  The existing clients are
>> communicating fine, no errors or complains.  I have two new clients to
>> add and both have the same symptoms.
>>
>> I used these procedures to backup then restore onto the new host
>> http://www.freeipa.org/page/V3/Backup_and_Restore
>>
>> To change the IP i just updated /etc/hosts and pushed it out to the clients
>
> This may be related. Did the backup and restore really go correctly? AFAIK,
> this feature did not go through more heavy testing in the community yet, so
> there may be rough edges. There were several bug fixes to backup and restore
> scripts in FreeIPA 4.1.x releases already.
>
> But if the hostname is the same, A/ and PTR DNS records are still valid 
> and
> your other clients work fine, it should be OK.
>
> So you are saying that installation still fails with the NSS error -8054? I am
> thinking that the next step should be to run ipa-client-install with --force
> flag to make sure that it does not clean the certificate downloaded from LDAP
> and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you 
> already
> tested the one downloaded by wget, but theoretically, the one in LDAP could be
> different).
>
>> On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden  wrote:
>>> Megan . wrote:
 Everything looks ok.

 Our Networks team only opened 443 from the client to the server.  is
 80 required to be open too for registration?  80 is a lot harder for
 me to request on our network.

 I think I might have found the issue.  Maybe it can't verify the CA
 because its pointing to port 80, and 80 isn't open.  Is it possible to
 change the certificate so this information is available via 443 or
 does that not make sense since its trying to get information about the
 secure connection in the first place.
>>>
>>> I don't think port 80 is the problem and in any case, it is just a
>>> fallback in case the client can't get it vi

Re: [Freeipa-users] freeipa / sudo

[Simo Sorce]

On Wed, 10 Dec 2014 11:57:26 +
Chris Card  wrote:

> Hi,
> 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.

FWIW you should probably use just sudo -i it will avoid authorization
issues to run the su service.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

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] change directory manager password

[Rob Crittenden]

Rich Megginson wrote:
> On 12/10/2014 12:46 AM, Thomas Lau wrote:
>> Hi All,
>>
>> So I am using FreeIPA 3.3.3, when I change password on one IPA host,
>> the other clusters will in sync with the change or I need to do it one
>> by one manually?
> 
> You have to do every server manually.  Changes to the cn=config tree are
> not replicated.

You should also take a look at this:
http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

rob

> 
>>
>> On Wed, Dec 10, 2014 at 12:03 PM, Simo Sorce  wrote:
>>> On Tue, 09 Dec 2014 20:33:32 -0700
>>> Rich Megginson  wrote:
>>>
 On 12/09/2014 07:46 PM, Thomas Lau wrote:
> By the way, if I change Directory manager password, do I need to do
> anything else for replication cluster?
 http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html

 Unless you are using directory manager for replication (please tell
 me you are not), you shouldn't have to do anything.
>>> Given this is freeipa-users I assume ipa-replica-install/manage
>>> converted his replication agreements to use GSSAPI :-)
>>>
>>> So, no, in FreeIPA replication doesn't care about the DM password.
>>>
>>> Simo.
>>>
>>> -- 
>>> Simo Sorce * Red Hat, Inc * New York
>>>
>>> -- 
>>> 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] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached

[chymian]

Am Mittwoch, 10. Dezember 2014, 10:28:17 schrieb thierry bordaz:
> On 12/09/2014 11:52 PM, chymian wrote:
> >> Am Dienstag, 9. Dezember 2014, 14:10:48 schrieb thierry bordaz:
> >>
> >> On 12/09/2014 01:54 PM, 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.
> >>>
> >>>
> >>> a second service fails to start:
> >>>
> >>> $ systemctl status dirsrv-snmp.service
> >>> ● dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
> >>>
> >>> Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
> >>> Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
> >>> 5min
> >>> ago
> >>>
> >>>Process: 156 ExecStart=/usr/sbin/ldap-agent
> >>>/etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>
> >>>
> >>> Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
> >>> Subagent Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
> >>> instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
> >>> dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
> >>> 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
> >>> Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
> >>> entered
> >>> failed state.
> >> Hello,
> >>
> >> regarding this issue. Is there a agent log file under 
> >> /var/log/dirsrv/agent/
> >> ?
> >>
> >> thanks
> >> thierry
> >>
> > thierry,
> > no there aren’t any files, except the slapd-EB8-LAN/ directory in 
> > /var/log/dirsrv/
> > not even an  /var/log/dirsrv/agent/
> >
> > anything else I can provide?
> 
> Hello Guenter,
> 
> It is looking like no server have been configured in 
> /etc/dirsrv/config/ldap-agent.conf to be monitored.
> So the ldap-agent started by this service returns an errors at startup.
> As you are not using snmp, like Rich said you may ignore this service 
> failure.
> 
> thanks
> thierry

hello thierry,
yes, it’s seems to be empty – same as on a plain cos6/ipa 3.3 installation.
but there, the service does not get started, and therefore, no error is thrown.
may I suggest to do a check in the startup scripts weather a service is 
configured or not, or "systemctl disable" it by default?

thx for your help
guenter

  
> >   
> > thanks,
> > guenter
> >
> >>> except these, I was able to subscribe a jessie-client with autodiscovery
> >>> right after I did configure the ipa-server, before first reboot.
> >>>
> >>>
> >>> any help appreciated, since I do not have much experience with IPA – yet.
> >>> guenter
> 


-- 
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] change directory manager password

[Rich Megginson]

On 12/10/2014 12:46 AM, Thomas Lau wrote:

Hi All,

So I am using FreeIPA 3.3.3, when I change password on one IPA host,
the other clusters will in sync with the change or I need to do it one
by one manually?


You have to do every server manually.  Changes to the cn=config tree are 
not replicated.




On Wed, Dec 10, 2014 at 12:03 PM, Simo Sorce  wrote:

On Tue, 09 Dec 2014 20:33:32 -0700
Rich Megginson  wrote:


On 12/09/2014 07:46 PM, Thomas Lau wrote:

By the way, if I change Directory manager password, do I need to do
anything else for replication cluster?

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html

Unless you are using directory manager for replication (please tell
me you are not), you shouldn't have to do anything.

Given this is freeipa-users I assume ipa-replica-install/manage
converted his replication agreements to use GSSAPI :-)

So, no, in FreeIPA replication doesn't care about the DM password.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
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] freeipa / sudo

[Chris Card]

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

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] freeipa / sudo

[Martin Kosek]

On 12/10/2014 12:57 PM, Chris Card wrote:
> Hi,
> 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.
> 
> Here is my setup:
> 
> [root@fedora21-freeipa log]# ipa user-show ccard
>   User login: ccard
>   First name: Chris
>   Last name: Card
>   Home directory: /home/ccard
>   Login shell: /bin/sh
>   Email address: cc...@testdomain21.com
>   UID: 158101
>   GID: 158101
>   Account disabled: False
>   Password: True
>   Member of groups: ipausers, cog_rw
>   Indirect Member of Sudo rule: All
>   Kerberos keys available: True
>   SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 
> ccard (ssh-rsa)
> [root@fedora21-freeipa log]# ipa group-show cog_rw
>   Group name: cog_rw
>   GID: 158103
>   Member users: ccard
>   Member of Sudo rule: All
> [root@fedora21-freeipa log]# ipa sudorule-show All
>   Rule name: All
>   Enabled: TRUE
>   Host category: all
>   Command category: all
>   RunAs User category: all
>   RunAs Group category: all
>   User Groups: cog_rw
>   Sudo Option: !authenticate
> 
> I've found that this setup works eventually, but I have to wait for several 
> minutes after changing the settings (through the freeipa gui), before it 
> works. 
> I've found that changing entry_cache_sudo_timeout and stopping/starting sssd 
> on the client machine helps, and that sss_cache doesn't support invalidating 
> the sudo rules, which is annoying.
> 
> I've also tried making the sudo rule more restrictive by adding a host group 
> e.g.
> 
> [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.

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

[Freeipa-users] freeipa / sudo

[Chris Card]

Hi,
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.

Here is my setup:

[root@fedora21-freeipa log]# ipa user-show ccard
  User login: ccard
  First name: Chris
  Last name: Card
  Home directory: /home/ccard
  Login shell: /bin/sh
  Email address: cc...@testdomain21.com
  UID: 158101
  GID: 158101
  Account disabled: False
  Password: True
  Member of groups: ipausers, cog_rw
  Indirect Member of Sudo rule: All
  Kerberos keys available: True
  SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 
ccard (ssh-rsa)
[root@fedora21-freeipa log]# ipa group-show cog_rw
  Group name: cog_rw
  GID: 158103
  Member users: ccard
  Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: cog_rw
  Sudo Option: !authenticate

I've found that this setup works eventually, but I have to wait for several 
minutes after changing the settings (through the freeipa gui), before it works. 
I've found that changing entry_cache_sudo_timeout and stopping/starting sssd on 
the client machine helps, and that sss_cache doesn't support invalidating the 
sudo rules, which is annoying.

I've also tried making the sudo rule more restrictive by adding a host group 
e.g.

[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

  

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

[thierry bordaz]

On 12/09/2014 11:52 PM, chymian wrote:

Am Dienstag, 9. Dezember 2014, 14:10:48 schrieb thierry bordaz:

On 12/09/2014 01:54 PM, 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.


a second service fails to start:

$ systemctl status dirsrv-snmp.service
● dirsrv-snmp.service - 389 Directory Server SNMP Subagent.

Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled)
Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET;
5min
ago
   
   Process: 156 ExecStart=/usr/sbin/ldap-agent

   /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)>

Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP
Subagent Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server
instances defined in config file Dez 09 13:25:04 ipa systemd[1]:
dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09
13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP
Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service
entered
failed state.

Hello,

regarding this issue. Is there a agent log file under /var/log/dirsrv/agent/
?

thanks
thierry


thierry,
no there aren’t any files, except the slapd-EB8-LAN/ directory in 
/var/log/dirsrv/
not even an  /var/log/dirsrv/agent/

anything else I can provide?


Hello Guenter,

It is looking like no server have been configured in 
/etc/dirsrv/config/ldap-agent.conf to be monitored.

So the ldap-agent started by this service returns an errors at startup.
As you are not using snmp, like Rich said you may ignore this service 
failure.


thanks
thierry
  
thanks,

guenter


except these, I was able to subscribe a jessie-client with autodiscovery
right after I did configure the ipa-server, before first reboot.


any help appreciated, since I do not have much experience with IPA – yet.
guenter


--
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] Change default password expiry date

[Martin Kosek]

On 12/10/2014 03:36 AM, Dmitri Pal wrote:
> On 12/09/2014 08:43 PM, Thomas Lau wrote:
>> Hi All,
>>
>> FreeIPA Default is using 60days password expiry, how could I change it?
> 
> You go to password policies and change the global password policy.
> You change MAX lifetime.
> This is a global setting it will apply to new passwords/keytabs when they are
> changed next time.
> You can create other policies and apply them to groups it you need.

Right. BTW, the default is 90 days, not sixty:

# ipa pwpolicy-show
  Group: global_policy
  Max lifetime (days): 90
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

> 
>>
>> Also, for existing accounts, can I just change krbPasswordExpiration
>> on LDAP?
> 
> I think the answer is yes.

You will need to be Directory Manager for such change. Normally, it is excepted
that the new password policy is applied on next user password change.

> 
>> anywhere else I need to change?
> 
> I think the answer is no

Right.

> 
>> do I need to generate keytab
>> on Kerberos to activate new expiry date?
>>
> If you change the expiration in the attribute then no.
> 

More on password policies here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-pwdpolicy.html

-- 
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] can't register new clients

[Martin Kosek]

On 12/09/2014 03:57 PM, Megan . wrote:
> This is happening with all new clients.  I had to rebuild the LDAP
> server onto new hardware and the network team put us on a new VLAN.
> so my physical server and IP changed.  I was previously able to
> register clients, but after all of the changes, i can no longer
> register them.  At this point i'm not sure if there is a network issue
> or something wrong with the IPA server.  The existing clients are
> communicating fine, no errors or complains.  I have two new clients to
> add and both have the same symptoms.
> 
> I used these procedures to backup then restore onto the new host
> http://www.freeipa.org/page/V3/Backup_and_Restore
> 
> To change the IP i just updated /etc/hosts and pushed it out to the clients

This may be related. Did the backup and restore really go correctly? AFAIK,
this feature did not go through more heavy testing in the community yet, so
there may be rough edges. There were several bug fixes to backup and restore
scripts in FreeIPA 4.1.x releases already.

But if the hostname is the same, A/ and PTR DNS records are still valid and
your other clients work fine, it should be OK.

So you are saying that installation still fails with the NSS error -8054? I am
thinking that the next step should be to run ipa-client-install with --force
flag to make sure that it does not clean the certificate downloaded from LDAP
and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you already
tested the one downloaded by wget, but theoretically, the one in LDAP could be
different).

> On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden  wrote:
>> Megan . wrote:
>>> Everything looks ok.
>>>
>>> Our Networks team only opened 443 from the client to the server.  is
>>> 80 required to be open too for registration?  80 is a lot harder for
>>> me to request on our network.
>>>
>>> I think I might have found the issue.  Maybe it can't verify the CA
>>> because its pointing to port 80, and 80 isn't open.  Is it possible to
>>> change the certificate so this information is available via 443 or
>>> does that not make sense since its trying to get information about the
>>> secure connection in the first place.
>>
>> I don't think port 80 is the problem and in any case, it is just a
>> fallback in case the client can't get it via LDAP which in new installs
>> shouldn't be an issue. You'd get an error that the CA couldn't be
>> retrieved at all and not that a duplicate serial existed.
>>
>> Is this happening on every client or just one?
>>
>> Did you have a previous IPA install and you are re-enrolling this
>> client(s) into the new one?
>>
>> rob
>>
>>>
>>> from the server:
>>> [root@dir1 ipa]# openssl verify -verbose -CAFile ca.crt
>>> .
>>> .
>>> Authority Information Access:
>>> OCSP - URI:http://dir1.example.com:80/ca/ocsp
>>> .
>>>
>>>
>>>
>>> [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>> -O /tmp/ipa.crt
>>> --2014-12-09 13:21:32--  https://dir1.example.com/ipa/config/ca.crt
>>> Resolving dir1.example.com... 172.28.27.170
>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>> ERROR: cannot verify dir1.example.com’s certificate, issued by
>>> “/O=EXAMPLE.COM/CN=Certificate Authority”:
>>>   Self-signed certificate encountered.
>>> To connect to dir1.example.com insecurely, use ‘--no-check-certificate’.
>>> [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt
>>> -O /tmp/ipa.crt --no-check-certificate
>>> --2014-12-09 13:22:11--  https://dir1.example.com/ipa/config/ca.crt
>>> Resolving dir1.example.com... 172.28.27.170
>>> Connecting to dir1.example.com|172.28.27.170|:443... connected.
>>> WARNING: cannot verify dir1.example.com’s certificate, issued by
>>> “/O=EXAMPLE.COM/CN=Certificate Authority”:
>>>   Self-signed certificate encountered.
>>> HTTP request sent, awaiting response... 200 OK
>>> Length: 1357 (1.3K) [application/x-x509-ca-cert]
>>> Saving to: “/tmp/ipa.crt”
>>>
>>> 100%[>] 1,357
>>> --.-K/s   in 0.005s
>>>
>>> 2014-12-09 13:22:11 (246 KB/s) - “/tmp/ipa.crt” saved [1357/1357]
>>>
>>> [root@data2-uat ipa]# cd /tmp
>>> [root@data2-uat tmp]# openssl s_client -host dir1.example.com  -port
>>> 443 -CAfile /tmp/ipa.crt
>>> CONNECTED(0003)
>>> depth=1 O = EXAMPLE.COM, CN = Certificate Authority
>>> verify return:1
>>> depth=0 O = EXAMPLE.COM, CN = dir1.example.com
>>> verify return:1
>>> ---
>>> Certificate chain
>>>  0 s:/O=EXAMPLE.COM/CN=dir1.example.com
>>>i:/O=EXAMPLE.COM/CN=Certificate Authority
>>>  1 s:/O=EXAMPLE.COM/CN=Certificate Authority
>>>i:/O=EXAMPLE.COM/CN=Certificate Authority
>>> ---
>>> Server certificate
>>> -BEGIN CERTIFICATE-
>>> ...
>>> -END CERTIFICATE-
>>> subject=/O=EXAMPLE.COM/CN=dir1.example.com
>>> issuer=/O=EXAMPLE.COM/CN=Certificate Authority
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 2095 bytes and written 591 bytes