Re: [Freeipa-users] [FreeIPA 4.3.0] CentOS 6.8 sudo fails

[Jakub Hrozek]

On Tue, Jun 07, 2016 at 08:21:21PM +, Nathan Peters wrote:
> I have a fresh installation of CentOS 6.8 joined to a FreeIPA 4.3.0 domain on 
> Fedora 23.
> 
> When I try to sudo on this host, it fails.  Here are the log entries from 
> /var/log/secure.  Note that we have several hundred CentOS 6.5-6.7 machines 
> where this works fine.
> 
> Is this a new bug in CentOS 6.8?

It's true that in 6.8, the sudo part was changed quite a bit, but we
haven't heard about any bugs so far. Could you please follow:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
and also:
https://fedorahosted.org/sssd/wiki/Troubleshooting
to inspect SSSD logs? For authentication failed you'll probably want to
take a look at the domain logs and maybe the krb5_child.log

-- 
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.3.0] CentOS 6.8 sudo fails

[Nathan Peters]

I have a fresh installation of CentOS 6.8 joined to a FreeIPA 4.3.0 domain on 
Fedora 23.

When I try to sudo on this host, it fails.  Here are the log entries from 
/var/log/secure.  Note that we have several hundred CentOS 6.5-6.7 machines 
where this works fine.

Is this a new bug in CentOS 6.8?

Jun  7 20:14:48 cass1 sudo: pam_unix(sudo:auth): authentication failure; 
logname=nathan.peters uid=756600344 euid=0 tty=/dev/pts/0 ruser=nathan.peters 
rhost=  user=nathan.peters
Jun  7 20:14:48 cass1 sudo: pam_sss(sudo:auth): authentication success; 
logname=nathan.peters uid=756600344 euid=0 tty=/dev/pts/0 ruser=nathan.peters 
rhost= user=nathan.peters
Jun  7 20:14:48 cass1 sudo: nathan.peters : user NOT authorized on host ; 
TTY=pts/0 ; PWD=/home/nathan.peters ; USER=root ; COMMAND=/bin/su -
Jun  7 20:15:22 cass1 sudo: pam_unix(sudo-i:auth): conversation failed
Jun  7 20:15:22 cass1 sudo: pam_unix(sudo-i:auth): auth could not identify 
password for [nathan.peters]
Jun  7 20:15:22 cass1 sudo: pam_sss(sudo-i:auth): authentication failure; 
logname=nathan.peters uid=756600344 euid=0 tty=/dev/pts/0 ruser=nathan.peters 
rhost= user=nathan.peters
Jun  7 20:15:22 cass1 sudo: pam_sss(sudo-i:auth): received for user 
nathan.peters: 7 (Authentication failure)
Jun  7 20:15:22 cass1 sudo: nathan.peters : user NOT authorized on host ; 
TTY=pts/0 ; PWD=/home/nathan.peters ; USER=root ; COMMAND=/bin/bash
-- 
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 4.3.0] Limits exceeded for this query

[Rob Crittenden]

Nathan Peters wrote:

I get this when doing almost anything on only one of my Fedora 23
FreeIPA 4.3.0 servers.  The rest work fine.

This server also tends to crash quite a bit and the others do not.


What crashes?


Any tips on what I should be looking for or how to fix that ?


I'd look in the 389-ds access log for err=3 or 4 and see what limits 
were exceeded and potentially why.


rob



Some operations failed.

Hide details 

·limits exceeded for this query

Nathan Peters





--
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.3.0] Limits exceeded for this query

[Nathan Peters]

I get this when doing almost anything on only one of my Fedora 23 FreeIPA 4.3.0 
servers.  The rest work fine.

This server also tends to crash quite a bit and the others do not.

Any tips on what I should be looking for or how to fix that ?



Some operations failed.
Hide details

* limits exceeded for this query


Nathan Peters
-- 
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] replica +dns +ca -> ERROR Unable to retrieve CA chain

[Rob Crittenden]

lejeczek wrote:



On 25/05/16 14:19, Rob Crittenden wrote:

lejeczek wrote:

hi there,

I'm trying to set up a replica with: --setup-dns --no-forwarders
--setup-ca

installer fails at:

  [10/23]: importing CA chain to RA certificate database
   [error] RuntimeError: Unable to retrieve CA chain: [Errno 111]
Connection refused
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

more from log:

2016-05-25T12:38:31Z DEBUG   [10/23]: importing CA chain to RA
certificate database
2016-05-25T12:38:31Z DEBUG Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 418, in start_creation
 run_step(full_msg, method)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 408, in run_step
 method()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
1015, in __import_ca_chain
 chain = self.__get_ca_chain()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
997, in __get_ca_chain
 raise RuntimeError("Unable to retrieve CA chain: %s" % str(e))
RuntimeError: Unable to retrieve CA chain: [Errno 111] Connection
refused

2016-05-25T12:38:31Z DEBUG   [error] RuntimeError: Unable to retrieve CA
chain: [Errno 111] Connection refused
2016-05-25T12:38:31Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute

what might be the problem?


It is failing getting the CA chain from dogtag. It uses port 8080 by
default. I'd check your firewall and that the remote CA is up.


is 8080 needed only @installation time or all the time?
many thanks,


I think it's just needed during install but I didn't pour over the code. 
Once up the data replicates, depending on version, on 389 or 7389 and 
all other access should be proxied through 443.


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 2.2 Certificate Renewal issue

[Rob Crittenden]

Kay Zhou Y wrote:

Hi Rob,

Actually certmonger service is failed after restart it, but without its active 
the two 389-ds and apache certs could be renewed as well.. it's weird..

root@ecnshlx3039-test2(SH):~ #systemctl status certmonger
certmonger.service - Certificate monitoring and PKI enrollment
   Loaded: loaded (/usr/lib/systemd/system/certmonger.service; disabled)
   Active: failed (Result: exit-code) since Mon, 23 Jun 2014 00:31:11 
+0200; 5s ago
  Process: 2198 ExecStart=/usr/sbin/certmonger -S -p 
/var/run/certmonger.pid -n $OPTS (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/certmonger.service

Jun 23 00:31:11 ecnshlx3039-test2.sh.cn.ao.ericsson.se certmonger[2198]: 2014-06-23 
00:31:11 [2198] Unable to set well-known bus name 
"org.fedorahosted.certmonger": (2).
Jun 23 00:31:11 ecnshlx3039-test2.sh.cn.ao.ericsson.se certmonger[2198]: Error 
connecting to D-Bus.


I'm not sure why it can't connect to dbus. Is the messagebus service 
running?



I have already renewed two 389-ds and apache certs  to 20160622, however , 
since there is no enough time for us before expiration. So we try to seek other 
workarounds, and one solution for us is disable expired certificate according 
to 
https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/troubleshooting-servers-and-replicas.html#expired-certs
After test, it could work, but IPA command could not be used. But seems we can 
still get data from LDAP.

If there is any other way we could use to disable such expired certs without 
impact from your side?


It's possible but it's hacky and it trains people to disregard bad 
certificates.


rob



Thanks for your great support again :)

BR//Kay

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Friday, June 03, 2016 5:34 AM
To: Kay Zhou Y; freeipa-users@redhat.com
Cc: Doris Hongmei; Xionglin Gu
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:

Hi Rob,

We are using fedora 17.
And as you said, when I roll back time to when the CA subsystem and ipaCert are valid. 
Then restart ipatcl,  "pki-cad@pki-ca.service" is active as normal.
But these five certs could not renewed as before. (actually I always
restart ipa world after I roll back time, this
"pki-cad@pki-ca.service" should be active but I just ignore it
before... )


