[Freeipa-users] FreeIPA vs DogTag CA

[Kamal Perera]

Dear all,

Seeking your kind advices.

If the requirement is for having a scalable corporate CA only, is it
possible to get this requirement fulfilled with DogTag only, or install
FreeIPA and use the CA functionality only.

What are the functional differences and support limitations?

Thanks
Kaamel
-- 
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-replica-install fails with python import error for module ssl_match_hostname

[White Hat]

When attempting to run ipa-replica-install I get a python error, No
module named ssl_match_hostname


This is on a CentOS 7.2 x86_64 testing box.

All available updates including kernel installed, and system rebooted
same day. Same error before and after patching and reboot.

Let me know if you want to see the yum history log info.

- Operating system version
[root@lcars site-packages]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

[root@lcars site-packages]# uname -a
Linux lcars.internal.madisonrentals.biz 3.10.0-327.28.2.el7.x86_64 #1
SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

- Here are the installed packages.  All were installed using yum.
[root@lcars site-packages]# yum list installed | awk '/backports|ipa-/'
ipa-admintools.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-client.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-python.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-server.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
ipa-server-dns.x86_64  4.2.0-15.0.1.el7.centos.18  @updates
python-backports.noarch1.0-6.el7   @anaconda
python-backports.x86_641.0-8.el7   installed
python-backports-ssl_match_hostname.noarch

I have the following repositories enabled:
base/7/x86_64
epel/x86_64
extras/7/x86_64
updates/7/x86_64

- Other threads on this issue suggest using pip to install
backports.ssl_match_hostname.  I still get the same error after doing
that.

[root@lcars site-packages]# pip install backports.ssl_match_hostname
Requirement already satisfied (use --upgrade to upgrade):
backports.ssl_match_hostname in /usr/lib/python2.7/site-packages

[root@lcars site-packages]# pip install --upgrade backports.ssl_match_hostname
Requirement already up-to-date: backports.ssl_match_hostname in
/usr/lib/python2.7/site-packages

- Here's the actual attempt
[root@lcars site-packages]# ipa-replica-install --setup-ca --setup-dns
--forwarder=4.2.2.1
/root/replica-info-lcars.internal.madisonrentals.biz.gpg
WARNING: conflicting time synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORNo module
named ssl_match_hostname

Even when running the suggested ipa-server-install --uninstall, I
still receive the error about the missing module.

Here's what I have in /usr/lib/python2.7/site-packages

[root@lcars site-packages]# pwd
/usr/lib/python2.7/site-packages
[root@lcars site-packages]# ls | awk '/backports.ssl/'
backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info
backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info

- And here are the contents of each directory.
[root@lcars site-packages]# cd
backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info/

