[Freeipa-users] FreeIPA 4.1 -> 4.2 replica upgrade process

[Andreas Calminder]

Hello!
This might be trivial but I want to double check the preferred way of 
upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 
4.1), 1 acting as master with a ca (external certificate), the replicas 
are also ca's, they're only syncing to and from the master, unaware of 
each other. The replicas handle all client requests. The master also run 
a one-way winsync agreement with one of our active directory servers.


For some reason I think that I should start by upgrading the replicas 
and upgrade the master last, but I don't know why, I might have read it 
in somewhere, long ago. Is this the preferred way, does order even 
matter? The documentation just says /yum update ipa-server/ which seems 
easy enough, but I'd rather double check.


Best regards,
Andreas

--
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] CA installation failed on server

[Rob Crittenden]

Christian Heimes wrote:
> On 2015-11-30 16:27, Rob Crittenden wrote:
>> Christian Heimes wrote:
>>> On 2015-11-30 12:51, Martin Basti wrote:


 On 28.11.2015 00:14, Rob Crittenden wrote:
> Martin Štefany wrote:
>> Hello,
>>
>> I remember experiencing this, but I'm not sure of solution. I think it's
>> related to apache (httpd) and his group.
>>
>> My notes for IPA installation on CentOS 7.x say:
>>
>> # groupadd -g 48 apache
>> # yum -y install ipa-server bind bind-dyndb-ldap
>> # usermod -g apache apache
>> # ipa-server-install...
>>
>> CentOS is somehow not creating group apache for apache user and then
>> assuming root which is then causing problems with apache later. Pre-
>> creating such group before installing httpd and then usermod-ing user
>> apache might solve it.
>>
>> Did you get any warnings while running:
>> # yum install -y ipa-server bind bind-dyndb-ldap ?
>>
>>
>> If possible, try installation from scratch with my notes on fresh
>> system. If not:
>>
>> # systemctl stop apache   # if it runs
>> # groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
>> 48, or use 'groupadd -r apache' instead
>> # usermod -g apache apache
>> # ipa-server-install...
>>
> Sounds unlikely to me. If indeed it did happen you'd need to file a bug
> against Apache to create its own uid/gid, which I'm pretty certain it
> already does.
>
> In any case, dogtag doesn't run in Apache so it would be unlikely to
> blow up in the CA installer.
>
> cating the contents of a directory into one log is not at all helpful,
> especially given that you missed all the important bits in the
> subdirectories beneath it. This is just a mishmash of stuff. We need to
> see /var/log/pki/pki-tomcat/ca/debug.
>
> /var/log/ipaserver-install.log might also be useful to see though it
> probably just records in a more verbose way the fact that pkispawn
> failed.
>
> rob
>
 Hello,

 I see in log this error message:

 2015-11-26 08:41:53 pkidestroy  : ERROR...
 subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n',
 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d',
 '/etc/pki/pki-tomcat/alias', '-e',
 'name="/var/lib/pki/pki-tomcat"=CA=caList=ipa.home=443=8443=8443=8443=remove',
 '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned
 non-zero exit status 6!

 It means that the CA has no been sucessfully uninstalled, and it can
 cause issues during installation
 PKI bug:
 https://fedorahosted.org/pki/ticket/1704

 Christian may have workaround (CCed)