With the time rolled back what I'd do is restart certmonger then run in a loop 
with a 1 second sleep ipa-getcert list and ensure that the statuses are 
changing to SUBMITTING, etc., and see what the final state is. certmonger logs 
to syslog so that might give some clues what is happening, and you can watch 
the dogtag logs to ensure the requests are being received, etc.

rob



Thanks,
BR//Kay

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, June 01, 2016 10:37 PM
To: Kay Zhou Y; freeipa-users@redhat.com
Cc: Doris Hongmei; Xionglin Gu
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:

Hi Rob,

1.  I have made snapshots for this system for test, so NSS databases has been 
backed up.

2.  For the pki-cad service, I can't find it in my system, it shows there is no 
such service.
but there is one service failed as below:

root@ecnshlx3039-test2(SH):requests #systemctl status
pki-cad@pki-ca.service pki-cad@pki-ca.service - PKI Certificate Authority 
Server pki-ca
 Loaded: loaded (/lib/systemd/system/pki-cad@.service; enabled)
 Active: failed (Result: exit-code) since Wed, 01 Jun 2016 06:28:53 
+0200; 23min ago
Process: 2675 ExecStop=/usr/bin/pkicontrol stop ca %i (code=exited, 
status=1/FAILURE)
Process: 2525 ExecStart=/usr/bin/pkicontrol start ca %i 
(code=exited, status=0/SUCCESS)
   Main PID: 2593 (code=exited, status=0/SUCCESS)
 CGroup: name=systemd:/system/pki-cad@.service/pki-ca

Jun 01 06:28:49 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2549]:
pam_unix(runuser-l:session): session opened for user pkius...d=0) Jun
01 06:28:49 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2549]:
pam_unix(runuser-l:session): session closed for user pkiuser Jun 01
06:28:52 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2694]:
pam_unix(runuser-l:session): session opened for user pkius...d=0) Jun
01 06:28:53 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2694]:
pam_unix(runuser-l:session): session closed for user pkiuser

I can't start it normally, even the log just said:
Jun  1 06:54:39 ecnshlx3039-test2 systemd[1]: pki-cad@pki-ca.service:
control process exited, code=exited status=1 Jun  1 06:54:39 ecnshlx3039-test2 
systemd[1]: Unit pki-cad@pki-ca.service entered failed state.

I will google more to try to start it firstly.


Ok, this is very confusing to me. What distribution are you running? I have the 
feeling you are running an extremely outdated version of Fedora.

Yes, you need the CA up in order to get the certificates renewed. 

Re: [Freeipa-users] FreeIPA 4.2 on CentOS 7.2 restricts an access to krb* attributes

[Konstantin M. Khankin]

Thanks a ton Alexander, this permission fixed everything :)

2016-06-07 17:08 GMT+03:00 Alexander Bokovoy :

> On Tue, 07 Jun 2016, Konstantin M. Khankin wrote:
>
>> Hi Alexander!
>>
>> Here's the config (mostly auto-generated by ipa-client-install):
>>
>> -
>> [domain/gsk.loc]
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = gsk.loc
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = garage.gsk.loc
>> chpass_provider = ipa
>> ipa_server = _srv_, drone.gsk.loc
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> #ldap_search_base = cn=accounts,dc=gsk,dc=loc
>> ldap_user_extra_attrs = uid, krbLastSuccessfulAuth, krbLastFailedAuth
>>
>> [sssd]
>> services = nss, sudo, pam, ssh, ifp
>> config_file_version = 2
>>
>> domains = gsk.loc
>> [nss]
>> homedir_substring = /home
>>
>> [pam]
>>
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>>
>> [ifp]
>> allowed_uids = apache, root
>> user_attributes = +uid, +krbLastSuccessfulAuth, +krbLastFailedAuth
>>
>> -
>>
> Ok, for these there is a separate permission, 'System: Read User Kerberos
> Login Attributes'.
>
> ipa permission-show 'System: Read User Kerberos Login Attributes'
>
> It is by default assigned to 'User administrators' role. You can use
> 'ipa role-add-member' to add others, like hosts:
>
> ipa role-add-member 'User Administrator' --hosts=garage.gsk.loc
>
> --
> / 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] replication - ruv errors

[Andy Brittingham]

Hello,

I'm having issues with freeipa replication. Currently we have 4 Freeipa 
servers, in a master - master relationship with replication


agreements between all servers.

I noticed the replication failure messages in the logs late last week 
and upon investigation found stale replication agreements for


ipa servers that had been replaced. Eventually I rebuilt 3 of the 4 
servers and re-initialized from the good server.


This morning my main ipa server had the directory service crash. After 
we restarted it, ipa-manage-replica --list-ruv showed


entries like these:

unable to decode: {replica 6} 55e49446 55e49446
unable to decode: {replica 4} 550b2d9e00020004 550b2d9e00020004

Which a cleanallruv.pl was able to remove.

We also noticed these log errors:

[07/Jun/2016:07:40:12 -0400] NSMMReplicationPlugin - ruv_compare_ruv: 
RUV [changelog max RUV] does not contain element
[{replica 1080 ldap://ipa1.p10jax.auth.monetra.com:389} 
57506ee60438 57506f0600160438] which is present in

RUV [database RUV]
[07/Jun/2016:07:40:12 -0400] NSMMReplicationPlugin - ruv_compare_ruv: 
RUV [changelog max RUV] does not contain element
[{replica 1285 ldap://ipa1.gnv.auth.monetra.com:389} 
5734e4730505 57361df00505] which is present in

RUV [database RUV]
[07/Jun/2016:07:40:12 -0400] NSMMReplicationPlugin - ruv_compare_ruv: 
RUV [changelog max RUV] does not contain element
[{replica 1085 ldap://ipa1.p10jax.auth.monetra.com:389} 
56d0aa27043d 57489fdd0003043d] which is present in

RUV [database RUV]
[07/Jun/2016:07:40:12 -0400] NSMMReplicationPlugin - ruv_compare_ruv: 
RUV [changelog max RUV] does not contain element


The cleanallruv script had no effect on these errors.

What is the proper procedure to clean up these stale entries? Is there 
something that I may be doing that causes this situation?


Thanks,

Andy

--
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] AD one-way trust error ---

[Jeffrey Stormshak]

Greetings all …

I’m trying to pinpoint a problem when creating the AD trust using the following 
command below.  The error message and related details provided below.  There is 
a Bugzilla on it, however, I cannot locate any updated versions from 
RHEL/Oracle Linux channels.  That gives me the impression that I’m stuck 
without a fix or other possible resolution.  Thoughts?

Creating AD Trust Error Message:
[root@ma-ipa-server-p1 ~]# ipa trust-add DOMAIN.COM --admin Administrator 
--password
Active Directory domain administrator's password:
ipa: ERROR: CIFS server configuration does not allow access to 
\\pipe\lsarpc

Software Versions reporting error:
ipa-server-trust-ad-4.2.0-15.0.1.el7.x86_64
ipa-server-4.2.0-15.0.1.el7.x86_64

# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

# rpm -qa samba
samba-4.2.3-10.el7.x86_64

BugZilla Reported:
https://bugzilla.redhat.com/show_bug.cgi?id=1249455

Jeffrey Stormshak, RHCSA | Sr. Linux Engineer
Platform Systems | IT Operations Infrastructure
CCC Information Services, Inc.
Phone: (312) 229-2552
-- 
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 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

[Rob Crittenden]

dan.finkelst...@high5games.com wrote:

This advice has gotten me much further, thanks. We didn't have an HBAC
rule for admin and, now with it in place, connection checks and other
commands appear to be working that haven't worked before. I'm still
getting caught on the CA portion of the replica installation.
Confoundingly, neither the ipa-replica-install or ipa-ca-install
commands will complete (the former with the —setup-ca option), the
latter producing this output in the last few lines of
pareplica-ca-install.log:

2016-06-07T12:44:32Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'

2016-06-07T12:44:32Z DEBUG Checking if IPA schema is present in
ldap://ipa-replica.example.com:7389

2016-06-07T12:44:32Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa-replica.example.com:7389
conn=

2016-06-07T12:44:32Z DEBUG Check OK

2016-06-07T12:44:32Z DEBUG Destroyed connection context.ldap2_50387920

2016-06-07T12:44:32Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'

2016-06-07T12:44:32Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 732, in run_script

 return_value = main_function()

   File "/usr/sbin/ipa-ca-install", line 202, in main

 install_replica(safe_options, options, filename)

   File "/usr/sbin/ipa-ca-install", line 150, in install_replica

 ca.install(True, config, options)

   File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
106, in install

 install_step_0(standalone, replica_config, options)

   File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
130, in install_step_0

 ra_p12=getattr(options, 'ra_p12', None))

   File
"/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line
1530, in install_replica_ca

 sys.exit("A CA is already configured on this system.")

2016-06-07T12:44:32Z DEBUG The ipa-ca-install command failed, exception:
SystemExit: A CA is already configured on this system.

This occurs when I run either the replica or ca installer commands a
second time.


A second time how? Are you running ipa-server-install --uninstall in 
between?


In any case, when the CA install fails 99 times out of 100 the ipa* 
install logs will contain nothing useful. You need to dig into the CA 
logs to see why the install failed.


rob



Best regards,

Dan



*Daniel Alex Finkelstein*| Senior Dev Ops Engineer

_dan.finkelst...@h5g.com _| 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  and Shake
the Sky 

Follow us on: Facebook , Twitter
, YouTube
, Linkedin


//

/This message and any attachments may contain confidential or privileged
information and are only for the use of the intended recipient of this
message. If you are not the intended recipient, please notify the sender
by return email, and delete or destroy this and all copies of this
message and all attachments. Any unauthorized disclosure, use,
distribution, or reproduction of this message or any attachments is
prohibited and may be unlawful./

*From: *Rob Crittenden 
*Date: *Monday, June 6, 2016 at 18:08
*To: *Daniel Finkestein ,
"freeipa-users@redhat.com" 
*Subject: *Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of
FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica,
cannot promote to master

dan.finkelst...@high5games.com 
wrote:

By the way, I want to mention the conncheck: if I don't skip it, it

tries to ssh into the master IPA instance as 'admin@', rather

than the user (root), and fails. All other parts of the connectivity

check work, however. Why does it try to access the master as a Kerberos

principal instead of the process user?

Because the remote master, being an IPA server, should have an admin

account, so it's a known. root over ssh is not allowed in some environments.

There is a ticket open to be able to set the login to be used, right now

admin is hardcoded.

As for the install failure you should now have the appropriate logs to

start diagnosing what was going on in /var/log/pki.

rob

Thanks,

Dan



*Daniel Alex Finkelstein*| Senior Dev Ops Engineer

_dan.finkelst...@h5g.com 
_|
 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Rob Crittenden]

Bret Wortman wrote:



On 06/03/2016 01:04 PM, Rob Crittenden wrote:

Bret Wortman wrote:



On 06/03/2016 11:02 AM, Rob Crittenden wrote:

Bret Wortman wrote:

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
see how we go.

Rob, would you have just used the existing "localhost.key" instead of
generating a new one?


No, I think you did the right thing, the default keysize was probably
still 1024 in F21. I double-checked the getcert-request man page and
it looks like it will use an existing key if one exists in the key
file passed in so I was wrong about that bit. You just didn't need to
use req to generate a CSR as certmonger will do that for you.


Good to know.

I tried the update-ca-trust on both the yum server and on my workstation
but nothing changed even after an httpd restart. I did take a peek
inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and
didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but
I confess I'm not sure what should be where at this point).


You'd only need to do this on the machine acting as a client.

I'm pretty sure yum uses /etc/pki/nssdb. Is the IPA CA in there and
trusted?

$ certutil -L -d /etc/pki/nssdb


It's in there on both the server and client.


Hmm, this works for me on an F-21 system. I created an empty repo, added 
a yum config and was able to fetch it ok.


yum uses libcurl under the hood, you might try the same certutil command 
using sql:/etc/pki/nssdb as the NSS database and add in the IPA CA to 
see if that helps. Again, it is only needed on the client.


rob




rob




Bret


rob




On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert
request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually
going on here. You generate a CSR and call it a certificate. It is
probably the case that certmonger is ignoring it altogether and
generating its own CSR.


ipa-getcert list shows it approved. I set up SSL in apache to use
the
above .key and .crt, but when I try to run yum against this using
ssl:

# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:



[Errno 14] curl#60 - "Peer's certificate issuer has been
marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would
have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust
but I'm pretty sure it is done automatically now and I think it
was in
the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
this code.

Look at this,
https://fedoraproject.org/wiki/Features/SharedSystemCertificates

The idea is to add the IPA CA to that and then all tools using SSL
would "just work".

Something like:

# cp /etc/ipa/ca.crt
/usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your
IPA
install (and get a new CA):

# rm /etc/ipa/ca.crt
/usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more
recent
versions of IPA.

rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale
,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob

Re: [Freeipa-users] FreeOTP

[Winfried de Heiden]

  
  
No, neither HOTP works...


Op 07-06-16 om 17:09 schreef Prashant
  Bapat:


  
Do HOTP tokens work fine ?
  
  
On 7 June 2016 at 20:37, Winfried de
  Heiden 
  wrote:
  

  Hi all,
  

  Yes I check that one also. The
  IPA-server is running ntp and is is sync. The FreeOTP
  app is running on my phone which is synced by network,
  all looks fine
  
  Forgot to mention; this IPA-server is running on
  Fedora ARM on a Bananapi. non-otp logins go well.
  

  Winny

  

  
  
  
  Op 07-06-16 om 16:56 schreef Prashant Bapat:
  
  

  

  ​If this is TOTP (time
based) you want to double check the time is
properly set in both the server (NTP) and the
device that is generating the OTP tokens. I have
had issues with this with my users couple of
times. ​


  On 7 June 2016 at 19:43,
Alexander Bokovoy 
wrote:
On Tue, 07 Jun
2016, Winfried de Heiden wrote:
  
   Hi all,
  I tried the FreeIPA webUI, ssh and "su -
  otpuser", all the same result.

  Ok.

          Jun
  07 14:44:37 ipa.blabla.bla
  krb5kdc[5887](info): AS_REQ
           (6 etypes {18 17 16
           23 25 26}) 192.168.1.251:
  NEEDED_PREAUTH:
           otpu...@blabla.bla
  for krbtgt/
           blabla@blabla.bla,
  Additional pre-authentication
           required
           Jun 07 14:44:37 ipa.blabla.bla
  krb5kdc[5887](info): closing
           down fd 12
           Jun 07 14:44:42 ipa.blabla.bla
  krb5kdc[5888](info): preauth
           (otp) verify
           failure: Connection timed out
  
           I just cannot figure out what's
  going wrong. What is trying
           to connect to
           causing this timeout? (yep, I
  disabled firewalld for
           this...)

   What is the output of  systemctl
  status ipa-otpd.socket
  ?
  
  if it is disabled, do
  
   systemctl enable ipa-otpd.socket
   systemctl start ipa-otpd.socket
  

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

  

  
  

  
  

  

  


  


  


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