[root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# ls
dependency_links.txt  PKG-INFO  SOURCES.txt  top_level.txt

[root@lcars backports.ssl_match_hostname-3.4.0.2-py2.7.egg-info]# cd ..
[root@lcars site-packages]# ls
backports.ssl_match_hostname-3.5.0.1-py2.7.egg-info
dependency_links.txt  installed-files.txt  PKG-INFO  SOURCES.txt  top_level.txt

Another thread suggested that this can be caused by a missing
__init__.py file, however, creating this file in both directories
doesn't help.

A commit by Heimes may shed some light on this.
The commit is in regards to otptoken and states that:

"The otptoken plugin is the only module in FreeIPA that uses Python's ssl
module instead of NSS. The patch replaces ssl with NSSConnection. It
uses the default NSS database to lookup trust anchors. NSSConnection
uses NSS for hostname matching. The package
python-backports-ssl_match_hostname is no longer required."

The master IPA server is up and running with no issues.

An ipa connection between replica server and master reports that the
connection is working.

What else could I be missing?

Thanks,
Chris.

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

Re: [Freeipa-users] ipa-client login as AD user in trusted domain

[Guy Knights]

Hmm, ok. In that case, I guess I need to rethink my setup. Thanks again for
all your help!

Kind regards,
Guy

On 10 August 2016 at 14:46, Justin Stephenson  wrote:

> On 08/10/2016 05:19 PM, Guy Knights wrote:
>
> Ok, I increased the debug level as you recommended and it's given me a lot
> of useful info. Before I go any further trying to troubleshoot that mass of
> info on this mailing list though, I would like to double check something I
> came across. In the debug output I noticed this line:
>
> "No ccache file for user [b...@ad.bbg.net] found."
>
> I would not dwell much on this error message, I see the same error from
> the krb5_auth_prepare_ccache_name function when I successfully logged in as
> an AD user on my IPA client(I suspect the ccache gets created shortly
> after). Higher debug logs means there will be a lot of log messages that
> look like errors but may not be.
>
> I then searched this error and found this thread in which the OP seems to
> have basically the same setup as me:
>
> https://lists.fedorahosted.org/pipermail/sssd-users/2013-
> January/000379.html
>
> I started playing with kinit on the ubuntu machine that I'm trying to log
> into, and got this error:
>
> "kinit: Cannot find KDC for realm "AD.BBG.NET" while getting initial
> credentials"
>
> After reading through some of the replies on the above thread, I saw a
> post that basically says that while the initial user info lookup is via
> FreeIPA, to actually authenticate a user the ipa client machine must
> connect directly to the AD controller. If this is true, it basically means
> the setup I was planning to use (FreeIPA in the cloud replicating/proxying
> local AD user accounts) is not going to work as I'd hoped. Could you
> confirm if this behaviour is in fact correct?
>
> Yes, the IPA client at some points needs to communicate directly with AD
> for kerberos communication - you should see this in
> /var/log/sssd/krb5_child.log
>
> This is explained better than I could here:
>
> The anatomy of a trusted identity lookup
>
> https://jhrozek.wordpress.com/2015/08/19/performance-tuning-
> sssd-for-large-ipa-ad-trust-deployments/
>
>
> Kind regards,
> Justin Stephenson
>
> Thanks,
> Guy
>
> On 9 August 2016 at 18:47, Justin Stephenson  wrote:
>
>> Hello,
>>
>> You may need to increase the debug level to 9 and look in the
>> sssd_.log for failures after the failed login attempt - i would
>> look in between log messages 'Got request for bobt...' and 'Backend
>> returned' messages
>>
>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>
>> You can also send the debug logs here for review.
>>
>> Make sure logins and lookups are working on the IPA server first before
>> troubleshooting the IPA client.
>>
>> Kind regards,
>>
>> Justin Stephenson
>> On 08/09/2016 07:32 PM, Guy Knights wrote:
>>
>> I've set up a freeipa server on a centos 7 machine and have successfully
>> configured a 2-way trust between it and our active directory domain
>> controller. I've also installed ipa-client on an ubuntu 14.04 machine and
>> have run ipa-client-install, which has apparently successfully joined the
>> FreeIPA domain.
>>
>> So far, I can successfully do the following:
>>
>> 1. Log into the FreeIPA machine with an AD user account.
>> 2. Log into the Ubuntu machine with a FreeIPA account.
>> 3. Run 'getent passwd ' on the Ubuntu machine and have
>> it return the associated FreeIPA user account details (eg.
>> "jackt:*:113105:113105:Jack Test:/home/ipa.bbg.net/jackt:/
>> bin/bash")
>> 4. Run 'getent passwd ' on the Ubuntu machine and have it
>> return the associated AD user account details (eg. "
>> b...@ad.bbg.net:*:1946801107:1946801107::/home/ad.bbg.net/bobt:/bin/bash
>> ")
>>
>> What I can't do is log into the Ubuntu machine with the AD user. I'm
>> using the following SSH command from the command line on my mac:
>>
>> ssh -o User=b...@ad.bbg.net vm1.bbg.com
>>
>> It asks me for the password, I enter it and it says permissions denied,
>> please try again. I set the debug level in SSSD on the ubuntu client to 5
>> and this is what shows up in the log during the login attempt:
>>
>> (Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net]]] [be_get_account_info]
>> (0x0100): Got request for [4097][1][name=bobt]
>> (Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
>> (0x0100): Request processed. Returned 3,95,Account info lookup failed
>> (Tue Aug  9 16:25:57 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
>> (0x0100): Request processed. Returned 0,0,Success
>> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [be_get_account_info]
>> (0x0100): Got request for [3][1][name=bobt]
>> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
>> (0x0100): Request processed. Returned 3,95,Account info lookup failed
>> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [be_pam_handler]
>> (0x0100): Got request with the following data
>> (Tue Aug  9 16:27:54 2016) 

Re: [Freeipa-users] ipa-client login as AD user in trusted domain

[Justin Stephenson]

On 08/10/2016 05:19 PM, Guy Knights wrote:
Ok, I increased the debug level as you recommended and it's given me a 
lot of useful info. Before I go any further trying to troubleshoot 
that mass of info on this mailing list though, I would like to double 
check something I came across. In the debug output I noticed this line:


"No ccache file for user [b...@ad.bbg.net ] 
found."


I would not dwell much on this error message, I see the same error from 
the krb5_auth_prepare_ccache_name function when I successfully logged in 
as an AD user on my IPA client(I suspect the ccache gets created shortly 
after). Higher debug logs means there will be a lot of log messages that 
look like errors but may not be.


I then searched this error and found this thread in which the OP seems 
to have basically the same setup as me:


https://lists.fedorahosted.org/pipermail/sssd-users/2013-January/000379.html

I started playing with kinit on the ubuntu machine that I'm trying to 
log into, and got this error:


"kinit: Cannot find KDC for realm "AD.BBG.NET " 
while getting initial credentials"


After reading through some of the replies on the above thread, I saw a 
post that basically says that while the initial user info lookup is 
via FreeIPA, to actually authenticate a user the ipa client machine 
must connect directly to the AD controller. If this is true, it 
basically means the setup I was planning to use (FreeIPA in the cloud 
replicating/proxying local AD user accounts) is not going to work as 
I'd hoped. Could you confirm if this behaviour is in fact correct?


Yes, the IPA client at some points needs to communicate directly with AD 
for kerberos communication - you should see this in 
/var/log/sssd/krb5_child.log


This is explained better than I could here:


   The anatomy of a trusted identity lookup

   
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/


Kind regards,
Justin Stephenson

Thanks,
Guy

On 9 August 2016 at 18:47, Justin Stephenson > wrote:


Hello,

You may need to increase the debug level to 9 and look in the
sssd_.log for failures after the failed login attempt -
i would look in between log messages 'Got request for bobt...' and
'Backend returned' messages

https://fedorahosted.org/sssd/wiki/Troubleshooting


You can also send the debug logs here for review.

Make sure logins and lookups are working on the IPA server first
before troubleshooting the IPA client.

Kind regards,

Justin Stephenson

On 08/09/2016 07:32 PM, Guy Knights wrote:

I've set up a freeipa server on a centos 7 machine and have
successfully configured a 2-way trust between it and our active
directory domain controller. I've also installed ipa-client on an
ubuntu 14.04 machine and have run ipa-client-install, which has
apparently successfully joined the FreeIPA domain.

So far, I can successfully do the following:

1. Log into the FreeIPA machine with an AD user account.
2. Log into the Ubuntu machine with a FreeIPA account.
3. Run 'getent passwd ' on the Ubuntu machine
and have it return the associated FreeIPA user account details
(eg. "jackt:*:113105:113105:Jack
Test:/home/ipa.bbg.net/jackt:/bin/bash
")
4. Run 'getent passwd ' on the Ubuntu machine and
have it return the associated AD user account details (eg.
"b...@ad.bbg.net:*:1946801107:1946801107::/home/

ad.bbg.net/bobt:/bin/bash
")

What I can't do is log into the Ubuntu machine with the AD user.
I'm using the following SSH command from the command line on my mac:

ssh -o User=b...@ad.bbg.net  vm1.bbg.com


It asks me for the password, I enter it and it says permissions
denied, please try again. I set the debug level in SSSD on the
ubuntu client to 5 and this is what shows up in the log during
the login attempt:

(Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net
]]] [be_get_account_info] (0x0100): Got
request for [4097][1][name=bobt]
(Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net
]]] [acctinfo_callback] (0x0100): Request
processed. Returned 3,95,Account info lookup failed
(Tue Aug  9 16:25:57 2016) [sssd[be[ipa.bbg.net
]]] [acctinfo_callback] (0x0100): Request
processed. Returned 0,0,Success
(Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net
]]] [be_get_account_info] (0x0100): Got
request for [3][1][name=bobt]
(Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net
]]] [acctinfo_callback] (0x0100): 

