Re: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening

2017-03-03 Thread Chris Herdt 
On Fri, Mar 3, 2017 at 4:22 AM, Tomas Krizek  wrote:
>
>
> On 03/02/2017 06:25 PM, Chris Herdt wrote:
>
> On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti  wrote:
>>
>>
>>
>>
>> On 02.03.2017 16:55, Chris Herdt wrote:
>>
>>
>>
>> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti  wrote:
>>>
>>>
>>>
>>> On 02.03.2017 01:07, Chris Herdt wrote:
>>>
>>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a 
>>> FreeIPA 3.0.0 master on CentOS 6.8 following the steps at 
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>>>
>>> At this step:
>>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir 
>>> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>>>
>>> I get the error:
>>> ERROR cannot connect to 'ldaps://master.example.com'
>>>
>>> I ran ipa-replica-conncheck and found that port 636 is not accessible:
>>> Port check failed! Inaccessible port(s): 636 (TCP)
>>>
>>> The port is not blocked. I'm wondering where in the configuration for 
>>> FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a 
>>> way I can specify to use port 389 for setting up the replica.
>>>
>>> Thanks!
>>>
>>> --
>>> Chris Herdt
>>> Systems Administrator
>>>
>>>
>>>
>>> Hello,
>>> this is known issue only in FreeIPA 4.4.x, this will be fixed  in next 
>>> minor update which should be released soon to RHEL7.3 (I don't know how 
>>> fast it will be in Centos)
>>>
>>> so you can wait, or enable it manually (not nice)
>>>
>>> sorry for troubles
>>> Martin
>>
>>
>>
>> Thanks for the reply! Before attempting this in my production environment, I 
>> had set up a similar configuration in a test environment (FreeIPA 3.0.0 
>> master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the 
>> ipa-replica-install went fine. I assumed this was an issue with my FreeIPA 
>> 3.0.0 production server.
>>
>> To enable the fix manually, I'm assuming I'd need to install FreeIPA from 
>> source on the intended replica? If I download the 4.4.3 release from 
>> https://pagure.io/freeipa/releases, will that be sufficient?
>>
>> Sorry,
>> I probably misread what you wrote, I thought that port is closed on replica, 
>> but now I see that port is closed on 3.3.0 master, so this is something 
>> different. I'm not aware of any issue on 3.3.0 that should cause this.
>>
>> Could you check your configuration on 3.3.0 master? Is port opened on 
>> master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on 
>> master?
>>
>> Martin
>
>
> When I compare the errors file on my production environment and my test 
> environment, I do note that the LDAPS entry is missing from my production 
> environment:
>
> production:
> [01/Mar/2017:17:30:07 -0600] - slapd started.  Listening on All Interfaces 
> port 389 for LDAP requests
> [01/Mar/2017:17:30:07 -0600] - Listening on 
> /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests
>
> test:
> [28/Feb/2017:13:37:50 -0600] - slapd started.  Listening on All Interfaces 
> port 389 for LDAP requests
> [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for LDAPS 
> requests
> [28/Feb/2017:13:37:50 -0600] - Listening on 
> /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests
>
> I'm not sure why it is missing though. Which config file(s) should I be 
> checking?
>
> You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check if 
> the Directory Server has LDAP configured correctly. In particular, you're 
> interested in:
>
> - nsslapd-security in cn=config
> - cn=encryption,cn=config
> - cn=RSA,cn=encryption,cn=config
>
> Also, you can check if the certificate for LDAPS is available in the NSS 
> database:
>
> certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L


nsslapd-security was set to off. I set it to on, but SSL failed.

There were no certificates listed--which I think explains why SSL
failed--when running:
certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L

ipa-getcert list shows several certs, including one with
location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB' -- I'm not sure where this cert exists though.

I assume I need to get the NSS db to recognize the Server-Cert, for example:
certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -i ?

-- 
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] [solved] Re: GSSAPI for second hop (SSH)

2017-03-03 Thread Jason B. Nance 
>I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users 
>connecting to
>Linux servers from their domain-joined workstations are not required to 
>enter a
>password for the first connection.  However, if they attempt to ssh to a 
>second
>Linux machine from the first they are being prompted for a password.
>
>I've tried the following /etc/ssh/ssh_config options:
>
>GSSAPIDelegateCredentials yes
>GSSAPIKeyExchange yes
>GSSAPIRenewalForcesRekey yes
>GSSAPITrustDns yes
>
>And the following /etc/ssh/sshd_config options:
>
>GSSAPIAuthentication yes
>GSSAPIKeyExchange yes
>GSSAPIStoreCredentialsOnRekey yes
>
>Am I missing a step/configuration?
>>>
 They need to allow delegation on the machine where their first hop
 starts, not only on your jump server.
>>>
>>>Both the first hop and subsequent servers have those settings.
> 
>> I'm not talking about servers. It starts with the client machines.
>> If server never got delegated credentials, how could it be a client that
>> delegates them further? That original client has to allow delegation
>> in first place.
> 
> Do you know how I can validate that is working (such as, will something show 
> up
> in a klist)?  I'm using PuTTY 0.67 as my Windows ssh client and have the 
> "Allow
> GSSAPI credential delegation" box checked, but some quick Googling is
> suggesting that may not be enough.

Okay, I missed something REALLY basic.  :-(  In my SSH client configuration I 
didn't have "GSSAPIAuthentication yes", and the default is "no".  The key 
exchange doesn't work, but gssapi-with-mic does.  Here's an excerpt from "ssh 
-vvv":

debug3: preferred 
gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: 
gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to sl1mmgplsat0001 (via proxy).

-- 
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] GSSAPI for second hop (SSH)

2017-03-03 Thread Jason B. Nance 
I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users 
connecting to
Linux servers from their domain-joined workstations are not required to 
enter a
password for the first connection.  However, if they attempt to ssh to a 
second
Linux machine from the first they are being prompted for a password.

I've tried the following /etc/ssh/ssh_config options:

GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
GSSAPIRenewalForcesRekey yes
GSSAPITrustDns yes

And the following /etc/ssh/sshd_config options:

GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStoreCredentialsOnRekey yes

Am I missing a step/configuration?
>>
>>> They need to allow delegation on the machine where their first hop
>>> starts, not only on your jump server.
>>
>>Both the first hop and subsequent servers have those settings.

> I'm not talking about servers. It starts with the client machines.
> If server never got delegated credentials, how could it be a client that
> delegates them further? That original client has to allow delegation
> in first place.

Do you know how I can validate that is working (such as, will something show up 
in a klist)?  I'm using PuTTY 0.67 as my Windows ssh client and have the "Allow 
GSSAPI credential delegation" box checked, but some quick Googling is 
suggesting that may not be enough.

Thanks for the insight.

j

-- 
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] GSSAPI for second hop (SSH)