>>>
>>> Hi Martin and Martin,
>>>
>>> last week I have identified an incompatibility between Dogtag's sslget
>>> command and Apache HTTP. sslget sends a server name indication during
>>> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer
>>> versions of Apache HTTP don't accept requests with SNI and without HTTP
>>> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log.
>>>
>>> The simplest workaround is to bypass Apache and talk to Dogtag directly.
>>> In order to do bypass the Apache proxy you have to log onto the server.
>>> You also have to become root so you can access the NSS database that
>>> contains the private key for authentication. Simply copy and paste the
>>> sslget command from the log (everything between "Command '[" and "]'
>>> returend non-zero exit status 6!"), remove the comma, replace
>>> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command
>>> should look like:
>>>
>>> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ...
>>> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443'
>>
>> mod_nss added support for SNI in Fedora 23. It should behave the same
>> way as mod_ssl, denying a request that contains an SNI hostname but no
>> Host header.
>>
>> I assume you've filed a bug against dogtag to send a Host header in the
>> request?
>>
>> A better workaround would be to add NSSSNI off to
>> /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install
>> should work then, or at least get past this sslget error.
> 
> That might explain why the issue hasn't popped up earlier. sslget sets
> SNI header without HTTP Host header for a while. Since FreeIPA uses
> mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header
> before, sslget didn't fail in the past.
> 
> Yes, I have fixed sslget to send a HTTP Host header with hostname and port.
> 
> No, that won't work. You'd have to change the configuration before you
> run uninstall. Install still won't work because uninstall was
> incomplete. It's still necessary to remove the Service Domain for the CA
> from LDAP. The sslget command call removes it. It's also possible to
> remove it with ldapremove over ldapi. The entry is in the
> 

Re: [Freeipa-users] CA installation failed on server

[Martin Basti]

On 30.11.2015 17:45, Rob Crittenden wrote:

Christian Heimes wrote:

On 2015-11-30 16:27, Rob Crittenden wrote:

Christian Heimes wrote:

On 2015-11-30 12:51, Martin Basti wrote:


On 28.11.2015 00:14, Rob Crittenden wrote:

Martin Štefany wrote:

Hello,

I remember experiencing this, but I'm not sure of solution. I think it's
related to apache (httpd) and his group.

My notes for IPA installation on CentOS 7.x say:

# groupadd -g 48 apache
# yum -y install ipa-server bind bind-dyndb-ldap
# usermod -g apache apache
# ipa-server-install...

CentOS is somehow not creating group apache for apache user and then
assuming root which is then causing problems with apache later. Pre-
creating such group before installing httpd and then usermod-ing user
apache might solve it.

Did you get any warnings while running:
# yum install -y ipa-server bind bind-dyndb-ldap ?


If possible, try installation from scratch with my notes on fresh
system. If not:

# systemctl stop apache   # if it runs
# groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
48, or use 'groupadd -r apache' instead
# usermod -g apache apache
# ipa-server-install...


Sounds unlikely to me. If indeed it did happen you'd need to file a bug
against Apache to create its own uid/gid, which I'm pretty certain it
already does.

In any case, dogtag doesn't run in Apache so it would be unlikely to
blow up in the CA installer.

cating the contents of a directory into one log is not at all helpful,
especially given that you missed all the important bits in the
subdirectories beneath it. This is just a mishmash of stuff. We need to
see /var/log/pki/pki-tomcat/ca/debug.

/var/log/ipaserver-install.log might also be useful to see though it
probably just records in a more verbose way the fact that pkispawn
failed.

rob


Hello,

I see in log this error message:

2015-11-26 08:41:53 pkidestroy  : ERROR...
subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n',
'subsystemCert cert-pki-ca', '-p', '272326334956', '-d',
'/etc/pki/pki-tomcat/alias', '-e',
'name="/var/lib/pki/pki-tomcat"=CA=caList=ipa.home=443=8443=8443=8443=remove',
'-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned
non-zero exit status 6!

It means that the CA has no been sucessfully uninstalled, and it can
cause issues during installation
PKI bug:
https://fedorahosted.org/pki/ticket/1704

Christian may have workaround (CCed)

Hi Martin and Martin,

last week I have identified an incompatibility between Dogtag's sslget
command and Apache HTTP. sslget sends a server name indication during
the TLS/SSL handshake but doesn't send a HTTP Host header. Newer
versions of Apache HTTP don't accept requests with SNI and without HTTP
Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log.

The simplest workaround is to bypass Apache and talk to Dogtag directly.
In order to do bypass the Apache proxy you have to log onto the server.
You also have to become root so you can access the NSS database that
contains the private key for authentication. Simply copy and paste the
sslget command from the log (everything between "Command '[" and "]'
returend non-zero exit status 6!"), remove the comma, replace
'ipa.home:443' with 'ipa.home:8443' and run the command. The command
should look like:

'/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ...
'/ca/agent/ca/updateDomainXML' 'ipa.home:8443'

mod_nss added support for SNI in Fedora 23. It should behave the same
way as mod_ssl, denying a request that contains an SNI hostname but no
Host header.

I assume you've filed a bug against dogtag to send a Host header in the
request?

A better workaround would be to add NSSSNI off to
/etc/httpd/conf.d/nss.conf within the default VH. Retrying the install
should work then, or at least get past this sslget error.

That might explain why the issue hasn't popped up earlier. sslget sets
SNI header without HTTP Host header for a while. Since FreeIPA uses
mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header
before, sslget didn't fail in the past.

Yes, I have fixed sslget to send a HTTP Host header with hostname and port.

No, that won't work. You'd have to change the configuration before you
run uninstall. Install still won't work because uninstall was
incomplete. It's still necessary to remove the Service Domain for the CA
from LDAP. The sslget command call removes it. It's also possible to
remove it with ldapremove over ldapi. The entry is in the
cn=CAList,ou=Security Domain,o=ipaca subtree.

I'm not sure I follow. You mean my proposed workaround won't work? I
think it should because the IPA installer directly tweaks only a few
things in nss.conf so if one manually sets NSSSNI then it should be
preserved between install/uninstall.

I was under the impression this is a fresh install so there is no
existing data to deal with.

rob

If I did read logs right, there was ipa-server-installed, CA 
uninstallation failed and now IPA server install is 

Re: [Freeipa-users] CA installation failed on server

[Christian Heimes]

On 2015-11-30 17:48, Martin Basti wrote:
> If I did read logs right, there was ipa-server-installed, CA
> uninstallation failed and now IPA server install is failing because new
> CA cannot be installed due the old instance of CA.

Martin, you are right. Daniel didn't mention reinstallation in his
initial mail. You and me are aware of the details because we talked to
him on IRC. I just asked Daniel on IRC and he confirmed it. Rob couldn't
know the fact, hence the misunderstanding.

Robert, your workaround fixes uninstallation. But it doesn't fix an
already broken system. ipa-server --uninstall leaves the system in an
inconsistent state. It removes most of the CA but leaves entries in LDAP
ou=Security Domain,o=ipaca.




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

Re: [Freeipa-users] CA installation failed on server

[Rob Crittenden]

Christian Heimes wrote:
> On 2015-11-30 12:51, Martin Basti wrote:
>>
>>
>> On 28.11.2015 00:14, Rob Crittenden wrote:
>>> Martin Štefany wrote:
 Hello,

 I remember experiencing this, but I'm not sure of solution. I think it's
 related to apache (httpd) and his group.

 My notes for IPA installation on CentOS 7.x say:

 # groupadd -g 48 apache
 # yum -y install ipa-server bind bind-dyndb-ldap
 # usermod -g apache apache
 # ipa-server-install...

 CentOS is somehow not creating group apache for apache user and then
 assuming root which is then causing problems with apache later. Pre-
 creating such group before installing httpd and then usermod-ing user
 apache might solve it.

 Did you get any warnings while running:
 # yum install -y ipa-server bind bind-dyndb-ldap ?


 If possible, try installation from scratch with my notes on fresh
 system. If not:

 # systemctl stop apache   # if it runs
 # groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
 48, or use 'groupadd -r apache' instead
 # usermod -g apache apache
 # ipa-server-install...

>>> Sounds unlikely to me. If indeed it did happen you'd need to file a bug
>>> against Apache to create its own uid/gid, which I'm pretty certain it
>>> already does.
>>>
>>> In any case, dogtag doesn't run in Apache so it would be unlikely to
>>> blow up in the CA installer.
>>>
>>> cating the contents of a directory into one log is not at all helpful,
>>> especially given that you missed all the important bits in the
>>> subdirectories beneath it. This is just a mishmash of stuff. We need to
>>> see /var/log/pki/pki-tomcat/ca/debug.
>>>
>>> /var/log/ipaserver-install.log might also be useful to see though it
>>> probably just records in a more verbose way the fact that pkispawn
>>> failed.
>>>
>>> rob
>>>
>> Hello,
>>
>> I see in log this error message:
>>
>> 2015-11-26 08:41:53 pkidestroy  : ERROR...
>> subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n',
>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d',
>> '/etc/pki/pki-tomcat/alias', '-e',
>> 'name="/var/lib/pki/pki-tomcat"=CA=caList=ipa.home=443=8443=8443=8443=remove',
>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned
>> non-zero exit status 6!
>>
>> It means that the CA has no been sucessfully uninstalled, and it can
>> cause issues during installation
>> PKI bug:
>> https://fedorahosted.org/pki/ticket/1704
>>
>> Christian may have workaround (CCed)
> 
> Hi Martin and Martin,
> 
> last week I have identified an incompatibility between Dogtag's sslget
> command and Apache HTTP. sslget sends a server name indication during
> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer
> versions of Apache HTTP don't accept requests with SNI and without HTTP
> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log.
> 
> The simplest workaround is to bypass Apache and talk to Dogtag directly.
> In order to do bypass the Apache proxy you have to log onto the server.
> You also have to become root so you can access the NSS database that
> contains the private key for authentication. Simply copy and paste the
> sslget command from the log (everything between "Command '[" and "]'
> returend non-zero exit status 6!"), remove the comma, replace
> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command
> should look like:
> 
> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ...
> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443'

mod_nss added support for SNI in Fedora 23. It should behave the same
way as mod_ssl, denying a request that contains an SNI hostname but no
Host header.

I assume you've filed a bug against dogtag to send a Host header in the
request?

A better workaround would be to add NSSSNI off to
/etc/httpd/conf.d/nss.conf within the default VH. Retrying the install
should work then, or at least get past this sslget error.

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] CA installation failed on server

[Christian Heimes]

On 2015-11-30 16:27, Rob Crittenden wrote:
> Christian Heimes wrote:
>> On 2015-11-30 12:51, Martin Basti wrote:
>>>
>>>
>>> On 28.11.2015 00:14, Rob Crittenden wrote:
 Martin Štefany wrote:
> Hello,
>
> I remember experiencing this, but I'm not sure of solution. I think it's
> related to apache (httpd) and his group.
>
> My notes for IPA installation on CentOS 7.x say:
>
> # groupadd -g 48 apache
> # yum -y install ipa-server bind bind-dyndb-ldap
> # usermod -g apache apache
> # ipa-server-install...
>
> CentOS is somehow not creating group apache for apache user and then
> assuming root which is then causing problems with apache later. Pre-
> creating such group before installing httpd and then usermod-ing user
> apache might solve it.
>
> Did you get any warnings while running:
> # yum install -y ipa-server bind bind-dyndb-ldap ?
>
>
> If possible, try installation from scratch with my notes on fresh
> system. If not:
>
> # systemctl stop apache   # if it runs
> # groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
> 48, or use 'groupadd -r apache' instead
> # usermod -g apache apache
> # ipa-server-install...
>
 Sounds unlikely to me. If indeed it did happen you'd need to file a bug
 against Apache to create its own uid/gid, which I'm pretty certain it
 already does.

 In any case, dogtag doesn't run in Apache so it would be unlikely to
 blow up in the CA installer.

 cating the contents of a directory into one log is not at all helpful,
 especially given that you missed all the important bits in the
 subdirectories beneath it. This is just a mishmash of stuff. We need to
 see /var/log/pki/pki-tomcat/ca/debug.

 /var/log/ipaserver-install.log might also be useful to see though it
 probably just records in a more verbose way the fact that pkispawn
 failed.

 rob

>>> Hello,
>>>
>>> I see in log this error message:
>>>
>>> 2015-11-26 08:41:53 pkidestroy  : ERROR...
>>> subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n',
>>> 'subsystemCert cert-pki-ca', '-p', '272326334956', '-d',
>>> '/etc/pki/pki-tomcat/alias', '-e',
>>> 'name="/var/lib/pki/pki-tomcat"=CA=caList=ipa.home=443=8443=8443=8443=remove',
>>> '-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned
>>> non-zero exit status 6!
>>>
>>> It means that the CA has no been sucessfully uninstalled, and it can
>>> cause issues during installation
>>> PKI bug:
>>> https://fedorahosted.org/pki/ticket/1704
>>>
>>> Christian may have workaround (CCed)
>>
>> Hi Martin and Martin,
>>
>> last week I have identified an incompatibility between Dogtag's sslget
>> command and Apache HTTP. sslget sends a server name indication during
>> the TLS/SSL handshake but doesn't send a HTTP Host header. Newer
>> versions of Apache HTTP don't accept requests with SNI and without HTTP
>> Host. You should see a HTTP/400 Bad Request in /var/log/httpd/error_log.
>>
>> The simplest workaround is to bypass Apache and talk to Dogtag directly.
>> In order to do bypass the Apache proxy you have to log onto the server.
>> You also have to become root so you can access the NSS database that
>> contains the private key for authentication. Simply copy and paste the
>> sslget command from the log (everything between "Command '[" and "]'
>> returend non-zero exit status 6!"), remove the comma, replace
>> 'ipa.home:443' with 'ipa.home:8443' and run the command. The command
>> should look like:
>>
>> '/usr/bin/sslget' '-n' 'subsystemCert cert-pki-ca' ...
>> '/ca/agent/ca/updateDomainXML' 'ipa.home:8443'
> 
> mod_nss added support for SNI in Fedora 23. It should behave the same
> way as mod_ssl, denying a request that contains an SNI hostname but no
> Host header.
> 
> I assume you've filed a bug against dogtag to send a Host header in the
> request?
> 
> A better workaround would be to add NSSSNI off to
> /etc/httpd/conf.d/nss.conf within the default VH. Retrying the install
> should work then, or at least get past this sslget error.

That might explain why the issue hasn't popped up earlier. sslget sets
SNI header without HTTP Host header for a while. Since FreeIPA uses
mod_nss instead of mod_ssl and mod_nss hasn't processed the SNI header
before, sslget didn't fail in the past.

Yes, I have fixed sslget to send a HTTP Host header with hostname and port.

No, that won't work. You'd have to change the configuration before you
run uninstall. Install still won't work because uninstall was
incomplete. It's still necessary to remove the Service Domain for the CA
from LDAP. The sslget command call removes it. It's also possible to
remove it with ldapremove over ldapi. The entry is in the
cn=CAList,ou=Security Domain,o=ipaca subtree.

Christian



signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users 

Re: [Freeipa-users] Ticket transfer from host to host

[Rob Crittenden]

Thomas Lau wrote:
> Hi Rob,
> 
> So what you are trying to say is that it's nothing to do with FreeIPA
> but ssh client itself?

Correct.

rob

> 
> On Mon, Nov 30, 2015 at 11:39 AM, Rob Crittenden  > wrote:
> 
> Thomas Lau wrote:
> > ​Hi all,
> >
> > I am running FreeIPA 3.3.x in our environment. First I did is kinit on
> > client 1, then ssh to host A, it works fine; But then if I want to ssh
> > from host A to host B, I have to do kinit again, is there have a
> way to
> > do ticket transfer? Or is it call "Ticket Delegation"? How could I
> > config it to function properly?​
> >
> >
> 
> man ssh
> 
>  -K  Enables GSSAPI-based authentication and forwarding
> (delegation)
>  of GSSAPI credentials to the server.
> 
> 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] CA installation failed on server

[Rob Crittenden]

Christian Heimes wrote:
> On 2015-11-30 17:48, Martin Basti wrote:
>> If I did read logs right, there was ipa-server-installed, CA
>> uninstallation failed and now IPA server install is failing because new
>> CA cannot be installed due the old instance of CA.
> 
> Martin, you are right. Daniel didn't mention reinstallation in his
> initial mail. You and me are aware of the details because we talked to
> him on IRC. I just asked Daniel on IRC and he confirmed it. Rob couldn't
> know the fact, hence the misunderstanding.
> 
> Robert, your workaround fixes uninstallation. But it doesn't fix an
> already broken system. ipa-server --uninstall leaves the system in an
> inconsistent state. It removes most of the CA but leaves entries in LDAP
> ou=Security Domain,o=ipaca.

I don't know quite what to say.

Any already broken system? The IPA installer isn't (yet) idempotent so
any failure installing needs to be uninstalled, corrected, and tried
again. There is no powering onwards.

Left over data? In a standalone system this is moot because IPA needs to
start as a clean slate for a new installation attempt.

I really don't see how my workaround made any difference at all in the
uninstall since it should just be removing bits not doing anything over
LDAP. And in any case, uninstalling the server also wipes out the LDAP
server so it's a moot point.

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] HBAC - Limit SSH access to "test" systems

[Alexander Skwar]

Hello Alexander ;)