Re: [Freeipa-users] ipa-client login as AD user in trusted domain

[Guy Knights]

Ok, I increased the debug level as you recommended and it's given me a lot
of useful info. Before I go any further trying to troubleshoot that mass of
info on this mailing list though, I would like to double check something I
came across. In the debug output I noticed this line:

"No ccache file for user [b...@ad.bbg.net] found."

I then searched this error and found this thread in which the OP seems to
have basically the same setup as me:

https://lists.fedorahosted.org/pipermail/sssd-users/2013-January/000379.html

I started playing with kinit on the ubuntu machine that I'm trying to log
into, and got this error:

"kinit: Cannot find KDC for realm "AD.BBG.NET" while getting initial
credentials"

After reading through some of the replies on the above thread, I saw a post
that basically says that while the initial user info lookup is via FreeIPA,
to actually authenticate a user the ipa client machine must connect
directly to the AD controller. If this is true, it basically means the
setup I was planning to use (FreeIPA in the cloud replicating/proxying
local AD user accounts) is not going to work as I'd hoped. Could you
confirm if this behaviour is in fact correct?
Thanks,
Guy

On 9 August 2016 at 18:47, Justin Stephenson  wrote:

> Hello,
>
> You may need to increase the debug level to 9 and look in the
> sssd_.log for failures after the failed login attempt - i would
> look in between log messages 'Got request for bobt...' and 'Backend
> returned' messages
>
> https://fedorahosted.org/sssd/wiki/Troubleshooting
>
> You can also send the debug logs here for review.
>
> Make sure logins and lookups are working on the IPA server first before
> troubleshooting the IPA client.
>
> Kind regards,
>
> Justin Stephenson
> On 08/09/2016 07:32 PM, Guy Knights wrote:
>
> I've set up a freeipa server on a centos 7 machine and have successfully
> configured a 2-way trust between it and our active directory domain
> controller. I've also installed ipa-client on an ubuntu 14.04 machine and
> have run ipa-client-install, which has apparently successfully joined the
> FreeIPA domain.
>
> So far, I can successfully do the following:
>
> 1. Log into the FreeIPA machine with an AD user account.
> 2. Log into the Ubuntu machine with a FreeIPA account.
> 3. Run 'getent passwd ' on the Ubuntu machine and have
> it return the associated FreeIPA user account details (eg.
> "jackt:*:113105:113105:Jack Test:/home/ipa.bbg.net/jackt:/bin/bash
> ")
> 4. Run 'getent passwd ' on the Ubuntu machine and have it
> return the associated AD user account details (eg. "
> b...@ad.bbg.net:*:1946801107:1946801107::/home/ad.bbg.net/bobt:/bin/bash")
>
> What I can't do is log into the Ubuntu machine with the AD user. I'm using
> the following SSH command from the command line on my mac:
>
> ssh -o User=b...@ad.bbg.net vm1.bbg.com
>
> It asks me for the password, I enter it and it says permissions denied,
> please try again. I set the debug level in SSSD on the ubuntu client to 5
> and this is what shows up in the log during the login attempt:
>
> (Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net]]] [be_get_account_info]
> (0x0100): Got request for [4097][1][name=bobt]
> (Tue Aug  9 16:25:56 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 3,95,Account info lookup failed
> (Tue Aug  9 16:25:57 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [be_get_account_info]
> (0x0100): Got request for [3][1][name=bobt]
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 3,95,Account info lookup failed
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [be_pam_handler]
> (0x0100): Got request with the following data
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): command: PAM_AUTHENTICATE
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): domain: ad.bbg.net
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): user: b...@ad.bbg.net
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): service: sshd
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): tty: ssh
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): ruser:
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): rhost: 192.168.100.157
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): authtok type: 1
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): newauthtok type: 0
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): priv: 1
> (Tue Aug  9 16:27:54 2016) [sssd[be[ipa.bbg.net]]] [pam_print_data]
> (0x0100): cli_pid: 16230
> (Tue Aug  9 16:27:54 2016) 