2017-03-03 Thread Alexander Bokovoy 

On pe, 03 maalis 2017, Jason B. Nance wrote:

I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users connecting to
Linux servers from their domain-joined workstations are not required to enter a
password for the first connection.  However, if they attempt to ssh to a second
Linux machine from the first they are being prompted for a password.

I've tried the following /etc/ssh/ssh_config options:

   GSSAPIDelegateCredentials yes
   GSSAPIKeyExchange yes
   GSSAPIRenewalForcesRekey yes
   GSSAPITrustDns yes

And the following /etc/ssh/sshd_config options:

   GSSAPIAuthentication yes
   GSSAPIKeyExchange yes
   GSSAPIStoreCredentialsOnRekey yes

Am I missing a step/configuration?



They need to allow delegation on the machine where their first hop
starts, not only on your jump server.


Both the first hop and subsequent servers have those settings.

I'm not talking about servers. It starts with the client machines.
If server never got delegated credentials, how could it be a client that
delegates them further? That original client has to allow delegation
in first place.

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

Re: [Freeipa-users] GSSAPI for second hop (SSH)

2017-03-03 Thread Jason B. Nance 
>> I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users
>> connecting to Linux servers from their domain-joined workstations are
>> not required to enter a password for the first connection.  However,
>> if they attempt to ssh to a second Linux machine from the first they
>> are being prompted for a password.
> 
> What is the output if they klist on the first machine they SSH to?

[jna...@centric.com@sl1aosplmgt0001 ~]$ klist
Ticket cache: KEYRING:persistent:255985:krb_ccache_TuVdBrp
Default principal: jna...@centric.com

Valid starting   Expires  Service principal
03/03/2017 11:55:16  03/03/2017 21:47:34  krbtgt/ipa.gen.z...@centric.com
renew until 03/04/2017 11:47:33
03/03/2017 11:47:34  03/03/2017 21:47:34  krbtgt/centric@centric.com
renew until 03/04/2017 11:47:33