2015-11-30 10:38 GMT+01:00 Alexander Bokovoy :

> HBAC is enforced by SSSD over PAM. All you need to ensure is that an
> application (sshd in this case) uses PAM. Then you setup HBAC rules,
> disable allow_all rule, and then SSSD will verify rules on logon via
> sshd, checking all rules for service 'sshd' and applying to this host
> (via hostgroup or to all hosts).

Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
change the "default" behaviour? I mean, by default, everything will
be allowed for everyone on every system.

When I deactivate the allow_all - won't that mean, that nothing will
be allowed for everyone on all systems?

Playing with the HBAC Test thingie in the web interface seems to imply
that. And because of that, I now have 3 rules:

1) allow_all_but_ssh
2) ssh_prod
3) ssh_test

1) Who: Anyone, Accessing: Any host, Via Service: Selected every
   service, but not sshd
2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd
3) Who: Anyone, Accessing: Host groups: test, Via service: sshd

That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there.
Reason: I manually have to select every service and remove sshd. But if
a new service were to be added, I'd have to remember to add it there as
well. Not cool. Even more so, because I'm not the only admin. Colleagues
would have to know this as well. Not cool².

Somehow I'm missing "deny"-rules, I think. Nice to have allow rules,
but I'm rather looking for a way to deny something :/