Re: [Freeipa-users] Declarative configuration options?

[Mike LoSapio]

Something declarative which can be version controlled and considered a
"source of truth" and driven from configuration management (chef,
puppet, ansible - whatever your flavor)

A scheme to reconcile account properties, group memberships,
permissions, etc... I could see how this would be a slippery slope
because of the depth of groupings/permissions/etc... but a
version-controlled declarative user config gives a nice record for
auditors (When did mike get an account, who granted access to him,
when did he get access, what other access has he had over the last
year... etc..)

~~ Pseudo declaraion
ipa_user: mike
  uid: mlosapio
  first_name: mike
  last_name: losapio





On Wed, Aug 3, 2016 at 1:56 PM, Martin Basti  wrote:
>
>
> On 01.08.2016 22:50, Mike LoSapio wrote:
>>
>> Hi there,
>>
>> Is there anyone out there with a good system for storing users,
>> groups, hosts, etc.. in some sort of version controlled repo w/ flat
>> files that could plug into "two-man" workflows for user-account
>> creation and privilege/group membership changes, etc.
>>
>> There's some github projects out there to help installing FreeIPA
>> server and a few to get clients up and running, but nothing (that I
>> could find) for the on-going management of FreeIPA resources.
>>
>>
>>
>> So in puppet world (just as an example) - I'd be looking for something
>> like a puppet-defined-type freeipa_user with all the attributes
>> required and more-importantly all the code-glue that puts it all
>> together...
>>
>>
>> Figured I'd ask if there if there's anything already out there before
>> I re-invent the wheel.
>>
>>
>> TIA,
>> --Mike
>>
> Hello,
>
> sorry but I don't understand what you exactly need, can you be more
> specific? Do you need a script that provision users?
>
> Martin
>
>

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

Re: [Freeipa-users] sudo rules question on ubuntu 16.0.1

[Rob Crittenden]

Jeff Goddard wrote:

Sean,

Thanks for the reply. I don't think that's my problem but I'm posting a
redacted copy of the sssd.conf file for review below.


I'd start here: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

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] sudo rules question on ubuntu 16.0.1

[Jeff Goddard]

Sean,

Thanks for the reply. I don't think that's my problem but I'm posting a
redacted copy of the sssd.conf file for review below.


[domain/domain.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = docker-dev-01.domain.com
chpass_provider = ipa
ipa_server = _srv_, server.domain.com
ldap_tls_cacert = /etc/ipa/ca.crt
debug_level=7
[sssd]
services = nss, sudo, pam, ssh
debug_level=7
domains = domain.com
[nss]
homedir_substring = /home

[pam]

[sudo]
debug_level=7
[autofs]

[ssh]

[pac]

[ifp]

Jeff

On Wed, Aug 10, 2016 at 2:04 PM, Sean Hogan  wrote:

> Not sure it is the same as 14.X but I had to add the sudo in the list of
> services to sssd.conf as it was not put in by default. I am by no means an
> expert on it but my own personal experience with 14.x
>
>
>
> Sean Hogan
>
>
>
>
>
> [image: Inactive hide details for Jeff Goddard ---08/10/2016 10:52:31
> AM---I've got a freeipa domain and many centos 7.2 clients. I als]Jeff
> Goddard ---08/10/2016 10:52:31 AM---I've got a freeipa domain and many
> centos 7.2 clients. I also have a sudo rule that allows member of
>
> From: Jeff Goddard 
> To: freeipa-users@redhat.com
> Date: 08/10/2016 10:52 AM
> Subject: [Freeipa-users] sudo rules question on ubuntu 16.0.1
> Sent by: freeipa-users-boun...@redhat.com
> --
>
>
>
> I've got a freeipa domain and many centos 7.2 clients. I also have a sudo
> rule that allows member of the developer group sudo rights on virtual
> servers in the "development" group. This works great on the centos servers.
> However, I recently set up 3 ubuntu boxes, and added them to the IPA domain
> and then to the "development" group. My sudo rules fail. I've enabled
> debugging and I see in the /var/log/sssd/sssd_sudo.log that the clients
> connects to the server, identifies group memberships, and finally prints
> "returning 1 rules for [*u...@domain.com* ]. We only
> have the single rule so I can't figure out why it's not working. Can
> someone point me in the correct direction?
>
> Thanks,
>
> Jeff
>
> --
> 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] sudo rules question on ubuntu 16.0.1

[Sean Hogan]

   Not sure it is the same as 14.X but I had to add the sudo in the list of
services to sssd.conf as it was not put in by default.  I am by no means an
expert on it but my own personal experience with 14.x



Sean Hogan







From:   Jeff Goddard 
To: freeipa-users@redhat.com
Date:   08/10/2016 10:52 AM
Subject:[Freeipa-users] sudo rules question on ubuntu 16.0.1
Sent by:freeipa-users-boun...@redhat.com



I've got a freeipa domain and many centos 7.2 clients. I also have a sudo
rule that allows member of the developer group sudo rights on virtual
servers in the "development" group. This works great on the centos servers.
However, I recently set up 3 ubuntu boxes, and added them to the IPA domain
and then to the "development" group. My sudo rules fail. I've enabled
debugging and I see in the /var/log/sssd/sssd_sudo.log that the clients
connects to the server, identifies group memberships, and finally prints
"returning 1 rules for [u...@domain.com]. We only have the single rule so I
can't figure out why it's not working. Can someone point me in the correct
direction?

Thanks,

Jeff

--
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] sudo rules question on ubuntu 16.0.1