centric.com is the AD domain that ipa.gen.zone trusts.

-- 
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] GSSAPI for second hop (SSH)

2017-03-03 Thread Jason B. Nance 
>>I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users connecting 
>>to
>>Linux servers from their domain-joined workstations are not required to enter 
>>a
>>password for the first connection.  However, if they attempt to ssh to a 
>>second
>>Linux machine from the first they are being prompted for a password.
>>
>>I've tried the following /etc/ssh/ssh_config options:
>>
>>GSSAPIDelegateCredentials yes
>>GSSAPIKeyExchange yes
>>GSSAPIRenewalForcesRekey yes
>>GSSAPITrustDns yes
>>
>>And the following /etc/ssh/sshd_config options:
>>
>>GSSAPIAuthentication yes
>>GSSAPIKeyExchange yes
>>GSSAPIStoreCredentialsOnRekey yes
>>
>>Am I missing a step/configuration?

> They need to allow delegation on the machine where their first hop
> starts, not only on your jump server.

Both the first hop and subsequent servers have those settings.

-- 
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] GSSAPI for second hop (SSH)

2017-03-03 Thread Robbie Harwood 
"Jason B. Nance"  writes:

> I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users
> connecting to Linux servers from their domain-joined workstations are
> not required to enter a password for the first connection.  However,
> if they attempt to ssh to a second Linux machine from the first they
> are being prompted for a password.

What is the output if they klist on the first machine they SSH to?


signature.asc
Description: PGP signature
-- 
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] GSSAPI for second hop (SSH)

2017-03-03 Thread Alexander Bokovoy 

On pe, 03 maalis 2017, Jason B. Nance wrote:

Hello,

I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users connecting to 
Linux servers from their domain-joined workstations are not required to enter a 
password for the first connection.  However, if they attempt to ssh to a second 
Linux machine from the first they are being prompted for a password.

I've tried the following /etc/ssh/ssh_config options:

   GSSAPIDelegateCredentials yes
   GSSAPIKeyExchange yes
   GSSAPIRenewalForcesRekey yes
   GSSAPITrustDns yes

And the following /etc/ssh/sshd_config options:

   GSSAPIAuthentication yes
   GSSAPIKeyExchange yes
   GSSAPIStoreCredentialsOnRekey yes

Am I missing a step/configuration?

They need to allow delegation on the machine where their first hop
starts, not only on your jump server.

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

[Freeipa-users] GSSAPI for second hop (SSH)

2017-03-03 Thread Jason B. Nance 
Hello,

I have a FreeIPA 4.4.0 setup with Active Directory trusts.  Users connecting to 
Linux servers from their domain-joined workstations are not required to enter a 
password for the first connection.  However, if they attempt to ssh to a second 
Linux machine from the first they are being prompted for a password.

I've tried the following /etc/ssh/ssh_config options:

GSSAPIDelegateCredentials yes
GSSAPIKeyExchange yes
GSSAPIRenewalForcesRekey yes
GSSAPITrustDns yes

And the following /etc/ssh/sshd_config options:

GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPIStoreCredentialsOnRekey yes

Am I missing a step/configuration?

Thanks,

j

-- 
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 4.4 creating users with expiration

2017-03-03 Thread Rakesh Rajasekharan 
Hello,

Am using Freeipa 4.4 version .

I would like to create few users only valid for few days or  months. So,is
there a way to create few users with a preset expiration or auto lock those
accounts after a few days

Thanks
Rakesh
-- 
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] renewing cert and migrating free-ipa 3.1