Don't know, but that seems to be too complicated. Or is that really the
way to do that?

Thanks a lot,

Alexander
-- 
=>Google+ => http://plus.skwar.me <==
=> Chat (Jabber/Google Talk) => a.sk...@gmail.com <==

-- 
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.1 -> 4.2 replica upgrade process

[Martin Basti]

On 30.11.2015 10:12, Andreas Calminder wrote:

Hello!
This might be trivial but I want to double check the preferred way of 
upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 
4.1), 1 acting as master with a ca (external certificate), the 
replicas are also ca's, they're only syncing to and from the master, 
unaware of each other. The replicas handle all client requests. The 
master also run a one-way winsync agreement with one of our active 
directory servers.


For some reason I think that I should start by upgrading the replicas 
and upgrade the master last, but I don't know why, I might have read 
it in somewhere, long ago. Is this the preferred way, does order even 
matter? The documentation just says /yum update ipa-server/ which 
seems easy enough, but I'd rather double check.


Best regards,
Andreas


Hello,

replicas and master are equal, so it should not matter which is upgraded 
as first.


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] HBAC - Limit SSH access to "test" systems

[Alexander Bokovoy]

On Mon, 30 Nov 2015, Alexander Skwar wrote:

Hello Alexander ;)

2015-11-30 10:38 GMT+01:00 Alexander Bokovoy :