[Jeff Goddard]

I've got a freeipa domain and many centos 7.2 clients. I also have a sudo
rule that allows member of the developer group sudo rights on virtual
servers in the "development" group. This works great on the centos servers.
However, I recently set up 3 ubuntu boxes, and added them to the IPA domain
and then to the "development" group. My sudo rules fail. I've enabled
debugging and I see in the /var/log/sssd/sssd_sudo.log that the clients
connects to the server, identifies group memberships, and finally prints
"returning 1 rules for [u...@domain.com]. We only have the single rule so I
can't figure out why it's not working. Can someone point me in the correct
direction?

Thanks,

Jeff
-- 
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] Why is user status different on each master replica?

[Martin Basti]

On 09.08.2016 23:04, Larry Rosen wrote:


This user was locked out due to Max Failure policy = 5

If they’re supposed to be replicas, why the different status?

[root@il10 ~]# ipa user-status  lramey

---

Account disabled: False

---

  Server: ipa-idm-01.ipajdr.local

  Failed logins: 0

  Last successful authentication: 20160808191857Z

  Last failed authentication: 20160808191848Z

  Time now: 2016-08-09T19:57:20Z

  Server: ipa-idm-02.ipajdr.local

  Failed logins: 5

  Last successful authentication: 20160809151406Z

  Last failed authentication: 20160809194741Z

  Time now: 2016-08-09T19:57:21Z



Number of entries returned 2




Hi,

This is not replicated, because it may cause replication storms. So this 
status is local on each replica


Martin^2
-- 
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] Why is user status different on each master replica?

[Larry Rosen]

This user was locked out due to Max Failure policy = 5
If they're supposed to be replicas, why the different status?

[root@il10 ~]# ipa user-status  lramey
---
Account disabled: False
---
  Server: ipa-idm-01.ipajdr.local
  Failed logins: 0
  Last successful authentication: 20160808191857Z
  Last failed authentication: 20160808191848Z
  Time now: 2016-08-09T19:57:20Z

  Server: ipa-idm-02.ipajdr.local
  Failed logins: 5
  Last successful authentication: 20160809151406Z
  Last failed authentication: 20160809194741Z
  Time now: 2016-08-09T19:57:21Z

Number of entries returned 2

-- 
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 Session Management (WebUI, Kerberos, ...?)

[Joe Thielen]