2017-03-03 Thread Rob Crittenden 
Umarzuki Mochlis wrote:
> At first ip-getcert list hows certificate error
> 
> ca-error: Server failed request, will retry: -504 (libcurl failed to
> execute the HTTP POST transaction, explaining:  Peer's Certificate has
> expired.).
> 
> but after I changed ipa server's date to before expirate date, it shows
> 
> ca-error: Server failed request, will retry: -504 (libcurl failed to
> execute the HTTP POST transaction, explaining:  couldn't connect to
> host).
> 
> when I tried to start ipa with "service ipa start", all services would
> fail, so I need to start one by one
> 
> systemctl start dirsrv@DOMAIN-COM-MY.service
> systemctl status dirsrv@DOMAIN-COM-MY.service
> systemctl start krb5kdc.service
> systemctl status krb5kdc.service
> systemctl start kadmin.service
> systemctl status kadmin.service
> systemctl start ipa_memcached.service
> systemctl status ipa_memcached.service
> systemctl start pki-tomcatd@pki-tomcat.service
> systemctl status pki-tomcatd@pki-tomcat.service
> 
> 
> # tail /var/log/messages
> Jan  3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
> Jan  3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat.
> Jan  3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server
> failed request, will retry: -504 (libcurl failed to execute the HTTP
> POST transaction, explaining:  couldn't connect to host).
> Jan  3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server
> failed request, will retry: -504 (libcurl failed to execute the HTTP
> POST transaction, explaining:  couldn't connect to host).

You want to use the getcert command, not ipa-getcert, to see the CA
subsystem certificates.

What you should do is: getcert list |grep expires

Find a date/time that fits into a period where all certs are valid and
go back in time to then (after stopping ntpd).

That will hopefully fix the ipactl start issue.

Once IPA is restarted, restart certmonger.

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

Re: [Freeipa-users] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Rob Crittenden 
Harald Dunkel wrote:
> On 03/03/17 10:14, Jakub Hrozek wrote:
>> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote:
>>>
>>> This is systemd-only?
>>>
>>> Wouldn't it be better to create a working sssd.conf, no matter
>>> what?
>>
>> It is up to whoever is creating the sssd.conf. As I said, the change is
>> backwards-compatible. If you want the services to be started by sssd,
>> then list them in the services line. If you want to have them started on
>> demand and have a simpler configuration, you rely on the systemd services
>> manager.
>>
> 
> Understood. I will try 1.15.1 as soon as possible.
> 
> Reading ipa-client-install it appears to me that the other
> services haven't been omitted on purpose. I have the
> impression that nss and pam have simply been forgotten.
> 
> sssd's ssh service is defined only if ipa-client-install
> is allowed to touch the ssh or sshd configuration, but I
> have *no* idea why there is such a correlation.
> 
> Would somebody mind to look into this?

This is managed by authconfig on Fedora/RHEL systems. Not sure what
Debian does in this regard. Timo?

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

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

2017-03-03 Thread Umarzuki Mochlis 
At first ip-getcert list hows certificate error

ca-error: Server failed request, will retry: -504 (libcurl failed to
execute the HTTP POST transaction, explaining:  Peer's Certificate has
expired.).

but after I changed ipa server's date to before expirate date, it shows

ca-error: Server failed request, will retry: -504 (libcurl failed to
execute the HTTP POST transaction, explaining:  couldn't connect to
host).

when I tried to start ipa with "service ipa start", all services would
fail, so I need to start one by one

systemctl start dirsrv@DOMAIN-COM-MY.service
systemctl status dirsrv@DOMAIN-COM-MY.service
systemctl start krb5kdc.service
systemctl status krb5kdc.service
systemctl start kadmin.service
systemctl status kadmin.service
systemctl start ipa_memcached.service
systemctl status ipa_memcached.service
systemctl start pki-tomcatd@pki-tomcat.service
systemctl status pki-tomcatd@pki-tomcat.service


# tail /var/log/messages
Jan  3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat...
Jan  3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat.
Jan  3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server
failed request, will retry: -504 (libcurl failed to execute the HTTP
POST transaction, explaining:  couldn't connect to host).
Jan  3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server
failed request, will retry: -504 (libcurl failed to execute the HTTP
POST transaction, explaining:  couldn't connect to host).

2017-03-03 13:20 GMT+08:00 Umarzuki Mochlis :
> After httpd failed to start even with "NSSEnforceValidCerts off" in
> /etc/httpd/conf.d/nss.conf
> It used to work for a while since we use this only for zimbra but
> today it won't start anymore.
>
> We are not using commercial certs, so which steps should I follow to
> renew certs?
>
> It seems CA has expired more than 2 weeks ago.
>
> #  ipa-getcert list
> Number of certificates and requests being tracked: 7.
> Request ID '20130112120232':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: -504 (libcurl
> failed to execute the HTTP POST transaction, explaining:  Peer's
> Certificate has expired.).
> stuck: yes
> key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=DOMAIN.COM.MY
> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY
> expires: 2016-12-16 16:18:27 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
> DOMAIN-COM-MY
> track: yes
> auto-renew: yes
> Request ID '20130112120734':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: -504 (libcurl
> failed to execute the HTTP POST transaction, explaining:  Peer's
> Certificate has expired.).
> stuck: yes
> 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=DOMAIN.COM.MY
> subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY
> expires: 2016-12-16 16:18:27 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
>
> # rpm -qa | grep ipa
> freeipa-admintools-3.1.0-2.fc18.x86_64
> freeipa-server-3.1.0-2.fc18.x86_64
> libipa_hbac-python-1.9.3-1.fc18.x86_64
> python-iniparse-0.4-6.fc18.noarch
> freeipa-client-3.1.0-2.fc18.x86_64
> freeipa-server-selinux-3.1.0-2.fc18.x86_64
> freeipa-python-3.1.0-2.fc18.x86_64
> libipa_hbac-1.9.3-1.fc18.x86_64

-- 
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 mount NFS, but user only gets the permission question marks

2017-03-03 Thread Kees Bakker 
On 02-03-17 14:55, Brendan Kearney wrote:
> On 03/02/2017 08:43 AM, Kees Bakker wrote:
>> On 02-03-17 13:34, Brendan Kearney wrote:
>>> On 03/02/2017 05:40 AM, Kees Bakker wrote:
 On 24-02-17 14:38, Brendan Kearney wrote:
> On 02/24/2017 03:33 AM, Kees Bakker wrote:
>> On 23-02-17 15:39, Brendan Kearney wrote:
>>> On 02/23/2017 09:11 AM, Kees Bakker wrote:
 On 23-02-17 13:51, Brendan Kearney wrote:
> On 02/23/2017 07:32 AM, Kees Bakker wrote:
>> On 22-02-17 17:33, Brendan Kearney wrote:
>>> On 02/22/2017 10:26 AM, Kees Bakker wrote:
 On 22-02-17 14:05, Brendan Kearney wrote:
> On 02/22/2017 05:23 AM, Kees Bakker wrote:
>> On 21-02-17 19:49, Brendan Kearney wrote:
>>> On 02/21/2017 10:57 AM, Kees Bakker wrote:
 Hey,

 Maybe one of the NFS users on this list could give me a hint 
 what
 could be wrong. I'm not sure if it has any relation with 
 FreeIPA/Kerberos.

 I've set up an NFS server and I can mount the NFS directory on 
 my client. So, I'm
 guessing that setting up Kerberos principal was done correctly.

 However, only root can actually access the mounted contents. 
 Any other user
 only sees question marks as shown below.

 The mount command is simple.
 $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
 mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
 mount.nfs: trying text-based options 
 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

 On the server side /etc/exports looks like this.
 /home*(rw,sync,sec=krb5i,no_subtree_check)

 $ sudo mount |grep nfs
 srv1.example.com:/home on /nfshome type nfs4 
 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

 $ sudo ls -ld /nfshome
 drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
 $ sudo ls -l /nfshome
 total 0
 drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

 $ ls -l /nfshome
 ls: cannot access '/nfshome': Permission denied
 $ ls -l / | grep nfshome
 ls: cannot access '/nfshome': Permission denied
 d?   ? ??   ?? nfshome

 [...]

 Continuing story...

 I've tried various things in the meantime. I've set up two test 
 environments with virtual
 machines (virtualbox).
 * with Fedora 25; this works.
 * with Ubuntu 16.04; I'm getting the same problem (permission denied and 
 question marks).

 I also looked at the verbose output of rpc.gssd, it gives

 ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified 
 GSS failure.  Minor code may provide more information) - Can't find client 
 principal keesb@REALM in cache collection
>>> does the actual error message say @REALM, or did you substitute that to 
>>> obscure sensitive info?  if it does actually say @REALM, then you are 
>>> missing a config directive somewhere, that specifies the kerberos realm.
>> Be assured that I'm using the real thing.
>>
 getting credentials for client with uid 60001 for server srv1.example.com
 getting credentials for client with uid 60001 for server srv1.example.com
 WARNING: Failed to create krb5 context for user with uid 60001 for server 
 srv1.example.com
>> So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but 
>> not for another
>> user.
>>
>> [...]
>>
>> Log when the user is listing the directory
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall 
>> (/run/rpc_pipefs/nfs/clnt14)
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 
>> uid=60001 enctypes=18,17,16,23,3,1,2 '
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall 
>> (/run/rpc_pipefs/nfs/clnt14)
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is 
>> ''
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in 
>> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may 
>> provide more information) - Can't find client principal keesb@REALM in cache 
>> collection
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with 
>> uid 60001 for server srv1.example.com
>> Mar  2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being 
>> considered, with preferred realm 'REALM'
>> Mar  2 14:24:00

Re: [Freeipa-users] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Harald Dunkel 
On 03/03/17 10:14, Jakub Hrozek wrote:
> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote:
>>
>> This is systemd-only?
>>
>> Wouldn't it be better to create a working sssd.conf, no matter
>> what?
> 
> It is up to whoever is creating the sssd.conf. As I said, the change is
> backwards-compatible. If you want the services to be started by sssd,
> then list them in the services line. If you want to have them started on
> demand and have a simpler configuration, you rely on the systemd services
> manager.
> 

Understood. I will try 1.15.1 as soon as possible.

Reading ipa-client-install it appears to me that the other
services haven't been omitted on purpose. I have the
impression that nss and pam have simply been forgotten.

sssd's ssh service is defined only if ipa-client-install
is allowed to touch the ssh or sshd configuration, but I
have *no* idea why there is such a correlation.

Would somebody mind to look into this?


Thanx very much
Harri

-- 
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] cannot connect to ldaps during replica install, port 636 not listening