HBAC is enforced by SSSD over PAM. All you need to ensure is that an
application (sshd in this case) uses PAM. Then you setup HBAC rules,
disable allow_all rule, and then SSSD will verify rules on logon via
sshd, checking all rules for service 'sshd' and applying to this host
(via hostgroup or to all hosts).


Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
change the "default" behaviour? I mean, by default, everything will
be allowed for everyone on every system.

When I deactivate the allow_all - won't that mean, that nothing will
be allowed for everyone on all systems?

Yes. HBAC system is built around a simple principle: everything is
denied unless allowed explicitly with specific rules.

We supply 'allow_all' rule for defaults and it is your duty to create
HBAC rules which suit your deployment needs.


Playing with the HBAC Test thingie in the web interface seems to imply
that. And because of that, I now have 3 rules:

1) allow_all_but_ssh
2) ssh_prod
3) ssh_test

1) Who: Anyone, Accessing: Any host, Via Service: Selected every
  service, but not sshd
2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd
3) Who: Anyone, Accessing: Host groups: test, Via service: sshd

That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there.
Reason: I manually have to select every service and remove sshd. But if
a new service were to be added, I'd have to remember to add it there as
well. Not cool. Even more so, because I'm not the only admin. Colleagues
would have to know this as well. Not cool².

Somehow I'm missing "deny"-rules, I think. Nice to have allow rules,
but I'm rather looking for a way to deny something :/