> Date: Wed, 10 Aug 2016 09:02:29 +0200
> From: Petr Spacek 
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] FreeIPA Session Management (WebUI,
> Kerberos, ...?)
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252
>
> On 9.8.2016 21:37, Joe Thielen wrote:
> > First off, let me say THANK YOU to all of you who've helped make FreeIPA
> > what it is.  I think it's a fantastic project and it's amazing what it
> has
> > achieved.
> >
> > Second off, I'm still quite new to FreeIPA, especially the internals.
> This
> > includes Kerberos.  I'm also very very limited at Python (I come from a
> PHP
> > background - please don't hold it against me).  I have toyed around with
> > LDAP a little bit before looking at FreeIPA.
> >
> > After re-reading this e-mail I think it'd be important to note here at
> the
> > top that my focus is on web-based apps and non-kerberized clients.  The
> web
> > app server would be an IPA client.  I don't foresee a lot of
> terminal-based
> > stuff going on, aside from potential admin CLI tasks (for the web-based
> > app).
> >
> > I apologize in advance for the length of this e-mail.  I have searched, a
> > lot, to try and answer my own questions.  That's actually how I found
> > FreeIPA in the first place.  I've looked at the site/wiki, the mailing
> list
> > archive, and the Internet in general.  But I've been unable to find a
> > solution, or suggestions, which achieves exactly what I'm looking for.
> It
> > may be that I'm just using the wrong terminology and/or getting lost in
> the
> > buzzwords.
> >
> > What I'm trying to figure out is if there is a way to centrally manage
> > sessions, in addition to everything else FreeIPA currently does.  I'm not
> > necessarily just talking about WebUI sessions, I'd like external web apps
> > to be able to make use of it too.  And, I'd like to be able to manage
> them
> > via the WebUI.
> >
> > For example, let's say "joe" logs in to the WebUI (OR another web app
> tied
> > to FreeIPA).  Now, on another computer, "admin" logs into the WebUI.  Can
> > admin have a way to see that "joe" logged in, and, if need be, kill Joe's
> > session?
> >
> > I'd like for it to maintain history.  For each login/session, I'd like to
> > see who logged in, when, from where, what their last access was, when
> they
> > logged out (or if their session timed out), and the logout reason (manual
> > logout, session timeout, or admin intervention).
> >
> > But like I said, I'm not just looking for WebUI sessions.
> >
> > Let's say I create a web app.  I put it on a machine which is an IPA
> > client.  Thanks to the wealth of documentation and options, I have a
> > variety of methods to achieve authentication.  FreeIPA makes this great,
> > and for that I'm thankful.  However, in most of the documentation, it
> just
> > says "create the session" cookie, and the rest is left as an exercise to
> > the reader.  I'm familiar with web apps and have implemented session
> > management before.  What I'd love to see is FreeIPA to be able to handle
> > not just the auth but also the session management.
> >
> > Why?  Because I'd not like to have to re-invent the wheel.  And I'm
> trying
> > to see if there is already some method to do this that I'm just
> > fundamentally missing.  Or at least if there are enough pieces that I
> could
> > put together to make it happen.
> >
> > For "fun", I've tried to set up auth using different methods.  I've
> > successfully set it up using intercept_form_submit_module and
> > lookup_identity_module.  That's pretty neat, works great for auth.  But,
> as
> > far as I can tell, this method doesn't create a session or login trail in
> > the memcached DB.  In fact, I can't really find any trail aside from the
> > Kerberos logging messages in /var/log/krbkdc.log.
> >
> > I've also used Tobias Sette's php-freeipa from GitHub.  That works great
> > too... for auth.  And since that uses the JSON API, it looks like it does
> > create a record in the memcached DB.  So I suppose this could be one way
> > in, maybe by a FreeIPA plugin?
> >
> > I guess I'm running in circles because then again I think... "what about
> > pure Kerberos" clients...  or those using intercept_form_submit_module?
> > I'm not familiar with PAM.  But from what I can tell, I assume there is a
> > way to add a "pluggable" module for it too.  But on the server?  i.e.,
> if a
> > Kerberos session is established, is there a way, via PAM (or something
> > else?) to log that session to the FreeIPA server?   I think this is kinda
> > what Kerberos is trying to get away from, but for the use cases I'm
> > thinking of, it'd be a big feature.  In my searching I've seen things
> like
> > nss_mysql which look interesting, but of course wouldn't mesh with the
> > FreeIPA WebUI memcached method.
> >
> > Speaking of which, I know that memcached is not by any means a permanent
> > session log, and 

Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)

[Joe Thielen]

On Wed, Aug 10, 2016 at 5:27 AM, Jan Pazdziora 
wrote:

> On Tue, Aug 09, 2016 at 03:37:35PM -0400, Joe Thielen wrote:
> >
> > For example, let's say "joe" logs in to the WebUI (OR another web app
> tied
> > to FreeIPA).  Now, on another computer, "admin" logs into the WebUI.  Can
> > admin have a way to see that "joe" logged in, and, if need be, kill Joe's
> > session?
>
> Typical Web applications handle sessions via HTTP cookies. You might
> have additional cookies added by other layers, like mod_auth_mellon
> for SAML, but one your typical PHP application sees the user
> (externally) authenticated, it will create its own session as well,
> signed, and that's what it will use. The only party which has access
> to that session is user's browser, plus of course it is recorded in
> the application database.
>
> You will likely not find a generic mechanism which would allow you to
> log out random application-level session (cookie-based) because after
> all, it is not FreeIPA that created the session -- it's the
> application. And even if FreeIPA was creating the sessions,
> applications would be creating their own and those would still stay
> around and be valid.
>
> Your best bet might be to make the application-level session lifetime
> reasonably short, to force reauthentication at regular intervals. If
> some form of single sign-on authentication happens where the user is
> not asked for their creentials again, you will get check with the
> central authority (which can then block authentication attempt for
> user that was made disabled) without user's workflow being disrupted
> too much.
>
> By the way -- you say "Joe's session". I assume you will only do that
> when at the same time Joe should not be able to reauthenticate again
> to that service, right?
>
> > I guess I'm running in circles because then again I think... "what about
> > pure Kerberos" clients...
>
> Pure Kerberos clients are another fun -- the whole Kerberos
> authentication is built around the time-based service tickets. If the
> client already has a service ticket for the service, it does not need
> to consult KDC, and neither is the central authority consulted by the
> Web applications -- they trust the service tickets that they are able
> to decrypt.
>
> > or those using intercept_form_submit_module?
> > I'm not familiar with PAM.
>
> Well, PAM access phase might actually be a good way to be able to
> "plug in" authorization check to Web accesses. That way even if
> authentication (proof of identity) is done via method that does not
> contact central server (Kerberos), the authorization can happen
> against central authority. You can check
>
> https://www.adelton.com/apache/mod_authnz_pam/
>
> for example of adding PAM-based authorization to GSS-API
> authentication. And mod_intercept_form_submit does the same, for
> username+password authentication.
>
> But as noted above, this will just affect the Apache-based
> authentication / authorization and will prevent the application session
> from being created. It will not play any role in application-level
> session where the cookie is hold by the browser and evaluated by the
> application directly.
>
> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red
> Hat
>