2017-03-03 Thread Tomas Krizek 
On 03/02/2017 06:25 PM, Chris Herdt wrote:
> On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti  >wrote:
>
>
>
>
> On 02.03.2017 16:55, Chris Herdt wrote:
>>
>>
>> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti > > wrote:
>>
>>
>>
>> On 02.03.2017 01:07, Chris Herdt wrote:
>>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS
>>> 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the
>>> steps at
>>> 
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>>> 
>>> 
>>>
>>> At this step:
>>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir
>>> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>>>
>>> I get the error:
>>> ERROR cannot connect to 'ldaps://master.example.com
>>> '
>>>
>>> I ran ipa-replica-conncheck and found that port 636 is not
>>> accessible:
>>> Port check failed! Inaccessible port(s): 636 (TCP)
>>>
>>> The port is not blocked. I'm wondering where in the
>>> configuration for FreeIPA 3.0.0 I should check the LDAPS
>>> (mis)configuration, or if there is a way I can specify to
>>> use port 389 for setting up the replica.
>>>
>>> Thanks!
>>>
>>> -- 
>>> Chris Herdt
>>> Systems Administrator
>>>
>>>
>>
>> Hello,
>> this is known issue only in FreeIPA 4.4.x, this will be
>> fixed  in next minor update which should be released soon to
>> RHEL7.3 (I don't know how fast it will be in Centos)
>>
>> so you can wait, or enable it manually (not nice)
>>
>> sorry for troubles
>> Martin
>>
>>
>>
>> Thanks for the reply! Before attempting this in my production
>> environment, I had set up a similar configuration in a test
>> environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0
>> replica on CentOS 7.3) and the ipa-replica-install went fine. I
>> assumed this was an issue with my FreeIPA 3.0.0 production server.
>>
>> To enable the fix manually, I'm assuming I'd need to install
>> FreeIPA from source on the intended replica? If I download the
>> 4.4.3 release from https://pagure.io/freeipa/releases
>> , will that be sufficient?
> Sorry,
> I probably misread what you wrote, I thought that port is closed
> on replica, but now I see that port is closed on 3.3.0 master, so
> this is something different. I'm not aware of any issue on 3.3.0
> that should cause this.
>
> Could you check your configuration on 3.3.0 master? Is port opened
> on master? Do you have any errors in
> /var/log/dirsrv/slapd-*/errors log on master?
>
> Martin
>
>
> When I compare the errors file on my production environment and my
> test environment, I do note that the LDAPS entry is missing from my
> production environment:
>
> production:
> [01/Mar/2017:17:30:07 -0600] - slapd started.  Listening on All
> Interfaces port 389 for LDAP requests
> [01/Mar/2017:17:30:07 -0600] - Listening on
> /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests
>
> test:
> [28/Feb/2017:13:37:50 -0600] - slapd started.  Listening on All
> Interfaces port 389 for LDAP requests
> [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636
> for LDAPS requests
> [28/Feb/2017:13:37:50 -0600] - Listening on
> /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests
>
> I'm not sure why it is missing though. Which config file(s) should I
> be checking?
You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check
if the Directory Server has LDAP configured correctly. In particular,
you're interested in:

- nsslapd-security in cn=config
- cn=encryption,cn=config
- cn=RSA,cn=encryption,cn=config

Also, you can check if the certificate for LDAPS is available in the NSS
database:

certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L

>
>
> -- 
> Chris Herdt
> Systems Administrator
>
>
-- 
Tomas Krizek

GPG key ID: 0xA1FBA5F7EF8C
4869 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869



signature.asc
Description: OpenPGP digital signature
-- 
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] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Jakub Hrozek 
On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote:
> Hi Jakub,
> 
> On 03/03/17 09:32, Jakub Hrozek wrote:
> > On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote:
> >> Hi folks,
> >>
> >> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on
> >> Debian Stretch
> >   ~~
> > This is important I guess.
> > 
> > Since SSSD 1.15, SSSD allows to socket-activate the services, so it is
> > no longer required to have them explicitly listed in the services line
> > of the sssd section. But:
> > - there were some nasty bugs in the first version of the socket
> >   activation. We will be releasing 1.15.1 today to address those
> >   issues
> > - the sockets must be enabled (systemctl status sssd-nss.socket). I
> >   understand Debian is doing this but I'm neither Debian user nor
> >   developer. I would suggest to ask on some Debian-specific forum or
> >   file a bug report if the resulting configurationd doesn't work.
> > 
> 
> This is systemd-only?
> 
> Wouldn't it be better to create a working sssd.conf, no matter
> what?