Don't know, but that seems to be too complicated. Or is that really the
way to do that?

Deny rules complicate things a lot, really. You can create a service
group that includes all your services but sshd and assign that service
group to allow rule. Maintaining a service group is less problematic
than looking into what rules deny/allow. Consider also the contextual
problem of what to do if HBAC rules become unavailable -- should the
unavailability of deny rule be treated as allow or not? We chose to
define deny by default and add allow rules on top of it.

All this is covered in IPA documentation.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html

--
/ 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] CA installation failed on server

[Martin Basti]

On 28.11.2015 00:14, Rob Crittenden wrote:

Martin Štefany wrote:

Hello,

I remember experiencing this, but I'm not sure of solution. I think it's
related to apache (httpd) and his group.

My notes for IPA installation on CentOS 7.x say:

# groupadd -g 48 apache
# yum -y install ipa-server bind bind-dyndb-ldap
# usermod -g apache apache
# ipa-server-install...

CentOS is somehow not creating group apache for apache user and then
assuming root which is then causing problems with apache later. Pre-
creating such group before installing httpd and then usermod-ing user
apache might solve it.

Did you get any warnings while running:
# yum install -y ipa-server bind bind-dyndb-ldap ?


If possible, try installation from scratch with my notes on fresh
system. If not:

# systemctl stop apache   # if it runs
# groupadd -g 48 apache   # I use 48 as apache's UID tends to be also
48, or use 'groupadd -r apache' instead
# usermod -g apache apache
# ipa-server-install...


Sounds unlikely to me. If indeed it did happen you'd need to file a bug
against Apache to create its own uid/gid, which I'm pretty certain it
already does.

In any case, dogtag doesn't run in Apache so it would be unlikely to
blow up in the CA installer.

cating the contents of a directory into one log is not at all helpful,
especially given that you missed all the important bits in the
subdirectories beneath it. This is just a mishmash of stuff. We need to
see /var/log/pki/pki-tomcat/ca/debug.

/var/log/ipaserver-install.log might also be useful to see though it
probably just records in a more verbose way the fact that pkispawn failed.

rob


Hello,

I see in log this error message:

2015-11-26 08:41:53 pkidestroy  : ERROR... 
subprocess.CalledProcessError:  Command '['/usr/bin/sslget', '-n', 
'subsystemCert cert-pki-ca', '-p', '272326334956', '-d', 
'/etc/pki/pki-tomcat/alias', '-e', 
'name="/var/lib/pki/pki-tomcat"=CA=caList=ipa.home=443=8443=8443=8443=remove', 
'-v', '-r', '/ca/agent/ca/updateDomainXML', 'ipa.home:443']' returned 
non-zero exit status 6!


It means that the CA has no been sucessfully uninstalled, and it can 
cause issues during installation

PKI bug:
https://fedorahosted.org/pki/ticket/1704

Christian may have workaround (CCed)
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] HBAC - Limit SSH access to "test" systems

[Jan Pazdziora]

On Mon, Nov 30, 2015 at 11:18:15AM +0100, Alexander Skwar wrote:
> 
> Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
> change the "default" behaviour? I mean, by default, everything will
> be allowed for everyone on every system.

No.