Jan, thanks for the insights.  I realize that once the auth takes place and
the cookie is set that an external entity (a centralized session manager)
can't do much about the cookie.  My expectation is the web app
(server-side, not client-side) will have to "phone home" to the centralized
session manager on each request to ensure the session is still valid.  If
the web app gets a signal that the session is no longer valid, and it must
not be renewed, then it would end it's own session and no longer allow the
user to continue.  And yes, you are correct in regards to "Joe's session",
he would not be allowed to re-authenticate.

This will certainly increase overhead, but I'm looking at it from a
security perspective more than anything else.

Having a short session span makes sense, forcing frequent automatic
re-authentication.  This would help in situations when using a 3rd party
web app which doesn't meet the expectation that it'd be phoning home on
each request.

Now that I'm thinking about this more, I wonder if it'd be easier to turn
this around the other way.  Instead of the web app phoning home on each
request to check and see if the session is still valid (lot's of overhead
to check for something that may very rarely happen), and maybe have a way
for the centralized session manager to instead talk to the web app server
and initiate the killing of the session that way.  So this could actually
be made as a custom plugin for 3rd party apps too... a way to remotely kill
sessions.   An example of this would be a FreeIPA WebUI session.  If the
memcached record for the session were deleted by a 3rd party, that would
cause their session to end, right?  A little 

Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)

[Jan Pazdziora]

On Tue, Aug 09, 2016 at 03:37:35PM -0400, Joe Thielen wrote:
> 
> For example, let's say "joe" logs in to the WebUI (OR another web app tied
> to FreeIPA).  Now, on another computer, "admin" logs into the WebUI.  Can
> admin have a way to see that "joe" logged in, and, if need be, kill Joe's
> session?

Typical Web applications handle sessions via HTTP cookies. You might
have additional cookies added by other layers, like mod_auth_mellon
for SAML, but one your typical PHP application sees the user
(externally) authenticated, it will create its own session as well,
signed, and that's what it will use. The only party which has access
to that session is user's browser, plus of course it is recorded in
the application database.

You will likely not find a generic mechanism which would allow you to
log out random application-level session (cookie-based) because after
all, it is not FreeIPA that created the session -- it's the
application. And even if FreeIPA was creating the sessions,
applications would be creating their own and those would still stay
around and be valid.

Your best bet might be to make the application-level session lifetime
reasonably short, to force reauthentication at regular intervals. If
some form of single sign-on authentication happens where the user is
not asked for their creentials again, you will get check with the
central authority (which can then block authentication attempt for
user that was made disabled) without user's workflow being disrupted
too much.

By the way -- you say "Joe's session". I assume you will only do that
when at the same time Joe should not be able to reauthenticate again
to that service, right?

> I guess I'm running in circles because then again I think... "what about
> pure Kerberos" clients...

Pure Kerberos clients are another fun -- the whole Kerberos
authentication is built around the time-based service tickets. If the
client already has a service ticket for the service, it does not need
to consult KDC, and neither is the central authority consulted by the
Web applications -- they trust the service tickets that they are able
to decrypt.

> or those using intercept_form_submit_module?
> I'm not familiar with PAM.

Well, PAM access phase might actually be a good way to be able to
"plug in" authorization check to Web accesses. That way even if
authentication (proof of identity) is done via method that does not
contact central server (Kerberos), the authorization can happen
against central authority. You can check

https://www.adelton.com/apache/mod_authnz_pam/

for example of adding PAM-based authorization to GSS-API
authentication. And mod_intercept_form_submit does the same, for
username+password authentication.

But as noted above, this will just affect the Apache-based
authentication / authorization and will prevent the application session
from being created. It will not play any role in application-level
session where the cookie is hold by the browser and evaluated by the
application directly.

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

Re: [Freeipa-users] updating certificates

[Florence Blanc-Renaud]

Hi Josh,

depending on your IPA version, you may consider using 
ipa-server-certinstall and ipa-certupdate.


ipa-server-certinstall can be used to install a new certificate for 
Apache/LDAP servers, and ipa-certupdate to update the NSS DBs with the 
CA certificates found in the LDAP server.


Flo.

On 08/09/2016 05:48 PM, Josh wrote:

Rob,

One must also update /etc/ipa/nssdb the same way, otherwise ipa cli tool
gets SEC_ERROR_UNTRUSTED_ISSUER !

It would be nice to have an IPA tool  to update all certificates in all
required places.

Also, why would I need to add CA that already in system ca-trust to the
private IPA nssdb?

Josh.


On 06/28/2016 10:50 AM, Rob Crittenden wrote:

j...@use.startmail.com wrote:

Greetings,