It is up to whoever is creating the sssd.conf. As I said, the change is
backwards-compatible. If you want the services to be started by sssd,
then list them in the services line. If you want to have them started on
demand and have a simpler configuration, you rely on the systemd services
manager.

-- 
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] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Harald Dunkel 
Hi Jakub,

On 03/03/17 09:32, Jakub Hrozek wrote:
> On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote:
>> Hi folks,
>>
>> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on
>> Debian Stretch
>   ~~
> This is important I guess.
> 
> Since SSSD 1.15, SSSD allows to socket-activate the services, so it is
> no longer required to have them explicitly listed in the services line
> of the sssd section. But:
> - there were some nasty bugs in the first version of the socket
>   activation. We will be releasing 1.15.1 today to address those
>   issues
> - the sockets must be enabled (systemctl status sssd-nss.socket). I
>   understand Debian is doing this but I'm neither Debian user nor
>   developer. I would suggest to ask on some Debian-specific forum or
>   file a bug report if the resulting configurationd doesn't work.
> 

This is systemd-only?

Wouldn't it be better to create a working sssd.conf, no matter
what?


Regards
Harri

-- 
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] ipa-client-install generates bad sssd.conf

2017-03-03 Thread Jakub Hrozek 
On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote:
> Hi folks,
> 
> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on
> Debian Stretch
  ~~