> When I deactivate the allow_all - won't that mean, that nothing will
> be allowed for everyone on all systems?

That's right, nothing will be allowed.

Disabling allow_all has the potential of making everything stop
working. You need to plan carefully and replace the allow_all with
tailored rules. For example, see

http://www.freeipa.org/page/Howto/HBAC_and_allow_all

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

[Freeipa-users] HBAC - Limit SSH access to "test" systems

[Alexander Skwar]

Hello

I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04
FreeIPA 3.3.4 clients so, that users in a user group called "customers"
can only access hosts, which are in a host group called "test". Users
from the user group "ops" should be able to access all systems (ie.
"prod" systems and also those "test" systems).

But I cannot get my head around to create proper HBAC rules/setup…

Could somebody maybe lend me a helping hand?

At the moment, I have set it up so, that I modified the "prod" systems
sshd_config and added "DenyGroups customer" there. On the test systems,
I don't have that line. That works, but it's not using IPA (in a sense…
I do have to modify the hosts configuration on the system, which I
dislike. Granted, with Chef, it's not much, but still *G*).


Thanks,

Alexander
-- 
=>Google+ => http://plus.skwar.me <==
=> Chat (Jabber/Google Talk) => a.sk...@gmail.com <==

-- 
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] Problem with AD authentication after updating to 7.2 OS server

[Morgan Marodin]

I've found the problem, using DEBUG3 into SSH service:
-
Nov 30 08:52:47 myserver sshd[9639]: debug1: Unspecified GSS failure.
Minor code may provide more information\nClock skew too great\n
Nov 30 08:52:47 myserver sshd[9639]: debug1: Got no client credentials
Nov 30 08:52:47 myserver sshd[9639]: debug3: mm_request_send entering: type
45
Nov 30 08:52:47 myserver sshd[9639]: debug3: userauth_finish: failure
partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password"
[preauth]
Nov 30 08:52:47 myserver sshd[9639]: debug1: Received
SSH2_MSG_UNIMPLEMENTED for 7 [preauth]

My client was 4 minutes early than IPA server. After syncing time via
ntpdate kerberos ticket authentication works correctly.

Thanks for your support, bye.
Morgan

2015-11-27 18:38 GMT+01:00 Sumit Bose :

> On Fri, Nov 27, 2015 at 06:16:51PM +0100, Morgan Marodin wrote:
> > Yes:
> > --
> > # ls -l /var/lib/sss/pubconf/krb5.include.d/
> > total 8
> > -rw-r--r-- 1 root root 208 Nov 27 17:37 domain_realm_ipa_mydomain_com
> > -rw-r--r-- 1 root root 118 Nov 27 17:37 localauth_plugin
> >
> > So what could I try to do?
>
> 'getent passwd' should return the same entry for the user name you use
> at the login prompt and the Kerberos principal (its the name shown by
> klist in the 'Default principal:' line) e.g.:
>
> # getent passwd tu1@ad.devel
> tu1@ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh
> # getent passwd tu1@AD.DEVEL
> tu1@ad.devel:*:1367201104:1367201104:t u:/home/ad.devel/tu1:/bin/sh
>
> From the logs I guess you used the name 'morgan.maro...@mydomain.com' at
> the login prompt.
>
> I assume you use ssh for the Kerberos/GSSAPI login. Please check on the
> client with klist if you got a service ticket for your linux client
> principal which should look like host/linux.client.name@IPA.DOMAIN. On
> Windows there is klist for the cmd shell as well.
>
> Additionally if there is a service ticket for the linux host sshd debug
> logs from the linux host would be useful. For this please set LogLevel to
> DEBUG3 in /etc/ssh/sshd_config (please note that the log might contain
> confidential keys or passwords).
>
> bye,
> Sumit
>
> > Thanks, Morgan
> >
> > 2015-11-27 17:47 GMT+01:00 Sumit Bose :
> >
> > > On Fri, Nov 27, 2015 at 05:35:42PM +0100, Morgan Marodin wrote:
> > > > Hi Sumit.
> > > >
> > > > I don't know why, but now kerberos ticket authentication is working
> on
> > > 6.7
> > > > clients.
> > > > On 7.2 clients now password authetications with Active Directory
> > > > credentials is working ... but not with kerberos ticket.
> > >
> > > This is most likely due to some issues while mapping the Kerberos
> > > principal to the local user name.
> > >
> > > Do you have a 'includedir /var/lib/sss/pubconf/krb5.include.d/' line at
> > > the beginning of you krb5.conf file? Does
> > > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists?
> > >
> > > bye,
> > > Sumit
> > >
>
-- 
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] HBAC - Limit SSH access to "test" systems

[Alexander Bokovoy]

On Mon, 30 Nov 2015, Alexander Skwar wrote:

Hello

I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04
FreeIPA 3.3.4 clients so, that users in a user group called "customers"
can only access hosts, which are in a host group called "test". Users
from the user group "ops" should be able to access all systems (ie.
"prod" systems and also those "test" systems).

But I cannot get my head around to create proper HBAC rules/setup…

Could somebody maybe lend me a helping hand?

At the moment, I have set it up so, that I modified the "prod" systems
sshd_config and added "DenyGroups customer" there. On the test systems,
I don't have that line. That works, but it's not using IPA (in a sense…
I do have to modify the hosts configuration on the system, which I
dislike. Granted, with Chef, it's not much, but still *G*).

HBAC is enforced by SSSD over PAM. All you need to ensure is that an
application (sshd in this case) uses PAM. Then you setup HBAC rules,
disable allow_all rule, and then SSSD will verify rules on logon via
sshd, checking all rules for service 'sshd' and applying to this host
(via hostgroup or to all hosts).

--
/ 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] FreeIPA and LetsEncrypt Question

[Alexander Bokovoy]

On Mon, 30 Nov 2015, Günther J. Niederwimmer wrote:

Hello ,

I have the question, know any from the FreeIPA "Gurus" ;-), are the new
upcoming LetsEncrypt Certificates compatible and working with FreeIPA?

We have plans to support issuing certificates via Let's Encrypt.

However, right now Let's encrypt only issues server certificates, not
CA roots, so you cannot use them to bootstrap IPA CA.
--
/ 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] FreeIPA 4.1 -> 4.2 replica upgrade process

[Martin Kosek]

On 11/30/2015 01:32 PM, Andreas Calminder wrote:
> Great, thanks!
> I'll just go ahead and yum update then :).

I would just recommend to upgrade one-by-one, to avoid replication conflicts if
multiple masters add the same entries in the tree in the same time.

> On 11/30/2015 11:58 AM, Martin Basti wrote:
>>
>>
>> On 30.11.2015 10:12, Andreas Calminder wrote:
>>> Hello!
>>> This might be trivial but I want to double check the preferred way of
>>> upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 4.1),
>>> 1 acting as master with a ca (external certificate), the replicas are also
>>> ca's, they're only syncing to and from the master, unaware of each other.
>>> The replicas handle all client requests. The master also run a one-way
>>> winsync agreement with one of our active directory servers.
>>>
>>> For some reason I think that I should start by upgrading the replicas and
>>> upgrade the master last, but I don't know why, I might have read it in
>>> somewhere, long ago. Is this the preferred way, does order even matter? The
>>> documentation just says /yum update ipa-server/ which seems easy enough, but
>>> I'd rather double check.
>>>
>>> Best regards,
>>> Andreas
>>>
>> Hello,
>>
>> replicas and master are equal, so it should not matter which is upgraded as
>> first.
>>
>> Martin
> 

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

[Freeipa-users] FreeIPA AD password sync

[Gašper Bregar]

I have been strugling with FreeIPA and AD password sync for a couple of
days now. At first everything was working fine, but then all of a sudden
the synchronization started to fail for me and another user.

The error in passsync log was

Ldap error in ModifyPassword
> 50: Insufficient access


It took me some time to figure out that it was failing just for the two us.
It was failing because we were in the admin user group in FreeIPA. Is this
intentional? Is it possible to somehow change this behaviour with a
setting?

Regards,
Gašper
-- 
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 and LetsEncrypt Question

[Günther J . Niederwimmer]

Hello ,

I have the question, know any from the FreeIPA "Gurus" ;-), are the new 
upcoming LetsEncrypt Certificates compatible and working with FreeIPA?

Thanks for a answer, 
-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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.1 -> 4.2 replica upgrade process

[Andreas Calminder]

Great, thanks!
I'll just go ahead and yum update then :).

/andreas

On 11/30/2015 11:58 AM, Martin Basti wrote:



On 30.11.2015 10:12, Andreas Calminder wrote:

Hello!
This might be trivial but I want to double check the preferred way of 
upgrading my ipa environment, I have 3 servers (Running Rhel 7.1, ipa 
4.1), 1 acting as master with a ca (external certificate), the 
replicas are also ca's, they're only syncing to and from the master, 
unaware of each other. The replicas handle all client requests. The 
master also run a one-way winsync agreement with one of our active 
directory servers.


For some reason I think that I should start by upgrading the replicas 
and upgrade the master last, but I don't know why, I might have read 
it in somewhere, long ago. Is this the preferred way, does order even 
matter? The documentation just says /yum update ipa-server/ which 
seems easy enough, but I'd rather double check.


Best regards,
Andreas


Hello,

replicas and master are equal, so it should not matter which is 
upgraded as first.


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