[Freeipa-users] How to get FreeIPA feature requests ack'd?

[Cal Sawyer]

Hello

The RH Bugzilla is pretty much unnavigable by anyone who doesn't know 
the magic words, so i'm asking here. Apologies in advance if misdirected.


The Web UI has a couple of fairly annoying (sorry) deficiencies:

- unable to sort on columns, eg: In DNS Zones, the sort is on hostname, 
making it difficult to locate holes in a network range. This is easy in 
BIND flat zone files, which by convention are usually organised by IP 
address
- of course, sorting on IP address needs to be done like mySQL's 
ORDER BY INET_ATON(ip) to prevent what i like to call "Mac-style" 
ordering of IP addresses (1, 10 100, 2)
- record and subtree cloning would be a terrific feature when working 
with automount maps and sudo objects that are fiddly to edit in the UI. 
Essentially, what phpldapadmin allows


thank you,

- cal sawyer

--
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] IPA to supply radius with a special user name - how?

[lejeczek]

hi users,

some network devices need and look up special type of a 
user, in my case it's dell powerconnect switch which - when 
uses radius - needs,eg: $enable5$.


I this something that IPA will be ok with? will have no 
problems if I create such a user? I don't suppose IPA have 
full support for radius attributes, right? or --addattr=STR 
is something for that?


How does one create radius typical user?

many thanks,

L.

--
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] DNA Ranges

[Rob Crittenden]

Michael Rainey (Contractor) wrote:

Greetings Community,

I have a question about restoring the DNA Ranges on my IPA servers.  A
couple of weeks ago I took down one of my servers which involved a few
issues I had created for myself, but luckily I managed to recover.
Today I noticed that the DNA Ranges on the retired server was not
carried over to the new server.  After checking my other servers, I also
noticed none of the other servers have any ranges set.  So, my primary
question is; if I reset the range values to what they were on the
retired server to the new server, do I run the risk of generating
duplicate UIDs and GIDs, or should I set a new range to prevent
duplicate values?

At this point, I haven't found anything in my research which matches my
current scenario.


You don't mention which version of IPA you have. If you have 4.x+ then 
you can use ipa-replica-manage to manage the DNA ranges.


You shouldn't have any problems setting a new range. Being careful about 
overlap is good but I'm pretty sure the uniqueness plugin will prevent 
duplicate UID/GID but I haven't experimented with it. I typically 
recommend ensuring that there is no overlap when setting a new range.


Re-using the range from another server should carry no risk as long as 
only one master is offering that range.


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

[Prashant Bapat]

Do HOTP tokens work fine ?

On 7 June 2016 at 20:37, Winfried de Heiden  wrote:

> Hi all,
>
>
> Yes I check that one also. The IPA-server is running ntp and is is sync.
> The FreeOTP app is running on my phone which is synced by network, all
> looks fine
>
>
> Forgot to mention; this IPA-server is running on Fedora ARM on a Bananapi.
> non-otp logins go well.
>
>
> Winny
>
>
>
>
> Op 07-06-16 om 16:56 schreef Prashant Bapat:
>
> ​If this is TOTP (time based) you want to double check the time is
> properly set in both the server (NTP) and the device that is generating the
> OTP tokens. I have had issues with this with my users couple of times. ​
>
> On 7 June 2016 at 19:43, Alexander Bokovoy  wrote:
>
>> On Tue, 07 Jun 2016, Winfried de Heiden wrote:
>>
>>> Hi all,
>>> I tried the FreeIPA webUI, ssh and "su - otpuser", all the same result.
>>>
>> Ok.
>>
>>  Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ
>>>  (6 etypes {18 17 16
>>>  23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
>>>  otpu...@blabla.bla for krbtgt/
>>>  blabla@blabla.bla, Additional pre-authentication
>>>  required
>>>  Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing
>>>  down fd 12
>>>  Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
>>>  (otp) verify
>>>  failure: Connection timed out
>>>
>>>  I just cannot figure out what's going wrong. What is trying
>>>  to connect to
>>>  causing this timeout? (yep, I disabled firewalld for
>>>  this...)
>>>
>> What is the output of  systemctl status ipa-otpd.socket
>> ?
>>
>> if it is disabled, do
>>
>>  systemctl enable ipa-otpd.socket
>>  systemctl start ipa-otpd.socket
>>
>>
>> --
>> / Alexander Bokovoy
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeOTP

[Winfried de Heiden]

  
  
Hi all,

  
Yes I check that one also. The IPA-server is
running ntp and is is sync. The FreeOTP app is running on my
phone which is synced by network, all looks fine

Forgot to mention; this IPA-server is running on Fedora ARM on a
Bananapi. non-otp logins go well.

  
Winny
  

  



Op 07-06-16 om 16:56 schreef Prashant
  Bapat:


  
​If this is TOTP (time based) you want to
  double check the time is properly set in both the server (NTP)
  and the device that is generating the OTP tokens. I have had
  issues with this with my users couple of times. ​
  
  
On 7 June 2016 at 19:43, Alexander
  Bokovoy 
  wrote:
  On Tue, 07 Jun 2016, Winfried de Heiden wrote:


  Hi all,
I tried the FreeIPA webUI, ssh and "su - otpuser", all
the same result.
  
Ok.
  
  
         Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): AS_REQ
         (6 etypes {18 17 16
         23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
         otpu...@blabla.bla for krbtgt/
         blabla@blabla.bla, Additional
pre-authentication
         required
         Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): closing
         down fd 12
         Jun 07 14:44:42 ipa.blabla.bla
krb5kdc[5888](info): preauth
         (otp) verify
         failure: Connection timed out

         I just cannot figure out what's going wrong.
What is trying
         to connect to
         causing this timeout? (yep, I disabled
firewalld for
         this...)
  

What is the output of  systemctl status ipa-otpd.socket
?

if it is disabled, do

 systemctl enable ipa-otpd.socket
 systemctl start ipa-otpd.socket

  

-- 
/ Alexander Bokovoy

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

  


  


  


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

Re: [Freeipa-users] how to setup apache reverse https proxy for freeipa web UI

[Anthony Clark]

Apparently removing the GSSAPI AuthType breaks foreman-proxy, so I had to
do this:


  
AuthType GSSAPI
AuthName "Kerberos Login"
GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab
GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab
GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches
GssapiUseS4U2Proxy on
Require valid-user
ErrorDocument 401 /ipa/errors/unauthorized.html
  
WSGIProcessGroup ipa
WSGIApplicationGroup ipa


Apologies for the post spam.

On Tue, Jun 7, 2016 at 9:50 AM, Anthony Clark 
wrote:

> One thing I noticed was that once I had set up the proxy as per the
> document from Jan, I was getting access denied to /ipa until I disabled the
> Kerberos authentication stuff:
>
> # Protect /ipa and everything below it in webspace with Apache Kerberos
> auth
> 
> #  AuthType GSSAPI
> #  AuthName "Kerberos Login"
> #  GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab
> #  GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab
> #  GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches
> #  GssapiUseS4U2Proxy on
> #  Require valid-user
> #  ErrorDocument 401 /ipa/errors/unauthorized.html
>   WSGIProcessGroup ipa
>   WSGIApplicationGroup ipa
> 
>
>
>
> Once that change was made, the following proxy worked:
>
> Listen 9443
>
> 
>
> ErrorLog /etc/httpd/logs/password-error_log
> TransferLog /etc/httpd/logs/password-access_log
> LogLevel debug
>
> NSSEngine on
>
> NSSCipherSuite
> +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
>
> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
>
> NSSNickname Server-Cert
>
> NSSCertificateDatabase /etc/httpd/alias
>
> NSSProxyEngine on
> NSSProxyCipherSuite
> +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
>
> ProxyPass / https://ns01.dev.example.net/
> ProxyPassReverse / https://ns01.dev.example.net/
> ProxyPassReverseCookieDomain ns01.dev.example.net password.example.net
> RequestHeader edit Referer ^https://password\.example\.net/
> https://ns01.dev.example.net/
> 
>
> I hope this helps someone down the line.
>
> -Anthony Clark
>
>
> On Mon, Jun 6, 2016 at 7:29 AM, Karl Forner  wrote:
>
>> Thanks a lot Jan. It works perfectly, and it is crystal-clear.
>> Best,
>> Karl
>>
>> On Mon, Jun 6, 2016 at 11:13 AM, Jan Pazdziora 
>> wrote:
>> > On Fri, Jun 03, 2016 at 10:42:59PM +0200, Jan Pazdziora wrote:
>> >>
>> >> Hope this helps. I will likely do another writeup about this setup.
>> >
>> >
>> https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name
>> >
>> > --
>> > Jan Pazdziora
>> > Senior Principal Software Engineer, Identity Management Engineering,
>> Red Hat
>>
>> --
>> 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] FreeOTP

[Prashant Bapat]

​If this is TOTP (time based) you want to double check the time is properly
set in both the server (NTP) and the device that is generating the OTP
tokens. I have had issues with this with my users couple of times. ​

On 7 June 2016 at 19:43, Alexander Bokovoy  wrote:

> On Tue, 07 Jun 2016, Winfried de Heiden wrote:
>
>> Hi all,
>> I tried the FreeIPA webUI, ssh and "su - otpuser", all the same result.
>>
> Ok.
>
>  Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ
>>  (6 etypes {18 17 16
>>  23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
>>  otpu...@blabla.bla for krbtgt/
>>  blabla@blabla.bla, Additional pre-authentication
>>  required
>>  Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing
>>  down fd 12
>>  Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
>>  (otp) verify
>>  failure: Connection timed out
>>
>>  I just cannot figure out what's going wrong. What is trying
>>  to connect to
>>  causing this timeout? (yep, I disabled firewalld for
>>  this...)
>>
> What is the output of  systemctl status ipa-otpd.socket
> ?
>
> if it is disabled, do
>
>  systemctl enable ipa-otpd.socket
>  systemctl start ipa-otpd.socket
>
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] question about automount config

[Prasun Gera]

>From your errors, it looks like sssd is not able to find the autofs
entries. In order to confirm that, you can add the autofs mapping manually
to your config file (under /etc/auto.* depending on your config), and test
if that works. If you can get that to work, the problem lies in
freeipa/sssd configuration. I see that you are using sec=krb5. You may want
to disable kerberos too while debugging, both at the nfs server export
config, and at the client/automount config.

On Tue, Jun 7, 2016 at 9:10 AM, Arthur Fayzullin  wrote:

> I have done like You said. Here is output:
> [root@nfsclient ~]# automount -vvvf
> 1  Starting automounter version 5.1.1-3.fc23, master map auto.master
> 2  using kernel protocol version 5.02
> 3  mounted indirect on /misc with timeout 300, freq 75 seconds
> 4  mounted indirect on /net with timeout 300, freq 75 seconds
> 5  mounted indirect on /home with timeout 300, freq 75 seconds
> 6  lookup_read_map: lookup(sss): getautomntent_r: No such file or directory
> 7  attempting to mount entry /home/afayzullin
> 8  >> mount.nfs4: Connection timed out
> 9  mount(nfs): nfs: mount failure nfserver.ciktrb.ru:/home/afayzullin on
> /home/afayzullin
> 10 failed to mount /home/afayzullin
> 11 re-reading map for /home
> 12 attempting to mount entry /home/afayzullin
>
> from string 1 till 6 is startup output. I have googled by
> 'getautomntent_r', it has shown some closed threads that should be fixed
> (line 3, 4, 5 shows that it is ok)
> from line 7 I try to login as afayzullin and autofs tries to mount it as I
> wish, but for some reason it can not.
> How can I know why it can not do it? Where to look for it?
>
> also I have put debug_level=6 in [autofs] at /etc/sssd/sssd.conf and here
> is a piece from /var/log/sssd/sssd_autofs.log
>
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [accept_fd_handler] (0x0400):
> Client connected!
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_cmd_get_version] (0x0200):
> Received client version [1].
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_cmd_get_version] (0x0200):
> Offered version [1].
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_autofs_cmd_setautomntent]
> (0x0400): Got request for automount map named auto.home
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_parse_name_for_domains]
> (0x0200): name 'auto.home' matched without domain, user is auto.home
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [setautomntent_send] (0x0400):
> Requesting info for automount map [auto.home] from []
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
> (0x0400): Requesting info for [auto.h...@ciktrb.ru]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_get_autofs_msg]
> (0x0400): Creating autofs request for [ciktrb.ru][4105][mapname=auto.home]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_internal_get_send]
> (0x0400): Entering request [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
> (0x0400): Requesting info for [auto.h...@ciktrb.ru]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sysdb_autofs_entries_by_map]
> (0x0400): Getting entries for map auto.home
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
> (0x0400): setautomntent done for map auto.home
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]]
> [sss_autofs_cmd_setautomntent_done] (0x0400): setautomntent found data
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_req_destructor]
> (0x0400): Deleting request: [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]]
> [sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map auto.home
> key afayzullin
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [getautomntbyname_process]
> (0x0080): No key named [afayzullin] found
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]]
> [sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map auto.home
> key /
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [getautomntbyname_process]
> (0x0080): No key named [/] found
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]]
> [sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map auto.home
> key *
> (Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_autofs_cmd_endautomntent]
> (0x0400): endautomntent called
>
> While manual mount works fine:
> # mount -vvv -t nfs4 nfserver.ciktrb.ru:/home/afayzullin /mnt
> mount.nfs4: timeout set for Tue Jun  7 17:07:25 2016
> mount.nfs4: trying text-based options
> 'vers=4.2,addr=10.254.1.167,clientaddr=10.254.1.168'
> [root@nfsclient ~]# echo $?
> 0
> [root@nfsclient ~]# mount -l
> nfserver.ciktrb.ru:/home/afayzullin on /mnt type nfs4
> (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.254.1.168,local_lock=none,addr=10.254.1.167)
>
> $ ssh nfsclient
> Creating home directory for 

Re: [Freeipa-users] FreeOTP

[Alexander Bokovoy]

On Tue, 07 Jun 2016, Winfried de Heiden wrote:

Hi all,
I tried the FreeIPA webUI, ssh and "su - otpuser", all the same result.

Ok.


 Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ
 (6 etypes {18 17 16
 23 25 26}) 192.168.1.251: NEEDED_PREAUTH:
 otpu...@blabla.bla for krbtgt/
 blabla@blabla.bla, Additional pre-authentication
 required
 Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing
 down fd 12
 Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
 (otp) verify
 failure: Connection timed out

 I just cannot figure out what's going wrong. What is trying
 to connect to
 causing this timeout? (yep, I disabled firewalld for
 this...)
What is the output of 
 systemctl status ipa-otpd.socket

?

if it is disabled, do

 systemctl enable ipa-otpd.socket
 systemctl start ipa-otpd.socket

--
/ 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] Replica without CA: implications?