This is important I guess.

Since SSSD 1.15, SSSD allows to socket-activate the services, so it is
no longer required to have them explicitly listed in the services line
of the sssd section. But:
- there were some nasty bugs in the first version of the socket
  activation. We will be releasing 1.15.1 today to address those
  issues
- the sockets must be enabled (systemctl status sssd-nss.socket). I
  understand Debian is doing this but I'm neither Debian user nor
  developer. I would suggest to ask on some Debian-specific forum or
  file a bug report if the resulting configurationd doesn't work.

> ipa-client-install creates a bad sssd.conf file, e.g.
> 
>   [domain/example.com]
> 
>   cache_credentials = True
>   krb5_store_password_if_offline = True
>   ipa_domain = example.com
>   id_provider = ipa
>   auth_provider = ipa
>   access_provider = ipa
>   ldap_tls_cacert = /etc/ipa/ca.crt
>   ipa_hostname = stretch1.vs.example.com
>   chpass_provider = ipa
>   ipa_server = _srv_, ipa1.example.com
>   dns_discovery_domain = example.com
>   [sssd]
>   domains = example.com
>   services = sudo

btw I find it strange that sudo is listed. I would expect either all or
no services to be listed. The feature is backwards-compatible, so if you
list the services explicitly, the sssd process would still start them
explicitly, just as it did with previous versions.

>   [sudo]
> 
> 
> Esp. the services for nss, pam and ssh are not setup. Is this
> as expected?
> 
> 
> Every helpful comment is highly appreciated.
> Harri
> 
> -- 
> 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