About a year ago I installed my freeipa server with certificates from
startssl using command line options --dirsrv-cert-file --http-cert-file
etc.
The certificate is about to expire, what is the proper way to update it
in all places?


It depends on whether you kept the original CSR or not. If you kept
the original CSR and are just renewing the certificate(s) then when
you get the new one, use certutil to add the updated cert to the
appropriate NSS database like:

# certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i
/path/to/new.crt

If you need to generate a new CSR then you can use
ipa-server-certinstall to install the updated key and crt files.

In either case probably worth backing up /etc/httpd/alias/*.db and
/etc/dirsrv/slapd-INSTANCE/*.db.

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] FreeIPA Session Management (WebUI, Kerberos, ...?)

[Petr Spacek]

On 9.8.2016 21:37, Joe Thielen wrote:
> First off, let me say THANK YOU to all of you who've helped make FreeIPA
> what it is.  I think it's a fantastic project and it's amazing what it has
> achieved.
> 
> Second off, I'm still quite new to FreeIPA, especially the internals.  This
> includes Kerberos.  I'm also very very limited at Python (I come from a PHP
> background - please don't hold it against me).  I have toyed around with
> LDAP a little bit before looking at FreeIPA.
> 
> After re-reading this e-mail I think it'd be important to note here at the
> top that my focus is on web-based apps and non-kerberized clients.  The web
> app server would be an IPA client.  I don't foresee a lot of terminal-based
> stuff going on, aside from potential admin CLI tasks (for the web-based
> app).
> 
> I apologize in advance for the length of this e-mail.  I have searched, a
> lot, to try and answer my own questions.  That's actually how I found
> FreeIPA in the first place.  I've looked at the site/wiki, the mailing list
> archive, and the Internet in general.  But I've been unable to find a
> solution, or suggestions, which achieves exactly what I'm looking for.  It
> may be that I'm just using the wrong terminology and/or getting lost in the
> buzzwords.
> 
> What I'm trying to figure out is if there is a way to centrally manage
> sessions, in addition to everything else FreeIPA currently does.  I'm not
> necessarily just talking about WebUI sessions, I'd like external web apps
> to be able to make use of it too.  And, I'd like to be able to manage them
> via the WebUI.
> 
> For example, let's say "joe" logs in to the WebUI (OR another web app tied
> to FreeIPA).  Now, on another computer, "admin" logs into the WebUI.  Can
> admin have a way to see that "joe" logged in, and, if need be, kill Joe's
> session?
> 
> I'd like for it to maintain history.  For each login/session, I'd like to
> see who logged in, when, from where, what their last access was, when they
> logged out (or if their session timed out), and the logout reason (manual
> logout, session timeout, or admin intervention).
> 
> But like I said, I'm not just looking for WebUI sessions.
> 
> Let's say I create a web app.  I put it on a machine which is an IPA
> client.  Thanks to the wealth of documentation and options, I have a
> variety of methods to achieve authentication.  FreeIPA makes this great,
> and for that I'm thankful.  However, in most of the documentation, it just
> says "create the session" cookie, and the rest is left as an exercise to
> the reader.  I'm familiar with web apps and have implemented session
> management before.  What I'd love to see is FreeIPA to be able to handle
> not just the auth but also the session management.
> 
> Why?  Because I'd not like to have to re-invent the wheel.  And I'm trying
> to see if there is already some method to do this that I'm just
> fundamentally missing.  Or at least if there are enough pieces that I could
> put together to make it happen.
> 
> For "fun", I've tried to set up auth using different methods.  I've
> successfully set it up using intercept_form_submit_module and
> lookup_identity_module.  That's pretty neat, works great for auth.  But, as
> far as I can tell, this method doesn't create a session or login trail in
> the memcached DB.  In fact, I can't really find any trail aside from the
> Kerberos logging messages in /var/log/krbkdc.log.
> 
> I've also used Tobias Sette's php-freeipa from GitHub.  That works great
> too... for auth.  And since that uses the JSON API, it looks like it does
> create a record in the memcached DB.  So I suppose this could be one way
> in, maybe by a FreeIPA plugin?
> 
> I guess I'm running in circles because then again I think... "what about
> pure Kerberos" clients...  or those using intercept_form_submit_module?
> I'm not familiar with PAM.  But from what I can tell, I assume there is a
> way to add a "pluggable" module for it too.  But on the server?  i.e., if a
> Kerberos session is established, is there a way, via PAM (or something
> else?) to log that session to the FreeIPA server?   I think this is kinda
> what Kerberos is trying to get away from, but for the use cases I'm
> thinking of, it'd be a big feature.  In my searching I've seen things like
> nss_mysql which look interesting, but of course wouldn't mesh with the
> FreeIPA WebUI memcached method.
> 
> Speaking of which, I know that memcached is not by any means a permanent
> session log, and I understand it's not intended to be.  So would this go
> into the LDAP tree?  Would this clog it up too much?  I'm looking to store
> a year of  info... or more depending on the scenario.
> 
> I've briefly looked at the Apache Shiro project.  I'm not a Java guy, but
> from I'm reading it kind of has the right idea.  It even notes that the
> session management portions can be accessed from other apps (on other
> machines) and not necessarily from Java.  But due to the whole thing being
> a