[Cal Sawyer]

For the benefit, or added confusion, of future generations, some 
observations


ipa-ca-install, run successful replica instantiation w/o --setup-ca 
fails consistently with the errors in my orig post. Never figured out 
what the script was finding that needed purging.  After a multitude of 
attempts (thank you, ESXi snapshots) with multiple ipa-server-install 
--uninstall's , i gave up and rebuilt from the gound up withlatest 
packages and --setup-ca which works great


I found that installing a replica with firewalld enabled would 
consistently fail during initial replication.  Disabling firewalld 
always allowed replication and later stages to complete


  [24/38]: setting up initial replication
   Starting replication, please wait until this has completed.

   [ipa.localdomain.local] reports: Update failed! Status: [-1  - LDAP
   error: Can't contact LDAP server]


The first master and all replicas are all CentOS Linux release 7.2.1511 
(Core) with ipa-server-4.2.0-15.0.1.el7



One other thing.  if, during ipa-replica-install,+ you choose the 
default answer to the following:


Existing BIND configuration detected, overwrite? [no]:
ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting 
installation.


Not sure if that is intended?  Which BIND configuration is being detected?

Anyhow, up and running with 4 replicas, 2 of which will be split off to 
a failover instance of ESXi in the future.  When it works, it's a joy


Now back to getting these Mac clients to play nicely with IPA ...

thanks for the help and advice

- cal

On 02/06/16 22:27, Rob Crittenden wrote:

Cal Sawyer wrote:

Apologies for the lengthy pause in getting back onto this.  I ended up
destroying the replica and reprovisioning frmm scratch, but the replica
still lists as being CA-less.

Is what i'm seeing normal?  Would this 2-node setup in this state
survive failure of the master?


It will until the certificates start expiring. You want at least 2 
CA's to avoid a single point of failure situation.




-

ON MASTER ipa.localdomain.local

#  ipa-replica-manage list

ipa2.localdomain.local: master
ipa.localdomain.local: master

# ipa-csreplica-manage list

 >> ipa2.localdomain.local: CA not configured
ipa.localdomain.local: master


--

ON REPLICA ipa2.localdomain.local

# ipa-ca-install
Directory Manager (existing master) password:

 >> CA is already installed.

ok 

# ipa-ca-install -d



ipa.ipaserver.plugins.ldap2.ldap2: DEBUGCreated connection
context.ldap2_73731152
ipa.ipalib.plugins.config.config_show: DEBUGraw:
config_show(version=u'2.156')
ipa.ipalib.plugins.config.config_show: DEBUG config_show(rights=False,
all=False, raw=False, version=u'2.156')
ipa.ipapython.ipaldap.SchemaCache: DEBUGretrieving schema for
SchemaCache url=ldapi://%2fvar%2frun%2fslapd-LOCALDOMAIN-LOCAL.socket
conn=
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUGraw:
ca_is_enabled(version=u'2.156')
ipa.ipalib.plugins.cert.ca_is_enabled: DEBUG
ca_is_enabled(version=u'2.156')
ipa : DEBUG  File
"/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
line 732, in run_script
 return_value = main_function()

   File "/usr/sbin/ipa-ca-install", line 204, in main
 install_master(safe_options, options)

   File "/usr/sbin/ipa-ca-install", line 191, in install_master
 ca.install_check(True, None, options)

   File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
49, in install_check
 sys.exit("CA is already installed.\n")

ipa : DEBUGThe ipa-ca-install command failed, exception:
SystemExit: CA is already installed.

 >> CA is already installed.


It detects whether a CA is installed by the existence of something 
like /var/lib/pki-tomcat/ca. You can use pkidestroy to remove any 
remnants that might be left over from some previous failed install.


Or it could be that something wasn't updated properly in LDAP and 
there actually is a working CA. You might try manually starting the CA 
to see if it comes up, and/or run ipa-csreplica-manage to see if there 
are any working agreements.


rob







thanks

- cal sawyer



On 09/03/16 16:13, Simo Sorce wrote:

On Wed, 2016-03-09 at 15:59 +, Cal Sawyer wrote:

Hi

Somehow i picked the wrong cookbook when i provisioned my first (and
only) replica and it lacks CA aso, as pointed out in a recent thread,
creates a single point of failure.  Not ready to set up more 2 
replicas

yet and am still in testing.  Is it possible to replicate the master's
CA to the replica without destroying and reprovisioning with 
--setup-ca

this time?

Use ipa-ca-install on the replica.

Simo.







-- 
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 4.2 on CentOS 7.2 restricts an access to krb* attributes

[Alexander Bokovoy]

On Tue, 07 Jun 2016, Konstantin M. Khankin wrote:

Hi Alexander!

Here's the config (mostly auto-generated by ipa-client-install):
-
[domain/gsk.loc]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = gsk.loc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = garage.gsk.loc
chpass_provider = ipa
ipa_server = _srv_, drone.gsk.loc
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_search_base = cn=accounts,dc=gsk,dc=loc
ldap_user_extra_attrs = uid, krbLastSuccessfulAuth, krbLastFailedAuth

[sssd]
services = nss, sudo, pam, ssh, ifp
config_file_version = 2

domains = gsk.loc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]
allowed_uids = apache, root
user_attributes = +uid, +krbLastSuccessfulAuth, +krbLastFailedAuth
-

Ok, for these there is a separate permission, 'System: Read User Kerberos Login 
Attributes'.

ipa permission-show 'System: Read User Kerberos Login Attributes'

It is by default assigned to 'User administrators' role. You can use
'ipa role-add-member' to add others, like hosts:

ipa role-add-member 'User Administrator' --hosts=garage.gsk.loc

--
/ 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] how to setup apache reverse https proxy for freeipa web UI

[Anthony Clark]

One thing I noticed was that once I had set up the proxy as per the
document from Jan, I was getting access denied to /ipa until I disabled the
Kerberos authentication stuff:

# Protect /ipa and everything below it in webspace with Apache Kerberos auth

#  AuthType GSSAPI
#  AuthName "Kerberos Login"
#  GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab
#  GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab
#  GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches
#  GssapiUseS4U2Proxy on
#  Require valid-user
#  ErrorDocument 401 /ipa/errors/unauthorized.html
  WSGIProcessGroup ipa
  WSGIApplicationGroup ipa




Once that change was made, the following proxy worked:

Listen 9443



ErrorLog /etc/httpd/logs/password-error_log
TransferLog /etc/httpd/logs/password-access_log
LogLevel debug

NSSEngine on

NSSCipherSuite
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

NSSNickname Server-Cert

NSSCertificateDatabase /etc/httpd/alias

NSSProxyEngine on
NSSProxyCipherSuite
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

ProxyPass / https://ns01.dev.example.net/
ProxyPassReverse / https://ns01.dev.example.net/
ProxyPassReverseCookieDomain ns01.dev.example.net password.example.net
RequestHeader edit Referer ^https://password\.example\.net/
https://ns01.dev.example.net/


I hope this helps someone down the line.

-Anthony Clark


On Mon, Jun 6, 2016 at 7:29 AM, Karl Forner  wrote:

> Thanks a lot Jan. It works perfectly, and it is crystal-clear.
> Best,
> Karl
>
> On Mon, Jun 6, 2016 at 11:13 AM, Jan Pazdziora 
> wrote:
> > On Fri, Jun 03, 2016 at 10:42:59PM +0200, Jan Pazdziora wrote:
> >>
> >> Hope this helps. I will likely do another writeup about this setup.
> >
> > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name
> >
> > --
> > Jan Pazdziora
> > Senior Principal Software Engineer, Identity Management Engineering, Red
> Hat
>
> --
> 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] FreeOTP

[Winfried de Heiden]

  
  
Hi all,
I tried the FreeIPA webUI, ssh and "su -
  otpuser", all the same result.
  
  Winny
  

Op 07-06-16 om 15:02 schreef Alexander
  Bokovoy:

On Tue, 07 Jun 2016, Winfried de Heiden wrote:
  
  Hi all,


I am trying to setup Freeipa with otp using the freeotp app. All
looks fine,

adding the user to the FreeOTP app also works fine. The users
looks like:

ipa user-show otpuser

  User login: otpuser

  First name: otp

  Last name: user

  Home directory: /home/otpuser

  Login shell: /bin/bash

  Email address: otpu...@blabla.bla

  UID: 10011

  GID: 10011

  User authentication types: otp

  Account disabled: False

  Password: True

  Member of groups: ipausers

  Kerberos keys available: True


However, trying to login in will fail; /var/log/krb5kdc.log will
tell:


Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ (6
etypes {18 17 16

23 25 26}) 192.168.1.251: NEEDED_PREAUTH: otpu...@blabla.bla for
krbtgt/

blabla@blabla.bla, Additional pre-authentication required

Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing down
fd 12

Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
(otp) verify

failure: Connection timed out


I just cannot figure out what's going wrong. What is trying to
connect to

causing this timeout? (yep, I disabled firewalld for this...)

  
  How did you try to login?
  
  
  


  


-- 
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 4.2 on CentOS 7.2 restricts an access to krb* attributes

[Konstantin M. Khankin]

Hi Alexander!

Here's the config (mostly auto-generated by ipa-client-install):
-
[domain/gsk.loc]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = gsk.loc
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = garage.gsk.loc
chpass_provider = ipa
ipa_server = _srv_, drone.gsk.loc
ldap_tls_cacert = /etc/ipa/ca.crt
#ldap_search_base = cn=accounts,dc=gsk,dc=loc
ldap_user_extra_attrs = uid, krbLastSuccessfulAuth, krbLastFailedAuth

[sssd]
services = nss, sudo, pam, ssh, ifp
config_file_version = 2

domains = gsk.loc
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]
allowed_uids = apache, root
user_attributes = +uid, +krbLastSuccessfulAuth, +krbLastFailedAuth
-

In debug logs I can see that sssd establishes secure connection using host/
principal:

(Tue Jun  7 18:08:36 2016) [sssd[be[gsk.loc]]] [sasl_bind_send] (0x0100):
Executing sasl bind mech: GSSAPI, user: host/garage.gsk.loc
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [child_sig_handler]
(0x0100): child [2377] finished successfully.
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [fo_set_port_status]
(0x0100): Marking port 389 of server 'drone.gsk.loc' as 'working'
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [set_server_common_status]
(0x0100): Marking server 'drone.gsk.loc' as 'working'
(Tue Jun  7 18:08:37 2016) [sssd[be[gsk.loc]]] [fo_set_port_status]
(0x0400): Marking port 389 of duplicate server 'drone.gsk.loc' as 'working'

But this is what happens when I query info via dbus:

...
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): Adding uid [hc] to attributes of [hc].
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): krbLastSuccessfulAuth is not available for [hc].
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sdap_attrs_add_ldap_attr]
(0x2000): krbLastFailedAuth is not available for [hc].
...
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sysdb_remove_attrs]
(0x2000): Removing attribute [krbLastSuccessfulAuth] from [hc]
(Tue Jun  7 17:55:32 2016) [sssd[be[gsk.loc]]] [sysdb_remove_attrs]
(0x2000): Removing attribute [krbLastFailedAuth] from [hc]
...

> FreeIPA 4.x has enhanced ACIs but it mostly means there are less
> attributes accessible to non-authenticated (anonymous) connections. Once
> you are authenticated, most of the attributes which were accessed by
> anonymous connections before are now available.

Where can I see and/or control these ACIs?

Thanks!


2016-06-07 16:40 GMT+03:00 Alexander Bokovoy :

> On Tue, 07 Jun 2016, Konstantin M. Khankin wrote:
>
>> HI!
>>
>> I used to run FreeIPA 3.0 on CentOS 6 but recently upgraded this setup to
>> FreeIPA 4.2 on CentOS 7.2. And I got 2 my applications failing, because
>> they were accessing LDAP fields krb* (one by itself, another through
>> mod_lookup_identity). For the one which makes LDAP requests by its own I
>> created an account and LDAP happily gives an access to krb* fields once
>> that app makes simple bind
>>
> FreeIPA 4.x has enhanced ACIs but it mostly means there are less
> attributes accessible to non-authenticated (anonymous) connections. Once
> you are authenticated, most of the attributes which were accessed by
> anonymous connections before are now available.
>
> But with the one which relies on mod_lookup_identity I'm having troubles.
>> Even though SSSD is being authenticated through GSSAPI, LDAP does not give
>> an access to krb* fields. I tried to create a separate service record for
>> SSSD - no change. And I couldn't make SSSD do simple bind instead of using
>> GSSAPI. I tried to setup FreeIPA so that by default it gives an access to
>> krb* fields, but web interface rejected that change
>>
>> Could you please help me with this issue? How can I control this behavior
>> properly, not with ugly hacks?
>>
> Can you show your SSSD configuration? host/ principals should be just
> fine to access krb* attributes.
>
>
> --
> / Alexander Bokovoy
>



-- 
Konstantin Khankin
-- 
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] question about automount config

[Arthur Fayzullin]

I have done like You said. Here is output:

[root@nfsclient ~]# automount -vvvf
1  Starting automounter version 5.1.1-3.fc23, master map auto.master
2  using kernel protocol version 5.02
3  mounted indirect on /misc with timeout 300, freq 75 seconds
4  mounted indirect on /net with timeout 300, freq 75 seconds
5  mounted indirect on /home with timeout 300, freq 75 seconds
6  lookup_read_map: lookup(sss): getautomntent_r: No such file or directory
7  attempting to mount entry /home/afayzullin
8  >> mount.nfs4: Connection timed out
9  mount(nfs): nfs: mount failure nfserver.ciktrb.ru:/home/afayzullin on
/home/afayzullin
10 failed to mount /home/afayzullin
11 re-reading map for /home
12 attempting to mount entry /home/afayzullin

from string 1 till 6 is startup output. I have googled by
'getautomntent_r', it has shown some closed threads that should be fixed
(line 3, 4, 5 shows that it is ok)
from line 7 I try to login as afayzullin and autofs tries to mount it as
I wish, but for some reason it can not.
How can I know why it can not do it? Where to look for it?

also I have put debug_level=6 in [autofs] at /etc/sssd/sssd.conf and
here is a piece from /var/log/sssd/sssd_autofs.log

(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [accept_fd_handler] (0x0400):
Client connected!
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_cmd_get_version]
(0x0200): Received client version [1].
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_cmd_get_version]
(0x0200): Offered version [1].
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_autofs_cmd_setautomntent]
(0x0400): Got request for automount map named auto.home
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_parse_name_for_domains]
(0x0200): name 'auto.home' matched without domain, user is auto.home
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [setautomntent_send] (0x0400):
Requesting info for automount map [auto.home] from []
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
(0x0400): Requesting info for [auto.h...@ciktrb.ru]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_issue_request]
(0x0400): Issuing request for [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_get_autofs_msg]
(0x0400): Creating autofs request for [ciktrb.ru][4105][mapname=auto.home]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_internal_get_send]
(0x0400): Entering request [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
(0x0400): Requesting info for [auto.h...@ciktrb.ru]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sysdb_autofs_entries_by_map]
(0x0400): Getting entries for map auto.home
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [lookup_automntmap_step]
(0x0400): setautomntent done for map auto.home
(Tue Jun  7 15:59:58 2016) [sssd[autofs]]
[sss_autofs_cmd_setautomntent_done] (0x0400): setautomntent found data
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_dp_req_destructor]
(0x0400): Deleting request: [0x558ed3ebab90:0:auto.h...@ciktrb.ru]
(Tue Jun  7 15:59:58 2016) [sssd[autofs]]
[sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map
auto.home key afayzullin
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [getautomntbyname_process]
(0x0080): No key named [afayzullin] found
(Tue Jun  7 15:59:58 2016) [sssd[autofs]]
[sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map
auto.home key /
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [getautomntbyname_process]
(0x0080): No key named [/] found
(Tue Jun  7 15:59:58 2016) [sssd[autofs]]
[sss_autofs_cmd_getautomntbyname] (0x0400): Requested data of map
auto.home key *
(Tue Jun  7 15:59:58 2016) [sssd[autofs]] [sss_autofs_cmd_endautomntent]
(0x0400): endautomntent called

While manual mount works fine:
# mount -vvv -t nfs4 nfserver.ciktrb.ru:/home/afayzullin /mnt
mount.nfs4: timeout set for Tue Jun  7 17:07:25 2016
mount.nfs4: trying text-based options
'vers=4.2,addr=10.254.1.167,clientaddr=10.254.1.168'
[root@nfsclient ~]# echo $?
0
[root@nfsclient ~]# mount -l
nfserver.ciktrb.ru:/home/afayzullin on /mnt type nfs4
(rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.254.1.168,local_lock=none,addr=10.254.1.167)

$ ssh nfsclient
Creating home directory for afayzullin.
Last login: Tue Jun  7 17:34:14 2016
Could not chdir to home directory /home/afayzullin: No such file or
directory
-bash-4.3$ ll /mnt
итого 0
-rw-rw-r--. 1 afayzullin afayzullin 0 июн  7 17:00 test

but home is empty
# ll /home/
итого 0

So what steps should I take next?

24.05.2016 18:01, Prasun Gera пишет:
> You can stop the autofs daemon, and run it in foreground with
> automount -fvv. Then try to access the mount point in parallel. The
> logs from the foreground run should shed some light. Also, does your
> autofs setup work without kerberos ? As a first step it to work with
> non-kerberised nfs. 
>
> On Mon, May 23, 2016 at 11:06 AM, Arthur Fayzullin  > 

Re: [Freeipa-users] FreeOTP

[Alexander Bokovoy]

On Tue, 07 Jun 2016, Winfried de Heiden wrote:

Hi all,

I am trying to setup Freeipa with otp using the freeotp app. All looks fine,
adding the user to the FreeOTP app also works fine. The users looks like:
ipa user-show otpuser
  User login: otpuser
  First name: otp
  Last name: user
  Home directory: /home/otpuser
  Login shell: /bin/bash
  Email address: otpu...@blabla.bla
  UID: 10011
  GID: 10011
  User authentication types: otp
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

However, trying to login in will fail; /var/log/krb5kdc.log will tell:

Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): AS_REQ (6 etypes {18 17 16
23 25 26}) 192.168.1.251: NEEDED_PREAUTH: otpu...@blabla.bla for krbtgt/
blabla@blabla.bla, Additional pre-authentication required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing down fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth (otp) verify
failure: Connection timed out

I just cannot figure out what's going wrong. What is trying to connect to
causing this timeout? (yep, I disabled firewalld for this...)

How did you try to login?


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

[Winfried de Heiden]

  
  
Hi all,

I am trying to setup Freeipa with otp using the freeotp app. All
looks fine, adding the user to the FreeOTP app also works fine.
The users looks like:
ipa user-show otpuser
  User login: otpuser
  First name: otp
  Last name: user
  Home directory: /home/otpuser
  Login shell: /bin/bash
  Email address: otpu...@blabla.bla
  UID: 10011
  GID: 10011
  User authentication types: otp
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

However, trying to login in will fail; /var/log/krb5kdc.log will
tell:

  
Jun 07 14:44:37 ipa.blabla.bla
krb5kdc[5887](info): AS_REQ (6 etypes {18 17 16 23 25 26})
192.168.1.251: NEEDED_PREAUTH: otpu...@blabla.bla for
krbtgt/blabla@blabla.bla, Additional pre-authentication
required
Jun 07 14:44:37 ipa.blabla.bla krb5kdc[5887](info): closing down
fd 12
Jun 07 14:44:42 ipa.blabla.bla krb5kdc[5888](info): preauth
(otp) verify failure: Connection timed out
  


I just cannot figure out what's going wrong.
What is trying to connect to causing this timeout? (yep, I
disabled firewalld for this...)

  
Winny

  
  


-- 
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] Using our IPA CA as a trusted CA to sign ssl certificates

[Bret Wortman]

On 06/03/2016 01:04 PM, Rob Crittenden wrote:

Bret Wortman wrote:



On 06/03/2016 11:02 AM, Rob Crittenden wrote:

Bret Wortman wrote:

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
see how we go.

Rob, would you have just used the existing "localhost.key" instead of
generating a new one?


No, I think you did the right thing, the default keysize was probably
still 1024 in F21. I double-checked the getcert-request man page and
it looks like it will use an existing key if one exists in the key
file passed in so I was wrong about that bit. You just didn't need to
use req to generate a CSR as certmonger will do that for you.


Good to know.

I tried the update-ca-trust on both the yum server and on my workstation
but nothing changed even after an httpd restart. I did take a peek
inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and
didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but
I confess I'm not sure what should be where at this point).


You'd only need to do this on the machine acting as a client.

I'm pretty sure yum uses /etc/pki/nssdb. Is the IPA CA in there and 
trusted?


$ certutil -L -d /etc/pki/nssdb


It's in there on both the server and client.


rob




Bret


rob




On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert
request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually
going on here. You generate a CSR and call it a certificate. It is
probably the case that certmonger is ignoring it altogether and
generating its own CSR.

ipa-getcert list shows it approved. I set up SSL in apache to use 
the
above .key and .crt, but when I try to run yum against this using 
ssl:


# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml: 




[Errno 14] curl#60 - "Peer's certificate issuer has been 
marked as

not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would
have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust
but I'm pretty sure it is done automatically now and I think it 
was in

the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
this code.

Look at this,
https://fedoraproject.org/wiki/Features/SharedSystemCertificates

The idea is to add the IPA CA to that and then all tools using SSL
would "just work".

Something like:

# cp /etc/ipa/ca.crt 
/usr/share/pki/ca-trust-source/anchors/ipa-ca.pem

# update-ca-trust

You'd need to remember to manually undo this if you ever redo your 
IPA

install (and get a new CA):

# rm /etc/ipa/ca.crt 
/usr/share/pki/ca-trust-source/anchors/ipa-ca.pem

# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more 
recent

versions of IPA.

rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale 
,

wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob 
Crittenden,

wrote:

Bret Wortman wrote:
Is it possible to use our freeipa CA as a trusted CA to sign 
our

internal SSL certificates? Our system runs on a private network
and so
using the usual trusted sources isn't an option. We've been 
using

self-signed, but that adds some additional complications and we