[Freeipa-users] Centos 7, CA log files, bug report?

[Lachlan Musicman]

Hi,

Not sure if this is a bug or if I'm ignorant of the RH world, but when I
try to do a fresh IPA install on Centos 7.2, I'm getting failures here:

  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpAGdITu''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
logs and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.
ipa.ipapython.install.cli.install_tool(Server): ERRORCA configuration
failed.


[root@emts-centos71-7f ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

CentOS Linux release 7.2.1511 (Core)

Most importantly for me, /var/log/pki-ca-install.log doesn't exist and
there is no file that looks like it anywhere on my system. Is this a bug?

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] idoverride-add gives incorrect, inconsistant results?

[Lachlan Musicman]

1.13.0

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 January 2016 at 18:49, Jakub Hrozek  wrote:

> On Tue, Jan 19, 2016 at 12:23:39AM +, Simpson Lachlan wrote:
> > Since I got the service back up and running, I was continuing my
> tests/learning by following the steps on the V4 Migrating existing
> environments to Trust page:
> >
> >
> http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#How_to_Test
> >
> >
> >
> > [root@vmts-linuxidm ~]# id testu...@co.org.au
> > uid=1750693931(testu...@co.org.au) gid=1750693931(testu...@co.org.au)
> groups=1750693931(testu...@co.org.au),1750687326(bioinf-st...@co.org.au)
> >
> >
> > Success and joy.
> >
> >
> > [root@vmts-linuxidm ~]# ipa idoverrideuser-add 'Default Trust View'
> testu...@co.org.au --uid 1506
> > ---
> > Added User ID override "testu...@co.org.au"
> > ---
> >   Anchor to override: testu...@co.org.au
> >   UID: 1506
> >
> >
> >
> > Great.
> >
> >
> > [root@vmts-linuxidm ~]# sudo systemctl restart sssd
> >
> > [root@vmts-linuxidm ~]# id testu...@co.org.au
> > uid=1750693931(testu...@co.org.au) gid=1750693931(testu...@co.org.au)
> groups=1750693931(testu...@co.org.au),1750687326(bioinf-st...@co.org.au)
> >
> >
> > Huh? The documentation linked to above says that uid should now be 1506?
>
> What sssd version?
>
> --
> 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] idoverride-add gives incorrect, inconsistant results?

[Lachlan Musicman]

The /var/log/sssd/ldap_child.log have one line repeated:

 [[sssd[ldap_child[9738 [ldap_child_get_tgt_sync] (0x0010): Failed to
init credentials: Cannot contact any KDC for realm UNIX.CO.ORG.AU

All other log files are 0 size.


cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 22 January 2016 at 11:17, Lachlan Musicman <data...@gmail.com> wrote:

> No, I've not updated to 1.13.0-41 - I do the "yum upgrades" relatively
> frequently, I don't think it's in the repos yet.
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 20 January 2016 at 19:42, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Wed, Jan 20, 2016 at 09:15:47AM +1100, Lachlan Musicman wrote:
>> > 1.13.0
>>
>> I suspect it's 7.2, then. Did you alrady update to the latest available
>> version (1.13.0-41)? If yes, do you have logfiles?
>>
>> See https://fedorahosted.org/sssd/wiki/Troubleshooting
>>
>
>
-- 
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] idoverride-add gives incorrect, inconsistant results?

[Lachlan Musicman]

No, I've not updated to 1.13.0-41 - I do the "yum upgrades" relatively
frequently, I don't think it's in the repos yet.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 January 2016 at 19:42, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Wed, Jan 20, 2016 at 09:15:47AM +1100, Lachlan Musicman wrote:
> > 1.13.0
>
> I suspect it's 7.2, then. Did you alrady update to the latest available
> version (1.13.0-41)? If yes, do you have logfiles?
>
> See https://fedorahosted.org/sssd/wiki/Troubleshooting
>
-- 
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] SSSD, sudo and FQDNs

[Lachlan Musicman]

Hola,

We couldn't get sssd and sudo to work and discovered this on the SSSD
troubleshooting page:

https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO#Knownissues

Is this on the radar to be solved at all or is it unsolvable?

Cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."

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

[Freeipa-users] AD group membership

[Lachlan Musicman]

Hi,

We seem to have some progress, after reading this blog post about sssd
performance tuning.

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

So now we see that on the FreeIPA server, everything is stable and always
produces the results we expect with regard to users and group membership.
It's also a bit speedier, which is nice.

Unfortunately, on the clients, we are still seeing groups "disappearing"
occasionally,

We found this thread from late last year that seemed to state exactly what
we are seeing, although our sssd_pac.log is empty. I have just added
debug_level = 7 to [pac] in sssd.conf on server and client.

https://www.redhat.com/archives/freeipa-users/2015-December/msg00180.html

Did anything come of this?

Cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] File user and group ownership listings...

[Lachlan Musicman]

Now that groups are working as expected, we have noticed that when listing
a directory the user and group now have full domain qualifiers.

This doesn't look great. We've also noticed that we now need to

chown :group@subdomain filename

(with default_domain_suffix set).


Is there a reason why when the group's name and ID is the same across both
domains, it can't be considered the same group for file ownership reasons?


cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 access denied, all AD groups not detected

[Lachlan Musicman]

FWIW,

We are seeing the issues that are described here:

https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html

I was about to write when I found this, it explains exactly what I am
seeing - right down to the "impossible to reproduce because it's so
(seemingly) random".


I am about to read up on the SSSD trouble shooting in order to up the logs
, but here is some output I can share - note that this all happened in
~5 minutes. As you can see, clearing the cache has various unpredictable
effects. Both users should return the same list of groups. This was
performed on a FreeIPA client.

[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd
[root@emts-facs ~]# rm -rf /var/lib/sss/db/*
[root@emts-facs ~]# systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)



Cheers
L.




--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 access denied, all AD groups not detected

[Lachlan Musicman]

Hmmm, I also now see

https://fedorahosted.org/sssd/ticket/2642
and
https://bugzilla.redhat.com/show_bug.cgi?id=1217127

Versions being run:

sssd-client-1.13.0-40.el7_2.4.x86_64
sssd-ad-1.13.0-40.el7_2.4.x86_64
sssd-proxy-1.13.0-40.el7_2.4.x86_64
sssd-1.13.0-40.el7_2.4.x86_64
sssd-common-1.13.0-40.el7_2.4.x86_64
sssd-common-pac-1.13.0-40.el7_2.4.x86_64
sssd-ipa-1.13.0-40.el7_2.4.x86_64
sssd-ldap-1.13.0-40.el7_2.4.x86_64
python-sssdconfig-1.13.0-40.el7_2.4.noarch
sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
sssd-krb5-1.13.0-40.el7_2.4.x86_64

ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 17 May 2016 at 22:34, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote:
> > FWIW,
> >
> > We are seeing the issues that are described here:
> >
> >
> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html
> >
> > I was about to write when I found this, it explains exactly what I am
> > seeing - right down to the "impossible to reproduce because it's so
> > (seemingly) random".
> >
> >
> > I am about to read up on the SSSD trouble shooting in order to up the
> logs
> > , but here is some output I can share - note that this all happened
> in
> > ~5 minutes. As you can see, clearing the cache has various unpredictable
> > effects. Both users should return the same list of groups. This was
> > performed on a FreeIPA client.
>
> There were some bugs related to external groups, what server and client
> packages version are you running?
>
> --
> 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] HBAC access denied, all AD groups not detected

[Lachlan Musicman]

It's worth noting that, in difference to the bug report:

1. We aren't making changes to the overrides. The overrides exist, they
just aren't propagating evenly or consistently.
2. We are seeing these errors in the various logs:


sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
[sysdb_delete_group] (0x0400): Error: 2 (No such file or directory)
sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)


krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8929
[k5c_send_data] (0x0200): Received error code 0
krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8931
[k5c_send_data] (0x0200): Received error code 1432158214

sssd_nss.log:Error: 3, 0, Account info lookup failed
sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
(0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error
message: Account info lookup failed
sssd_nss.log:Error: 3, 22, Account info lookup failed
sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
(0x1000): Got reply from Data Provider - DP error code: 3 errno: 0 error
message: Account info lookup failed


cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 18 May 2016 at 08:35, Lachlan Musicman <data...@gmail.com> wrote:

> Hmmm, I also now see
>
> https://fedorahosted.org/sssd/ticket/2642
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1217127
>
> Versions being run:
>
> sssd-client-1.13.0-40.el7_2.4.x86_64
> sssd-ad-1.13.0-40.el7_2.4.x86_64
> sssd-proxy-1.13.0-40.el7_2.4.x86_64
> sssd-1.13.0-40.el7_2.4.x86_64
> sssd-common-1.13.0-40.el7_2.4.x86_64
> sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> sssd-ipa-1.13.0-40.el7_2.4.x86_64
> sssd-ldap-1.13.0-40.el7_2.4.x86_64
> python-sssdconfig-1.13.0-40.el7_2.4.noarch
> sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> sssd-krb5-1.13.0-40.el7_2.4.x86_64
>
> ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 17 May 2016 at 22:34, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote:
>> > FWIW,
>> >
>> > We are seeing the issues that are described here:
>> >
>> >
>> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html
>> >
>> > I was about to write when I found this, it explains exactly what I am
>> > seeing - right down to the "impossible to reproduce because it's so
>> > (seemingly) random".
>> >
>> >
>> > I am about to read up on the SSSD trouble shooting in order to up the
>> logs
>> > , but here is some output I can share - note that this all happened
>> in
>> > ~5 minutes. As you can see, clearing the cache has various unpredictable
>> > effects. Both users should return the same list of groups. This was
>> > performed on a FreeIPA client.
>>
>> There were some bugs related to external groups, what server and client
>> packages version are you running?
>>
>> --
>> 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] AD Primary Groups are ignored in FreeIPA?

[Lachlan Musicman]

Hola,

We have an interesting scenario that is hard to find any information on.

Due to permission restrictions, a NAS that is mounted and visible by both
AD and 'nix clients, every user belongs to a particular primary group.

When we try doing idoverride's on the groups, it fails with the Primary
Group. In some cases, the primary group doesn't even appear in a getent or
id request. Sometimes it appears with incorrect name or GID.

We have found it hard to get repeatable "failures", but here are two:

1. getent group  (where groupname is any group, but is a primary
group for a subset of members)

 - does not return any member that has groupname as a primary group in AD.

2. Overriding a group

if the user has that group as a primary group (in AD), it will override the
name, but not the GID.
else, the override works.

There were a number of other unusual results that are hard to explain how
to reproduce because it was all so seemingly random.


I feel like it would be an obvious need - to translate or override AD
primary groups to FreeIPA groups, but this doesn't seem possible.

Have we set IPA  up incorrectly, or are we hitting on something else?

I found this AD support problem for Win2003, but I feel like it's old and
would surely have been solved?
https://support.microsoft.com/en-us/kb/275523

Also, their solution ("hack AD, then hack your other LDAP software") is,
for some reason, funny to me.

Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] After successful ipa-client-install, sssd not used?

[Lachlan Musicman]

Hola,

We successfully installed ipa-server, and then successfully joined an AD in
a one way trust.
All in IPA are Centos 7.2 latest updates.

I can successfully get info from AD by using: $id username on the server.

I can successfully *join* the new ipa server with a client using
ipa-client-install. (both on stdout and /var/log/ipaclient-install look
good).

I have followed these instructions to add an external mapped group, an
internal group and a HBAC.

http://www.freeipa.org/page/Active_Directory_trust_setup


But, for some reason I can't then login to that client using AD
credentials.

In fact, on the client in question, all indicators are that the username
being used is "unknown". I see little to nothing in /var/log/sssd/*, a few
lines, late, in /var/log/dirsrv/slapd/. Most of the live logging of
auth seems to be in /var/log/secure.

My feeling is that the client successfully joins, but then isn't using sssd
as it's authentication system.

Where should I start looking? The logs aren't showing me anything of note.
What should I test? How can I test?

I have had this working previously on a test domain, but it's hard to know
what I've done differently due to time and how long it took to get it
working last time.

Cheers
L.




--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

Hey,

While hunting this sssd/hbac/AD user problem, I noticed in the
selinux_child.log a lot of errors that look like this:

(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [get_seuser]
(0x0020): Cannot query for galaxy
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [set_seuser]
(0x0020): Cannot verify the SELinux user
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
Cannot set SELinux login context.
(Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
selinux_child failed!
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
selinux_child started.
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
context initialized
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
performing selinux operations
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/active//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [get_seuser]
(0x0020): Cannot query for simpsonlach...@petermac.org.au
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [set_seuser]
(0x0020): Cannot verify the SELinux user
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
Cannot set SELinux login context.
(Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
selinux_child failed!
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
selinux_child started.
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
context initialized
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
performing selinux operations
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/active//seusers.final: 10):
ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not parse seuser record
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not cache file database
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): could not enter read-only section
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [get_seuser]
(0x0020): Cannot query for madhamshettiwar p...@petermac.org.au
(Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
(0x0020): expected character ':', but found 'j'
(/etc/selinux/targeted/modules/tmp//seusers.final: 10):



We have SELinux disabled on all of our servers, but we hadn't disabled this
check in sssd.conf. So we enabled it in sssd.conf and everything worked
fine.

But it should be noted that this check seems to be failing on a space in
the AD user names.

(I know, spaces in user names is weird, wrong and embarrassing, but it's
not my department. A fantastic example of Technical Debt and why project
planning and testing are best done before implementation.)

cheers
L.
--
The most dangerous 

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

On 14 July 2016 at 17:44, Sumit Bose <sb...@redhat.com> wrote:

> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> >
> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> >
> > Installed Packages
> > Name: ipa-server
> > Arch: x86_64
> > Version : 4.2.0
> > Release : 15.0.1.el7.centos.17
> > Size: 5.0 M
> > Repo: installed
> > >From repo   : updates
> > Summary : The IPA authentication server
> >
> >
> > Successfully joined in one way trust to AD.
> >
> > Successfully have added hosts (Centos 7, sssd 1.13.0).
> >
> >
> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
> > 
> > 5 HBAC rules matched
> > 
> >
> >   Rule name: allow_all
> >   User category: all
> >   Host category: all
> >   Service category: all
> >   Description: Allow all users to access any host from any host
> >   Enabled: FALSE
> >
> > ...
> >
> >   Rule name: ssh to galaxy
> >   Service category: all
> >   Description: Allows ssh to galaxy server
> >   Enabled: TRUE
> >   User Groups: ad_users
> >   Hosts: papr-res-galaxy.unix.petermac.org.au
> >
> >
> >
> >
> > With allow_all HBAC rule enabled, can login every time with
> >
> > ssh user@ad_domain@unix_host
> >
> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
> >
> > ad_users is a POSIX group with a GID. It has one member, the group
> >
> > ad_external an external group with a single, external, member
> >
> > pmc-res-ipaus...@petermac.org.au
> >
> > which is an AD group containing all the users that should have access to
> > the host.
> >
> >
> > With allow_all disabled and "ssh to galaxy" enabled, some users can login
> > and some can't. There is no discernable pattern that might explain why
> some
> > are discriminated against.
> >
> > Here is the test from the server:
> >
> > [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> > 
> > Access granted: True
> > 
> >   Matched rules: ssh to galaxy
> >   Not matched rules: Computing Cluster
> >   Not matched rules: FACS Computing
> >
> > I've installed ipa-admintools on the host in question and got the same
> > result.
> >
> > To be on the safe side/tick all boxes, I have cleared the cache on the
> host
> > in question:
> >
> > systemctl stop sssd
> > sss_cache -E
> > systemctl start sssd
> >
> > and confirmed success with a status check.
> >
> > When the user tries to login, it fails.
> >
> > Log is here:
> >
> > http://dpaste.com/0VAFNPH
> >
> >
> > The top is where the negotiating starts to the best of my knowledge.
> >
> > The attempts fails, with no information that is useful to me:
> >
> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_get_category] (0x0200): Category is set to 'all'.
> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
> [ssh
> > to galaxy]
> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
> [ssh
> > to galaxy]
> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_eval_user_element] (0x1000): [3] groups for [
> > sandsjor...@petermac.org.au]
>
> According to the HBAC evaluation the user is a member of 3 groups. Is
> this the expected number?
>
> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
> list of groups on the client and the IPA server? (The client does not
> talk to AD directly only to the IPA server, so if something is already
> missing on the server it cannot be seen on the client as well).
>
>
No, this is incorrect. He belongs to 14 groups on both the FreeIPA server
and the host in question.

[root@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc -l
14

[root@papr-res-galaxy ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc
-l
14



> Can you send me the SSSD cache file from the client
> /var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
> Since it might contain password hashes you might want to remove
> lines with 'cachedPassword' before
>
>

Ok, off list.



> 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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Lachlan Musicman]

This is exactly the issue I'm seeing too, various differences, but the
symptoms are the same.

Main diff would be that sometimes stopping sssd, clearing cache and
restarting sssd works, but only if individual AD domain members are added
to the external group - not AD domain groups.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 13 July 2016 at 08:07, Sullivan, Daniel [AAA] <
dsulliv...@bsd.uchicago.edu> wrote:

> Justin,
>
> I really appreciate you taking the time to respond to me.  This problem is
> driving me crazy and I will certainly take any help I can get. My suspicion
> is that the external user group in the policy below was causing the log
> entry you specified, removing it from the policy does not remediate the
> problem, even after flushing the client cache.
>
> The way I have this setup is as follows:
>
> 1) I created a POSIX group in IPA named 'cri-cri_server_administrators_ipa<
> https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#cri-cri_server_administrators_ipa>’
> and allowed IPA to assign the GID.
> 2) I created an external group in IPA named
> 'cri-cri_server_administrators_external<
> https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#cri-cri_server_administrators_external>’
> and added the AD group in the trusted domain as an external member to this
> group (cri-cri_server_administrat...@bsdad.uchicago.edu cri-cri_server_administrat...@bsdad.uchicago.edu>).
> 3) I added the group cri-cri_server_administrators_external<
> https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#cri-cri_server_administrators_external>
> as a member of 'cri-cri_server_administrators_ipa<
> https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#cri-cri_server_administrators_ipa
> >’
>
> The HBAC rule is configured as (removing the external group does not seem
> to make a difference).
>
> [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show
> 'cri-cri_server_administrators_allow_all'
>   Rule name: cri-cri_server_administrators_allow_all
>   Host category: all
>   Service category: all
>   Description: Allow anyone in
> cri-cri_server_administrat...@bsdad.uchicago.edu cri-cri_server_administrat...@bsdad.uchicago.edu> to login to any machine
>   Enabled: TRUE
>   User Groups: cri-cri_server_administrators_external,
> cri-cri_server_administrators_ipa
> [root@cri-ksysipadcp2 a.cri.dsullivan]#
>
> For example, the problem still persists when the policy is configured in
> this manner:
>
> [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show
> 'cri-cri_server_administrators_allow_all'
>   Rule name: cri-cri_server_administrators_allow_all
>   Host category: all
>   Service category: all
>   Description: Allow anyone in
> cri-cri_server_administrat...@bsdad.uchicago.edu cri-cri_server_administrat...@bsdad.uchicago.edu> to login to any machine
>   Enabled: TRUE
>   User Groups: cri-cri_server_administrators_ipa
>
> And my login validates against the host in question as follows:
>
> As I said I have this working consistently (i.e. can flush the cash) on
> another host with the same exact version of IPA and SSSD.  Here is a
> validation of hbactest (works with either of the two policy configurations
> above).
>
> [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbactest
> User name: a.cri.dsulli...@bsdad.uchicago.edu a.cri.dsulli...@bsdad.uchicago.edu>
> Target host: cri-kcriwebgdp1.cri.uchicago.edu<
> http://cri-kcriwebgdp1.cri.uchicago.edu>
> Service: sshd
> 
> Access granted: True
> 
>   Matched rules: cri-cri_server_administrators_allow_all
>   Not matched rules: cri-hpc_server_administration
>   Not matched rules: Gardner_cluster_login_no_ssh
>   Not matched rules: s.cri.ipa-idprovisioner_domain_controllers
> [root@cri-ksysipadcp2 a.cri.dsullivan]#
>
> Thank you again for your response.
>
> Best,
>
> Dan
>
> On Jul 12, 2016, at 4:12 PM, Justin Stephenson  > wrote:
>
>
> Hello,
>
> I am assuming this is the AD trust user that is having the problem with
> HBAC, in my testing I was only allowed access when the HBAC rule is linked
> to the IDM POSIX AD trust group and not the external group used to retrieve
> AD trust users. I noticed the following in the logs which is why I mention
> this:
>
> (Tue Jul 12 13:30:12 2016) [sssd[be[ipa.cri.uchicago.edu<
> http://ipa.cri.uchicago.edu>]]] [hbac_user_attrs_to_rule] (0x2000): Added
> non-POSIX group [cri-cri_server_administrators_external] to rule
> [cri-cri_server_administrators_allow_all]
>
> If this does not help, could you share with us more about the HBAC rule
> 'cri-cri_server_administrators_allow_all' and how it is configured?
>
> # ipa hbacrule-show 'cri-cri_server_administrators_allow_all'
>
> Kind regards,
>
> Justin Stephenson
>
> On 07/12/2016 04:11 PM, Sullivan, Daniel [AAA] wrote:
>
> Hi,
>
> I am experiencing an HBAC issue that is proving to be very difficult to
> diagnose.  It appears very closely 

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Ok, I have some logs of sssd 1.13.0 not working. Same values as before:

FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156

Installed Packages
Name: ipa-server
Arch: x86_64
Version : 4.2.0
Release : 15.0.1.el7.centos.17
Size: 5.0 M
Repo: installed
>From repo   : updates
Summary : The IPA authentication server


Successfully joined in one way trust to AD.

Successfully have added hosts (Centos 7, sssd 1.13.0).


[root@vmpr-linuxidm ~]# ipa hbacrule-find

5 HBAC rules matched


  Rule name: allow_all
  User category: all
  Host category: all
  Service category: all
  Description: Allow all users to access any host from any host
  Enabled: FALSE

...

  Rule name: ssh to galaxy
  Service category: all
  Description: Allows ssh to galaxy server
  Enabled: TRUE
  User Groups: ad_users
  Hosts: papr-res-galaxy.unix.petermac.org.au




With allow_all HBAC rule enabled, can login every time with

ssh user@ad_domain@unix_host

If I implement a HBAC rule "ssh to galaxy" as per above, with:

ad_users is a POSIX group with a GID. It has one member, the group

ad_external an external group with a single, external, member

pmc-res-ipaus...@petermac.org.au

which is an AD group containing all the users that should have access to
the host.


With allow_all disabled and "ssh to galaxy" enabled, some users can login
and some can't. There is no discernable pattern that might explain why some
are discriminated against.

Here is the test from the server:

[root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
--host=papr-res-galaxy.unix.petermac.org.au --service=sshd

Access granted: True

  Matched rules: ssh to galaxy
  Not matched rules: Computing Cluster
  Not matched rules: FACS Computing

I've installed ipa-admintools on the host in question and got the same
result.

To be on the safe side/tick all boxes, I have cleared the cache on the host
in question:

systemctl stop sssd
sss_cache -E
systemctl start sssd

and confirmed success with a status check.

When the user tries to login, it fails.

Log is here:

http://dpaste.com/0VAFNPH


The top is where the negotiating starts to the best of my knowledge.

The attempts fails, with no information that is useful to me:

230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_get_category] (0x0200): Category is set to 'all'.
231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
to galaxy]
232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
to galaxy]
233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [3] groups for [
sandsjor...@petermac.org.au]
234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
[Success (Permission denied)]
236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]


Cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 12 July 2016 at 09:08, Lachlan Musicman <data...@gmail.com> wrote:

> Alex, Sumit,
>
> Which log levels would you recommend for sssd to help debug this issue?
>
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 11 July 2016 at 17:15, Sumit Bose <sb...@redhat.com> wrote:
>
>> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
>> > On 11 July 2016 at 16:44, Alexander Bokovoy <aboko...@redhat.com>
>> wrote:
>> >
>> > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>> > >
>> > >> Hola,
>> > >>
>> > >> Centos 7, up to date.
>> > >>
>> > >> [root@linuxidm ~]# ipa --version
>> > >> VERSION: 4.2.0, API_VERSION: 2.156
>> > >>
>> > >> One way trust is successfully established, can login with
>> > >>
>> > >> ssh usern...@domain1.com@server1.domain2.com
>> > >>
>> > >> Am testing to get HBAC to work.
>> > >>
>> > >> I've noticed that with th

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Previously we did have the default_domain_suffix set, but we had to unset
it. I can't remember why we had to - something to do with
ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
We really wanted to use the dds => the researchers are complaining of
broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
I will need to teach ssh config.

Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > I've updated all the relevant hosts and the FreeIPA server to the COPR
> sssd
> > 1.14.0 release and the problem seems to have disappeared.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

Ok, I've just spoken with my colleague that has been involved in the IPA
roll out, and he said he thought that override_space wasn't compatible with
ID overrides?

Either way, since we have a working system we are reticent to make too many
changes - soon we will have a test system in place and I will be able to
check it then?

Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 20:17, Lachlan Musicman <data...@gmail.com> wrote:

> Wont be able to check until Monday morning (Australia's weekend has
> started) but can check, yes.
>
> And the reason I reported to you is because you will have more weight with
> selinux bug tickets than I would.
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 18:05, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Fri, Jul 15, 2016 at 08:59:43AM +0200, Lukas Slebodnik wrote:
>> > On (15/07/16 12:56), Lachlan Musicman wrote:
>> > >This line:
>> > >
>> > >We have SELinux disabled on all of our servers, but we hadn't disabled
>> this
>> > >check in sssd.conf. So we enabled it in sssd.conf and everything worked
>> > >fine.
>> > >
>> > >Should read that we *disabled* selinux.
>> > >
>> > >selinux_provider = none
>> > Could you also try another solution?
>> > put "override_space = _" into "sssd" section in sssd.conf
>> > and restart sssd.
>> >
>> > As a result of this space will be replaced with underscore
>> > and libsemanage should not complain.
>> >
>> > @see man sssd.conf -> override_space
>>
>> This is either a bug in semenage, we should file one and ask the
>> semanage developers if there is a proper way to quote the spaces.
>>
>> But yes, selinux_provider=none would disable this area of code.
>>
>> --
>> 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] HBAC and AD users

[Lachlan Musicman]

Ok, the bad news is that it didn't last. We are still having the same
problem - HBAC is rejecting users because not all jobs are being discovered
on the host.

I turned the debug_level up to 10 as requested, but to be honest, it's
impossible to find anything in the logs because it's so verbose - suddenly
there are timer events everywhere. I'm going to turn it down to 7 again so
I can actually parse it.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > I've updated all the relevant hosts and the FreeIPA server to the COPR
> sssd
> > 1.14.0 release and the problem seems to have disappeared.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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] HBAC and AD users

[Lachlan Musicman]

I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't loginand I can't even
show that this is the case because now they can login. Difficult to
reproduce :/

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 July 2016 at 11:13, Lachlan Musicman <data...@gmail.com> wrote:

> Ok, the bad news is that it didn't last. We are still having the same
> problem - HBAC is rejecting users because not all jobs are being discovered
> on the host.
>
> I turned the debug_level up to 10 as requested, but to be honest, it's
> impossible to find anything in the logs because it's so verbose - suddenly
> there are timer events everywhere. I'm going to turn it down to 7 again so
> I can actually parse it.
>
> Cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 17:56, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
>> > I've updated all the relevant hosts and the FreeIPA server to the COPR
>> sssd
>> > 1.14.0 release and the problem seems to have disappeared.
>>
>> Great, but please keep an eye on the machine, the 1.14 branch is still
>> kindof fresh and we did a lot of changes.
>>
>> About the HBAC issue, did you use the default_domain_suffix previously?
>>
>> --
>> 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] HBAC and AD users

[Lachlan Musicman]

On 19 July 2016 at 16:40, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > I think the thing that frustrates the most is that id u...@domain.com is
> > returning correct data on both but they can't loginand I can't even
> > show that this is the case because now they can login. Difficult to
> > reproduce :/
>
> Debugging from HBAC should at least tell you why the rules didn't
> match...
>


Sorry, I should have been clear - the issue is exactly the same. HBAC
rejected the user because they weren't in the correct groups, but sssd
hadn't got the correct number of groups from the AD server, and had missed
the group in question.

This is the user that reported the issue yesterday morning:

[root@vmpr-linuxidm ~]# id "lupat richard"@petermac.org.au | tr "," "\n" |
wc -l
22

Here are the relevant lines from the log.

 (Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_attrs_to_rule] (0x1000): Processing rule [Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_user_attrs_to_rule] (0x1000): Processing users for rule [Computing
Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [12] groups for [Lupat Richard]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research Bioinformatics Students
Reading Group,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Assistants,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf-Cluster,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=External - Exchange 2010
Users,OU=SOE & IT,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=VPN Access - General,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Mac Users,OU=!Exchange
Distribution Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf - Team,OU=!Security
Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Bioinformatics,OU=!Exchange Distribution Groups,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing
CN=DM_Outlook_Find,CN=Users,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected groups second component, got Users
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=RES_BioInformatics,OU=Department
Groups,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Sure - I've got tomorrow off, so it will be Friday morning.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 July 2016 at 17:14, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> > On 19 July 2016 at 16:40, Jakub Hrozek <jhro...@redhat.com> wrote:
> >
> > > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > > I think the thing that frustrates the most is that id
> u...@domain.com is
> > > > returning correct data on both but they can't loginand I can't
> even
> > > > show that this is the case because now they can login. Difficult to
> > > > reproduce :/
> > >
> > > Debugging from HBAC should at least tell you why the rules didn't
> > > match...
> > >
> >
> >
> > Sorry, I should have been clear - the issue is exactly the same. HBAC
> > rejected the user because they weren't in the correct groups, but sssd
> > hadn't got the correct number of groups from the AD server, and had
> missed
> > the group in question.
>
> Do you have the logs from the server and the client? If yes, feel free
> to send them in private mail if they are confidential, I'll try to
> find something in them.
>
> Specifying which groups are missing would help as well.
>
-- 
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] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

Wont be able to check until Monday morning (Australia's weekend has
started) but can check, yes.

And the reason I reported to you is because you will have more weight with
selinux bug tickets than I would.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 18:05, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Fri, Jul 15, 2016 at 08:59:43AM +0200, Lukas Slebodnik wrote:
> > On (15/07/16 12:56), Lachlan Musicman wrote:
> > >This line:
> > >
> > >We have SELinux disabled on all of our servers, but we hadn't disabled
> this
> > >check in sssd.conf. So we enabled it in sssd.conf and everything worked
> > >fine.
> > >
> > >Should read that we *disabled* selinux.
> > >
> > >selinux_provider = none
> > Could you also try another solution?
> > put "override_space = _" into "sssd" section in sssd.conf
> > and restart sssd.
> >
> > As a result of this space will be replaced with underscore
> > and libsemanage should not complain.
> >
> > @see man sssd.conf -> override_space
>
> This is either a bug in semenage, we should file one and ask the
> semanage developers if there is a proper way to quote the spaces.
>
> But yes, selinux_provider=none would disable this area of code.
>
> --
> 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] HBAC and AD users

[Lachlan Musicman]

Alex, Sumit,

Which log levels would you recommend for sssd to help debug this issue?

We've been using 7, but I just realised that it's not an increasing scale
but bitmasked...

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 11 July 2016 at 17:15, Sumit Bose <sb...@redhat.com> wrote:

> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > On 11 July 2016 at 16:44, Alexander Bokovoy <aboko...@redhat.com> wrote:
> >
> > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > >
> > >> Hola,
> > >>
> > >> Centos 7, up to date.
> > >>
> > >> [root@linuxidm ~]# ipa --version
> > >> VERSION: 4.2.0, API_VERSION: 2.156
> > >>
> > >> One way trust is successfully established, can login with
> > >>
> > >> ssh usern...@domain1.com@server1.domain2.com
> > >>
> > >> Am testing to get HBAC to work.
> > >>
> > >> I've noticed that with the Allow All rule in effect, the following
> set up
> > >> is sufficient:
> > >>
> > >> add external group "ad_external"
> > >> add internal group, "ad_internal", add ad_external as a group member
> of
> > >> ad_internal
> > >>
> > >> AD users can now successfully login to any server.
> > >>
> > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > >> needed to complete the extra step of adding AD users explicitly to the
> > >> "external member" group of the external group.
>
> yes, this is expected you either have to add AD users or groups to the
> external groups.
>
> > >>
> > >> I also note that this seems to be explicitly user based, not group
> based?
> > >> IE, I can add lach...@domain1.com to the external members of
> ad_external
> > >> and that works, but adding the group server_adm...@domain1.com (as
> seen
> > >> in
> > >> `id lach...@domain1.com`) doesn't allow all members access.
>
> Since it looks you are using FreeIPA 4.2 you might hit
> https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> the part where the HBAC rules are evaluated would help to understand the
> issue better.
>
> > >>
> > >> Does that sound correct?
> > >>
> > > No, it does not.
> > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > that can help understanding what happens there.
> > >
> > > What SSSD version do you have on both IPA client and IPA server?
> >
> >
> >
> > 1.13.0 on both client and server.
> >
> > To be honest, we have ratcheted up the logs and it doesn't help that
> much.
> > We just got lots of "unsupported PAM command [249]"
>
> This is unrelated, I assume this happens when trying to store the hashed
> password to the cache. This message is remove in newer releases.
>
> bye,
> Sumit
>
> >
> > Cheers
> > L.
>
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
>
-- 
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 and AD users

[Lachlan Musicman]

I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
1.14.0 release and the problem seems to have disappeared.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 10:09, Lachlan Musicman <data...@gmail.com> wrote:

> AH. I'm seeing a lot of this now.
>
> hbac_eval_user_element is returning the wrong number of groups.
>
> I just found another instance in my logs :
>
> (Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan]
>
>
> IPA server
> [root@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" |
> wc -l
> 41
>
> Host
> [root@papr-res-galaxy ~]# id simpsonlach...@petermac.org.au | tr "," "\n"
> |wc -l
> 41
>
>
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 09:45, Lachlan Musicman <data...@gmail.com> wrote:
>
>>
>> On 14 July 2016 at 17:44, Sumit Bose <sb...@redhat.com> wrote:
>>
>>> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
>>> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
>>> >
>>> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
>>> >
>>> > Installed Packages
>>> > Name: ipa-server
>>> > Arch: x86_64
>>> > Version : 4.2.0
>>> > Release : 15.0.1.el7.centos.17
>>> > Size: 5.0 M
>>> > Repo: installed
>>> > >From repo   : updates
>>> > Summary : The IPA authentication server
>>> >
>>> >
>>> > Successfully joined in one way trust to AD.
>>> >
>>> > Successfully have added hosts (Centos 7, sssd 1.13.0).
>>> >
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
>>> > 
>>> > 5 HBAC rules matched
>>> > 
>>> >
>>> >   Rule name: allow_all
>>> >   User category: all
>>> >   Host category: all
>>> >   Service category: all
>>> >   Description: Allow all users to access any host from any host
>>> >   Enabled: FALSE
>>> >
>>> > ...
>>> >
>>> >   Rule name: ssh to galaxy
>>> >   Service category: all
>>> >   Description: Allows ssh to galaxy server
>>> >   Enabled: TRUE
>>> >   User Groups: ad_users
>>> >   Hosts: papr-res-galaxy.unix.petermac.org.au
>>> >
>>> >
>>> >
>>> >
>>> > With allow_all HBAC rule enabled, can login every time with
>>> >
>>> > ssh user@ad_domain@unix_host
>>> >
>>> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
>>> >
>>> > ad_users is a POSIX group with a GID. It has one member, the group
>>> >
>>> > ad_external an external group with a single, external, member
>>> >
>>> > pmc-res-ipaus...@petermac.org.au
>>> >
>>> > which is an AD group containing all the users that should have access
>>> to
>>> > the host.
>>> >
>>> >
>>> > With allow_all disabled and "ssh to galaxy" enabled, some users can
>>> login
>>> > and some can't. There is no discernable pattern that might explain why
>>> some
>>> > are discriminated against.
>>> >
>>> > Here is the test from the server:
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbactest --user=
>>> sandsjor...@petermac.org.au
>>> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
>>> > 
>>> > Access granted: True
>>> > 
>>> >   Matched rules: ssh to galaxy
>>> >   Not matched rules: Computing Cluster
>>> >   Not matched rules: FACS Computing
>>> >
>>> > I've installed ipa-admintools on the host in question and got the same
>>> > result.
>>> >
>>> > To be on the safe side/tick all boxes, I have cleared the cache on the
>>> host
>>> > in question:
>>> >
>>> > systemctl stop sssd
>>> > sss_cache -E
>>> > systemctl start sssd
&g

Re: [Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

This line:

We have SELinux disabled on all of our servers, but we hadn't disabled this
check in sssd.conf. So we enabled it in sssd.conf and everything worked
fine.

Should read that we *disabled* selinux.

selinux_provider = none

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 11:27, Lachlan Musicman <data...@gmail.com> wrote:

> Hey,
>
> While hunting this sssd/hbac/AD user problem, I noticed in the
> selinux_child.log a lot of errors that look like this:
>
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [get_seuser]
> (0x0020): Cannot query for galaxy
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/tmp//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [set_seuser]
> (0x0020): Cannot verify the SELinux user
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
> Cannot set SELinux login context.
> (Thu Jul 14 09:40:29 2016) [[sssd[selinux_child[5446 [main] (0x0020):
> selinux_child failed!
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> selinux_child started.
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> context initialized
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0400):
> performing selinux operations
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/active//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [get_seuser]
> (0x0020): Cannot query for simpsonlach...@petermac.org.au
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/tmp//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [libsemanage]
> (0x0020): could not enter read-only section
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [set_seuser]
> (0x0020): Cannot verify the SELinux user
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
> Cannot set SELinux login context.
> (Thu Jul 14 10:21:32 2016) [[sssd[selinux_child[5504 [main] (0x0020):
> selinux_child failed!
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> selinux_child started.
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> context initialized
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [main] (0x0400):
> performing selinux operations
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): expected character ':', but found 'j'
> (/etc/selinux/targeted/modules/active//seusers.final: 10):
> ellul ja...@petermac.org.au:unconfined_u:s0-s0:c0.c1023
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not parse seuser record
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not cache file database
> (Thu Jul 14 10:37:14 2016) [[sssd[selinux_child[5585 [libsemanage]
> (0x0020): could not en

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

On 11 July 2016 at 16:44, Alexander Bokovoy <aboko...@redhat.com> wrote:

> On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>
>> Hola,
>>
>> Centos 7, up to date.
>>
>> [root@linuxidm ~]# ipa --version
>> VERSION: 4.2.0, API_VERSION: 2.156
>>
>> One way trust is successfully established, can login with
>>
>> ssh usern...@domain1.com@server1.domain2.com
>>
>> Am testing to get HBAC to work.
>>
>> I've noticed that with the Allow All rule in effect, the following set up
>> is sufficient:
>>
>> add external group "ad_external"
>> add internal group, "ad_internal", add ad_external as a group member of
>> ad_internal
>>
>> AD users can now successfully login to any server.
>>
>> When I tried to set up an HBAC, I couldn't get that set up to work, I
>> needed to complete the extra step of adding AD users explicitly to the
>> "external member" group of the external group.
>>
>> I also note that this seems to be explicitly user based, not group based?
>> IE, I can add lach...@domain1.com to the external members of ad_external
>> and that works, but adding the group server_adm...@domain1.com (as seen
>> in
>> `id lach...@domain1.com`) doesn't allow all members access.
>>
>> Does that sound correct?
>>
> No, it does not.
> HBAC evaluation and external group merging/resolution is done by SSSD.
> Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> that can help understanding what happens there.
>
> What SSSD version do you have on both IPA client and IPA server?



1.13.0 on both client and server.

To be honest, we have ratcheted up the logs and it doesn't help that much.
We just got lots of "unsupported PAM command [249]"

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

[Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Hola,

Centos 7, up to date.

[root@linuxidm ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

One way trust is successfully established, can login with

ssh usern...@domain1.com@server1.domain2.com

Am testing to get HBAC to work.

I've noticed that with the Allow All rule in effect, the following set up
is sufficient:

add external group "ad_external"
add internal group, "ad_internal", add ad_external as a group member of
ad_internal

AD users can now successfully login to any server.

When I tried to set up an HBAC, I couldn't get that set up to work, I
needed to complete the extra step of adding AD users explicitly to the
"external member" group of the external group.

I also note that this seems to be explicitly user based, not group based?
IE, I can add lach...@domain1.com to the external members of ad_external
and that works, but adding the group server_adm...@domain1.com (as seen in
`id lach...@domain1.com`) doesn't allow all members access.

Does that sound correct?

L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Unable to ssh after establishing trust

[Lachlan Musicman]

Have you set up the external group and internal group as required in IPA?

The server you are trying to log into - you have added this to the IPA
server using ipa-client-install?

When you are logged into the server that you want to login to as root (or
local user), does `id user@ad_domain.com` give you the results you expected?

(sorry to ask simple questions, but just in case)

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 11 July 2016 at 13:46, pgb205  wrote:

> I have successfully established trust and am able to obtain ticket
> granting ticket
> kinit user@AD_DOMAIN.COM
> I can also do kinit admin@IPA_DOMAIN.COM
> ssh admin@IPA_DOMAIN.COM also works
>
> however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
>
> I have checked that there are no hbac rules other then the default
> allow_all rule
>
> in sssd_ssh.log see
> permission denied (6) error
>
> in sssd_ipa.domain.log file I see
> pam_handler_callback 6 permission_denied
>
> in sssd_nss.log
> Unable to get information from Data Provider
> Error: 3 Account info lookup failed
> Will try to return what we have in cache
>
> in /var/log/secure
>  received for user user@AD_DOMAIN.COM: 6 (Permission denied)
>
> I can provided full logs if necessary to diagnose the above problem.
>
> --
> Additionally, I would like to be able to login as *user *not 
> *user@AD_DOMAIN.COM
> *
> My understanding that only thing that I have to change to make this happen
> is /etc/krb5.conf
> for line
> [libdefaults]
>  default_realm=AD_DOMAN.COM
> and then restarting ipa services.
>
> However, when I do this I get failure to restart Samba service
>
> --
> 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] AD PDC change

[Lachlan Musicman]

Can I just confirm - the IT team are about to migrate our PDC across town.

I presume that the trust relationship is with the domain, not the actual
machine itself. So our IPA server will just see the new PDC and everything
will be smooth?

No need to change any config or create a new trust?

Cheers
L.






--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] sssd stopping randomly

[Lachlan Musicman]

We are seeing SSSD in a failed state at random intervals.

Using the 1.14.0 COPR repo on Centos 7, FreeIPA 4.2

Unfortunately it's not something we want to reproduce and I'd turned the
debug logs off because of their size. I'm turning them back on one by one
as the crashes happen.

The only thing we see in the logs when it happens is:


(Mon Aug  8 09:39:44 2016) [sssd] [watchdog_handler] (0x0010): Watchdog
timer overflow, killing process!
(Mon Aug  8 09:39:44 2016) [sssd] [orderly_shutdown] (0x0010): SIGTERM:
killing children



Any ideas on what might cause this?


Cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 09:19, Jason B. Nance  wrote:

> >- User/group management in general becomes largely a command-line
> operation (such as mapping groups so they can be used in HBAC and sudo
> rules)
>
> While this is a nice-to-have, it isn't a deal breaker.
>

This definitely exists in WebUI? Unless you mean something I don't
understand.

Define groups:
Identity->User Groups (second tab)

Define user mappings:
IPA Server -> ID Views -> Default Trust View

Is that what you mean?

(aside: does FreeIPA have plans to move toward PatternFly?
http://www.patternfly.org/ )

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

Re: [Freeipa-users] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 09:51, Martin Basti <mba...@redhat.com> wrote:

>
> On 01.02.2017 23:44, Lachlan Musicman wrote:
>
>
>
> (aside: does FreeIPA have plans to move toward PatternFly?
> http://www.patternfly.org/ )
>
>
> Unless I missed something, FreeIPA 4.x already uses patternfly
>
> https://ipa.demo1.freeipa.org/ipa/ui/
> admin/Secret123
>
>
Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the
planning)

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

Re: [Freeipa-users] Is WinSync A Bad Choice?

[Lachlan Musicman]

On 2 February 2017 at 10:06, Jason B. Nance  wrote:

>
> >- User/group management in general becomes largely a command-line
>> operation (such as mapping groups so they can be used in HBAC and sudo
>> rules)
>>
>> While this is a nice-to-have, it isn't a deal breaker.
>>
>
> This definitely exists in WebUI? Unless you mean something I don't
> understand.
>
> Define groups:
> Identity->User Groups (second tab)
>
> In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users
> that are known via the trust with AD) under the "Users" tab.  There is
> limited visibility / management of external groups and membership, but
> nothing that displays a list of available users/groups in AD when
> attempting to create/modify a user/group.
>



Ah! Yes, I can't see all the AD users either. But adding a user to the ID
Views does fail on bad user names, which is not the same thing - I know -
but I only have a one way trust (from FreeIPA to AD) and the AD is managed
by the IT Overlords on Floor 6.

Bi directional trust may have different usage?


> Define user mappings:
> IPA Server -> ID Views -> Default Trust View
>
> By "mapping" I meant adding an AD group to a FreeIPA group (which can be
> used for HBAC/sudo) so that AD membership is known by IPA when applying the
> HBAC/sudo rules.  For example:
>
> ipa group-add \
>   --desc="lab.gen.zone 'Domain Admins' external map" \
>   lgz_map_domain_admins \
>   --external
> ipa group-add \
>   --desc="lab.gen.zone 'Domain Admins' POSIX" \
>   lgz_domain_admins
> ipa group-add-member \
>   lgz_map_domain_admins \
>   --external 'LAB\Domain Admins'
> ipa group-add-member \
>   lgz_domain_admins \
>   --groups lgz_map_domain_admins
>
>


Through the groups UI, you can add an external group (we use the naming
system "ad_my_group"), then add the AD group as an external member to that
group (add AD-DOMAIN\my_group). Then we add the local POSIX group
("my_group")  and make "ad_my_group" a member of that.


When you add a group in the groups, you will see the option for the group
to be POSIX, external or normal.

cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 installation on centos 7

[Lachlan Musicman]

On 4 February 2017 at 02:40, deepak dimri 
wrote:

> Thanks Rob
>
> Is there a place/link i can download the release for centos 7?
>
>
Amit,

You can get them from the vault:

http://vault.centos.org/7.2.1511/updates/x86_64/Packages/


I've still not done a comprehensive test, but the tests I have done show
sssd 1.14 working nicely (ie, as expected) with 4.4.0, *after* an upgrade
from 4.2.0.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper




> ~Amit
>
> On Fri, Feb 3, 2017 at 3:03 PM, Rob Crittenden 
> wrote:
>
>> amit bhatt wrote:
>>
>>> My QA development setup is running with IPA VERSION: 4.2.0 on centos 7
>>> and I want to install the same version in my production environment as
>>> well.  however when i am running yum install ipa-server i am getting
>>> VERSION: 4.4.0 (package ipa-server-4.4.0-14.el7.centos.4.x86_64)
>>> installed.
>>>
>>> How can i force IPA server to install 4.2.0 and not 4.4.0?
>>>
>>
>> You'd need to create your own yum repository with the older bits and
>> install from there (or push the packages onto your system and do a local
>> install).
>>
>> Note that the IPA packages are tested against the current versions of the
>> release which means that some packages may be newer and are therefore
>> untested against IPA 4.2.x. Chances are things will work fine but there are
>> no guarantees when mixing packages.
>>
>> 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
>>
>
>
> --
> 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] security, sssd, pam and web apps

[Lachlan Musicman]

Hi,

We have a new rstudio server that we'd like to have FreeIPA manage Auth on.

sssd works - I can login with my appropriate credentials via cli, but the
web interface doesn't accept the creds.

I've read http://www.freeipa.org/page/Web_App_Authentication#PAM_service
but we don't want to create a HBAC service - we aren't having much luck
with HBAC anyway (still working on that) but we also want all users to have
access to this web app.

The original /etc/pam.d/rstudio looks like:

#%PAM-1.0
auth  requisite  pam_succeed_if.so uid >= 500 quiet
auth  required   pam_unix.so nodelay

account   required   pam_unix.so


I've changed it to look like:

#%PAM-1.0
auth  required   pam_sss.so

account   required   pam_sss.so

This works - but does it create any other security issues?

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Error in selinux child: libsemanage can't parse spaces in AD user names

[Lachlan Musicman]

On 18 July 2016 at 18:26, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Mon, Jul 18, 2016 at 09:33:35AM +1000, Lachlan Musicman wrote:
> > Ok, I've just spoken with my colleague that has been involved in the IPA
> > roll out, and he said he thought that override_space wasn't compatible
> with
> > ID overrides?
>
> I haven't tested that to be honest. But just using my knowledge of the
> code as a basis, I would say the two should be compatible, especially
> with 1.14.0 where we decoupled the output from how we store users. But
> again, I haven't tested any of this.
>
> >
> > Either way, since we have a working system we are reticent to make too
> many
> > changes - soon we will have a test system in place and I will be able to
> > check it then?
>
> selinux_provider=none should be an easy workaround if you don't use the
> SELinux labels. I still have an item on my todo list to test this
> locally, I think I will get to that this week.
>


For what it's worth, we implemented the override_space=_ option.

This has failed, of course, because we had a user with an _ in their
username, and sssd went looking for test user instead of test_user, which
caused all kinds of issues.

We have gone back to selinux_provider=none

L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] sssd stops after nss crashes

[Lachlan Musicman]

We saw another sssd crash on the weekend (well, Friday night).

Centos 7, sssd 1.14.0 from COPR

Everything has worked fine for over a month until Friday.

According to the log sssd_nss on the host in question:

 - at about 16:18, watchdog_handler killed a process for a timer overflow.
 - there is some flopping about as nss/sssd tries to reconnect
 - at 16:19:12 we see this:

(Fri Sep  9 16:19:12 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
reconnecting. Deferring.

 - Which continues until 16:20:56

(Fri Sep  9 16:20:56 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
reconnecting. Deferring.

Note that there are 9,573,091 lines of this, at about 80,000 msgs per
second.

 - nss seems to stumble back to life at this point (there are no logs on
the freeipa server unfortunately)

 - at every 15 min interval we see this (I think this might be zabbix
polling sssd):

(Fri Sep  9 18:30:01 2016) [sssd[nss]] [get_client_cred] (0x0020):
SELINUX_getpeercon failed [-1][Unknown error -1].
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [accept_fd_handler] (0x0400): Client
connected!
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running
command [38][SSS_NSS_INITGR] with input [root].
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'root' matched without domain, user is root
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Requesting info for [root] from []
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [nss_cmd_initgroups_search]
(0x0400): User [r...@unix.petermac.org.au] does not exist in [
unix.petermac.org.au]! (negative cache)
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [nss_cmd_initgroups_search]
(0x0080): No matching domain found for [root], fail!
(Fri Sep  9 18:30:01 2016) [sssd[nss]] [client_recv] (0x0200): Client
disconnected!

Interspersed there is the occasional successful connection.

 - Then at 20:41 everything decides to fall over properly:

(Fri Sep  9 20:41:07 2016) [sssd[nss]] [watchdog_handler] (0x0010):
Watchdog timer overflow, killing process!
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_responder_ctx_destructor]
(0x0400): Responder is being shut down
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [confdb_get_domain_internal]
(0x0400): No enumeration for [unix.petermac.org.au]!
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_init_connection] (0x0400):
Adding connection 0x7f25be061590
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_opath_hash_add_iface]
(0x0400): Registering interface org.freedesktop.sssd.service with path
/org/freedesktop/sssd/service
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_conn_register_path] (0x0400):
Registering object path /org/freedesktop/sssd/service with D-Bus connection
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_opath_hash_add_iface]
(0x0400): Registering interface org.freedesktop.DBus.Properties with path
/org/freedesktop/sssd/service
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_opath_hash_add_iface]
(0x0400): Registering interface org.freedesktop.DBus.Introspectable with
path /org/freedesktop/sssd/service
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [monitor_common_send_id] (0x0100):
Sending ID: (nss,1)
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_names_init_from_args] (0x0100):
Using re
[(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_fqnames_init] (0x0100): Using
fq format [%1$s@%2$s].
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [check_file] (0x0400): lstat for
[/var/lib/sss/pipes/private/sbus-dp_unix.petermac.org.au] failed: [2][No
such file or directory].
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sbus_client_init] (0x0020):
check_file failed for [/var/lib/sss/pipes/private/
sbus-dp_unix.petermac.org.au].
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_dp_init] (0x0010): Failed to
connect to monitor services.
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_process_init] (0x0010): fatal
error setting up backend connector
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [sss_responder_ctx_destructor]
(0x0400): Responder is being shut down
(Fri Sep  9 20:41:07 2016) [sssd[nss]] [nss_process_init] (0x0010):
sss_process_init() failed
(Fri Sep  9 20:41:09 2016) [sssd[nss]] [server_setup] (0x0400): CONFDB:
/var/lib/sss/db/config.ldb
(Fri Sep  9 20:41:09 2016) [sssd[nss]] [confdb_get_domain_internal]
(0x0400): No enumeration for [unix.petermac.org.au]!
(Fri Sep  9 20:41:09 2016) [sssd[nss]] [sbus_init_connection] (0x0400):
Adding connection 0x7fd8ac102590
(Fri Sep  9 20:41:09 2016) [sssd[nss]] [sbus_opath_hash_add_iface]
(0x0400): Registering interface org.freedesktop.sssd.service with path
/org/freedesktop/sssd/service
(Fri Sep  9 20:41:09 2016) [sssd[nss]] [sbus_conn_register_path] (0x0400):
Registering 

Re: [Freeipa-users] sssd stops after nss crashes

[Lachlan Musicman]

SELinux is disabled, updated to 1.14.1 today.

This is the first crash in weeks, so we aren't that phased, although we'd
love to know it wont happen again - the servers are part of a cluster that
executes automated tasks as the data comes off genome sequencing machines -
clinical medical analyses that is important for the patients & etc.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 12 September 2016 at 20:28, Lukas Slebodnik <lsleb...@redhat.com> wrote:

> On (12/09/16 11:09), Lachlan Musicman wrote:
> >We saw another sssd crash on the weekend (well, Friday night).
> >
> >Centos 7, sssd 1.14.0 from COPR
> >
> Please upgrade to 1.14.1 from copr.
>
> >Everything has worked fine for over a month until Friday.
> >
> >According to the log sssd_nss on the host in question:
> >
> > - at about 16:18, watchdog_handler killed a process for a timer overflow.
> > - there is some flopping about as nss/sssd tries to reconnect
> > - at 16:19:12 we see this:
> >
> >(Fri Sep  9 16:19:12 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
> >reconnecting. Deferring.
> >
> > - Which continues until 16:20:56
> >
> >(Fri Sep  9 16:20:56 2016) [sssd[nss]] [sbus_dispatch] (0x0400): SBUS is
> >reconnecting. Deferring.
> >
> >Note that there are 9,573,091 lines of this, at about 80,000 msgs per
> >second.
> >
> > - nss seems to stumble back to life at this point (there are no logs on
> >the freeipa server unfortunately)
> >
> > - at every 15 min interval we see this (I think this might be zabbix
> >polling sssd):
> >
> >(Fri Sep  9 18:30:01 2016) [sssd[nss]] [get_client_cred] (0x0020):
> >SELINUX_getpeercon failed [-1][Unknown error -1].
> What is a state of SELinux on your machine?
> Please share output of "sestatus"
>
> LS
>
-- 
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 doesn't work issues

[Lachlan Musicman]

I must have made an error again:

- ipa hbactest gives seemingly correct answer on both server and client
- user can't actually use sudo on client?

Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR

>From the server:

[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo

Access granted: True

  Matched rules: Cluster Admin Users (sudo)
  Not matched rules: Cluster Users
[root@vmdv-linuxidm1 ~]#


>From the host in question:

[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
--host `hostname` --service sudo

Access granted: True

  Matched rules: Cluster Admin Users (sudo)
  Not matched rules: Cluster Users
[root@vmts-linuxclient1 ~]#


[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
[sudo] password for lsimp...@petermac.org.au:
lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
This incident will be reported.


On the client, in the sssd_sudo.log I can see (debug_level=6) a number of
lines, most notably three that start "Searching sysdb with" and then follow
with all my ipa and AD groups - both groups that would give me HBAC sudo
are listed in those log entries.

What should I try next?

cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] In webgui, ID Views slow, to crashingly slow

[Lachlan Musicman]

Hi

Sometimes when I visit the ID Views page in the webgui, it is crushingly
slow, and often it times out.

Centos 7, ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

Is there a reason, can I do something to fix this?

cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] sssd.conf - the server and host-client relationship

[Lachlan Musicman]

Hola,

What is the relationship between the IPA server, host-clients and the
sssd.conf?

>From what I can tell, sssd.conf is edited/changed by the ipa-client-install
process on the host-client.

What level of similarity does there need to be between the two sssd.confs?

My server's sssd.conf has a significant number of extra parameters set that
are not getting put onto the clients.

Debug levels are the most obvious, and understandable, omissions - but some
others are frustrating.

The (non debug_level) parameters missing are:
--
[domain/unixdev.etc]
ignore_group_members = True
ldap_purge_cache_timeout = 0
subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
selinux_provider = none
ipa_server_mode = True
sudo_provider = ldap
ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au

[sssd]
config_file_version = 2
domains = unixdev.etc

[nss]
memcache_timeout = 600
--

The other diff is that the

host has: ipa_server = vmdv-linuxidm1.unixdev.petermac.org.au
client has: ipa_server = _srv_, vmdv-linuxidm1.unixdev.petermac.org.au

Which I presume is expected/desired.

And the reason I ask is because we have selinux disabled, and without the
"selinux_provider = none" line, we would get kicked out as soon as freeipa
had logged us in with message:

Connection to test_client.unixdev.petermac.org.au closed by remote host.

and on that host-client there was a brand new selinux_child.log that I'd
never seen before.


cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] In webgui, ID Views slow, to crashingly slow

[Lachlan Musicman]

I concede - FreeIPA is big and hard and I am new. Evidence would suggest
that you know exactly what's going on under the hood. :)

Thanks everyone.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 18:10, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Tue, 20 Sep 2016, Sumit Bose wrote:
>
>> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
>>
>>> On Tue, 20 Sep 2016, Martin Babinsky wrote:
>>> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
>>> > > > -Original Message-
>>> > > >
>>> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
>>> > > > > Hi
>>> > > > >
>>> > > > > Sometimes when I visit the ID Views page in the webgui, it is
>>> > > > > crushingly slow, and often it times out.
>>> > > > >
>>> > > > > Centos 7, ipa --version
>>> > > > > VERSION: 4.2.0, API_VERSION: 2.156
>>> > > > >
>>> > > > > Is there a reason, can I do something to fix this?
>>> > > > >
>>> > > >
>>> > > > What kind of ID Views do you use? Do you use them to  override AD
>>> users?
>>> > > > Is there any useful info in '/var/log/httpd/error_log'?
>>> > >
>>> > > There is the single ID View Name, Default Trust View, and in that we
>>> have a number of users over riding the AD usernames and home dirs.
>>> > >
>>> > > The httpd error log is relatively large, tbh, but there's nothing in
>>> there that looks like an obvious reason. In fact, for an error log, there
>>> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the
>>> error log is jsonserver_session...
>>> > >
>>> > > Next time I see it (I only see it intermittently), I'll grab the
>>> logs and have a look.
>>> > >
>>> > > Cheers
>>> > > L.
>>> > >
>>> > >
>>> > >
>>> > > This email (including any attachments or links) may contain
>>> > > confidential and/or legally privileged information and is
>>> > > intended only to be read or used by the addressee.  If you
>>> > > are not the intended addressee, any use, distribution,
>>> > > disclosure or copying of this email is strictly
>>> > > prohibited.
>>> > > Confidentiality and legal privilege attached to this email
>>> > > (including any attachments) are not waived or lost by
>>> > > reason of its mistaken delivery to you.
>>> > > If you have received this email in error, please delete it
>>> > > and notify us immediately by telephone or email.  Peter
>>> > > MacCallum Cancer Centre provides no guarantee that this
>>> > > transmission is free of virus or that it has not been
>>> > > intercepted or altered and will not be liable for any delay
>>> > > in its receipt.
>>> > >
>>> >
>>> > One thing that crossed my mind is to check the connectivity to the AD
>>> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
>>> > contact AD DCs to do the username -> SID translation. If there is some
>>> > problem contacting them, then there may be hangs/timeouts when
>>> resolving
>>> > override anchors.
>>> Internally IPA framework attempts to resolve ID override anchors. We can
>>> actually optimize this code as ipaOriginalUID attribute contains
>>> normalized name already, written their when the override is created and
>>> never changed afterwards. This should speed up the resolution of large
>>> overrides.
>>>
>>> Martin, can you file a ticket for that? The code in question is
>>> baseidoverride.convert_anchor_to_human_readable_form() which could
>>> benefit from passing in entry_attrs and checking ipaoriginaluid there.
>>> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
>>> done now.
>>>
>>
>> As an alternative I wonder if the WebUI can be made asynchronous in the
>> sense that it displays the raw data (the SID in this case) first and run
>> the lookups in the background and replace the SID when the name is
>> available. I've seen some Windows tools behaving this when looking up
>> large numbers of SIDs.
>>
> We have that for external group members already.
>
> However, in the ID overrides there is no SID as it is. The RDN of the ID
> override is 'ipaAnchorUUID' attribute which is an encoding of a target
> reference. We don't need to resolve it because we already have it
> resolved in 'ipaOriginalUid' attribute -- this was done to help Schema
> Compatibility and SASL mapping plugins which cannot resolve
> ipaAnchorUUID value. We just need to make its use consistent across the
> IPA framework.
>
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] In webgui, ID Views slow, to crashingly slow

[Lachlan Musicman]

I've actually seen that on occasion - when it's loading sometimes that
happens already?

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 17:49, Sumit Bose <sb...@redhat.com> wrote:

> On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
> > On Tue, 20 Sep 2016, Martin Babinsky wrote:
> > > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > > > -Original Message-
> > > > >
> > > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > > > Hi
> > > > > >
> > > > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > > > crushingly slow, and often it times out.
> > > > > >
> > > > > > Centos 7, ipa --version
> > > > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > > > >
> > > > > > Is there a reason, can I do something to fix this?
> > > > > >
> > > > >
> > > > > What kind of ID Views do you use? Do you use them to  override AD
> users?
> > > > > Is there any useful info in '/var/log/httpd/error_log'?
> > > >
> > > > There is the single ID View Name, Default Trust View, and in that we
> have a number of users over riding the AD usernames and home dirs.
> > > >
> > > > The httpd error log is relatively large, tbh, but there's nothing in
> there that looks like an obvious reason. In fact, for an error log, there
> is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the
> error log is jsonserver_session...
> > > >
> > > > Next time I see it (I only see it intermittently), I'll grab the
> logs and have a look.
> > > >
> > > > Cheers
> > > > L.
> > > >
> > > >
> > > >
> > > > This email (including any attachments or links) may contain
> > > > confidential and/or legally privileged information and is
> > > > intended only to be read or used by the addressee.  If you
> > > > are not the intended addressee, any use, distribution,
> > > > disclosure or copying of this email is strictly
> > > > prohibited.
> > > > Confidentiality and legal privilege attached to this email
> > > > (including any attachments) are not waived or lost by
> > > > reason of its mistaken delivery to you.
> > > > If you have received this email in error, please delete it
> > > > and notify us immediately by telephone or email.  Peter
> > > > MacCallum Cancer Centre provides no guarantee that this
> > > > transmission is free of virus or that it has not been
> > > > intercepted or altered and will not be liable for any delay
> > > > in its receipt.
> > > >
> > >
> > > One thing that crossed my mind is to check the connectivity to the AD
> > > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> > > contact AD DCs to do the username -> SID translation. If there is some
> > > problem contacting them, then there may be hangs/timeouts when
> resolving
> > > override anchors.
> > Internally IPA framework attempts to resolve ID override anchors. We can
> > actually optimize this code as ipaOriginalUID attribute contains
> > normalized name already, written their when the override is created and
> > never changed afterwards. This should speed up the resolution of large
> > overrides.
> >
> > Martin, can you file a ticket for that? The code in question is
> > baseidoverride.convert_anchor_to_human_readable_form() which could
> > benefit from passing in entry_attrs and checking ipaoriginaluid there.
> > If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
> > done now.
>
> As an alternative I wonder if the WebUI can be made asynchronous in the
> sense that it displays the raw data (the SID in this case) first and run
> the lookups in the background and replace the SID when the name is
> available. I've seen some Windows tools behaving this when looking up
> large numbers of SIDs.
>
> bye,
> Sumit
>
> >
> > --
> > / Alexander Bokovoy
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
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] sssd.conf - the server and host-client relationship

[Lachlan Musicman]

My translations of your comments are in line, if you could correct, I'd
appreciate that.

On 20 September 2016 at 17:11, Lukas Slebodnik  wrote:

> >--
> >[domain/unixdev.etc]
> >ignore_group_members = True
> It was probably set as a result of performance tuning.
>
> >ldap_purge_cache_timeout = 0
> That's default since 1.13.0
>
> >subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
> that's specific option for sssd on IPA server
>


I presume your comment suggests ignore_group_members is no longer needed,
and since the lpct=0 is now default, then subdomain_inherit is also
superfluous?



> >selinux_provider = none
> It was probably set as a workaround of bug which have been already
> fixed.
>

We set this because of an error in libsemanage, but I think that was an
upstream (selinux) issue?
https://www.redhat.com/archives/freeipa-users/2016-July/msg00244.html

Not sure if I should disable just yet - was this fixed?


>
> >ipa_server_mode = True
> that's specific option for sssd on IPA server
>
>
I take it that this means it's still used.



> >sudo_provider = ldap
> >ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
> >ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
> >ldap_sasl_mech = GSSAPI
> >ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
> >ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
> >krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au
> Previous 7 options are not required since sssd-1.10
>

Yep, I added those because of disconnect between the different info sources
made it hard to tell what was canonical, so I followed the red hat guide:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html

mostly because I didn't quite understand the sssd-sudo man page (because
sometimes I find man pages obtuse), but also there was an inconsistency
with the local man page and the die.net mirror
https://linux.die.net/man/5/sssd-sudo and this howto
https://blog-rcritten.rhcloud.com/?p=52


> >
> >[sssd]
> >config_file_version = 2
> >domains = unixdev.etc
> >
> >[nss]
> >memcache_timeout = 600
> This option is se by ipa-*-install on ipa server mode.
>

These I will leave.

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

Re: [Freeipa-users] HBAC doesn't work issues

[Lachlan Musicman]

We have one "allow all" sudo rule (anyone, any host, any command).

Matching Defaults entries for root on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User root may run the following commands on this host:
(ALL) ALL


My sssd.conf has:

[domain/unixdev.etc]
...
sudo_provider = ldap
ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = unixdev.petermac.org.au
debug_level = 6

[sudo]
debug_level = 6

but only on the server - does that need to filter down to each client? The
client side sssd.confs seem to be auto created when ipa-client-install is
run, and are stripped down...

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 September 2016 at 18:21, Lukas Slebodnik <lsleb...@redhat.com> wrote:

> On (19/09/16 16:43), Lachlan Musicman wrote:
> >I must have made an error again:
> >
> >- ipa hbactest gives seemingly correct answer on both server and client
> >- user can't actually use sudo on client?
> >
> >Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
> >
> >>From the server:
> >
> >[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
> >--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
> >
> >Access granted: True
> >
> >  Matched rules: Cluster Admin Users (sudo)
> >  Not matched rules: Cluster Users
> >[root@vmdv-linuxidm1 ~]#
> >
> >
> >>From the host in question:
> >
> >[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
> >--host `hostname` --service sudo
> >
> >Access granted: True
> >
> >  Matched rules: Cluster Admin Users (sudo)
> >  Not matched rules: Cluster Users
> >[root@vmts-linuxclient1 ~]#
> >
> >
> >[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
> >[sudo] password for lsimp...@petermac.org.au:
> >lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
> >This incident will be reported.
> >
> Did you configure sudo rules for such user?
> What is an output of "sudo -l"
>
> LS
>
-- 
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 doesn't work issues

[Lachlan Musicman]

(redface)

It seems to be working.

Thanks


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 09:57, Lachlan Musicman <data...@gmail.com> wrote:

> We have one "allow all" sudo rule (anyone, any host, any command).
>
> Matching Defaults entries for root on this host:
> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
> DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
> LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>
> User root may run the following commands on this host:
> (ALL) ALL
>
>
> My sssd.conf has:
>
> [domain/unixdev.etc]
> ...
> sudo_provider = ldap
> ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
> ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
> ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
> krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au
>
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> domains = unixdev.petermac.org.au
> debug_level = 6
>
> [sudo]
> debug_level = 6
>
> but only on the server - does that need to filter down to each client? The
> client side sssd.confs seem to be auto created when ipa-client-install is
> run, and are stripped down...
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 19 September 2016 at 18:21, Lukas Slebodnik <lsleb...@redhat.com>
> wrote:
>
>> On (19/09/16 16:43), Lachlan Musicman wrote:
>> >I must have made an error again:
>> >
>> >- ipa hbactest gives seemingly correct answer on both server and client
>> >- user can't actually use sudo on client?
>> >
>> >Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
>> >
>> >>From the server:
>> >
>> >[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
>> >--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
>> >
>> >Access granted: True
>> >
>> >  Matched rules: Cluster Admin Users (sudo)
>> >  Not matched rules: Cluster Users
>> >[root@vmdv-linuxidm1 ~]#
>> >
>> >
>> >>From the host in question:
>> >
>> >[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
>> >--host `hostname` --service sudo
>> >
>> >Access granted: True
>> >
>> >  Matched rules: Cluster Admin Users (sudo)
>> >  Not matched rules: Cluster Users
>> >[root@vmts-linuxclient1 ~]#
>> >
>> >
>> >[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
>> >[sudo] password for lsimp...@petermac.org.au:
>> >lsimp...@petermac.org.au is not allowed to run sudo on
>> vmts-linuxclient1.
>> >This incident will be reported.
>> >
>> Did you configure sudo rules for such user?
>> What is an output of "sudo -l"
>>
>> LS
>>
>
>
-- 
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] sssd 1.14.1, HBAC still not working?

[Lachlan Musicman]

Hola,

I've set up a test domain that's as much as possible the same as the prod
domain, and successfully got a one way trust against the AD: cantos 7.2,
ipa 4.2.0-15/api2.156, sssd (copr) 1.14.1-3

On that test domain I believe I have HBAC working successfully.

Once I could show that it was working successfully on the test domain we
updated all the clients in the prod domain to sssd 1.14.1-3, updated the
IPA server, ran ipa-server-upgrade and we disabled "allow all" in the HBAC.

And it doesn't work? Two users could login, but none of the others could,
and the sudo rules weren't applied in so much as the one user that could
login but shouldn't have had sudo, did.

I tried stopping sssd/clearing cache/start sssd/waiting; and stopping
sssd/deleting /var/lib/sss/db/* /start sssd/waiting.

Neither of those worked, so I enabled allow all again.

Now I have a bunch of log files to look through, but no clear indication of
what might have gone wrong from a quick read.

I can see in the logs where one person is ok'd by HBAC for sshd and another
two are denied - when they should have all been ok'd. And I can infer that
the reasoning is that HBAC has declared person2 + person3 to not be in a
group they most definitely are in from the error messages. But there is no
indication of why sssd hasn't properly picked up that person2 is in the
correct group?

I guess the question is, where do I start fixing this? Which logs should I
be reading?

What can I compare between the two set ups (dev and prod) that might give
me insight, given that they are largely set up identically?

Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Shadow Utils appears in sssd.conf

[Lachlan Musicman]

Great - thank you. That worked.

Unfortunately SELinux creates too much overhead on a subset of our servers,
so we have it disabled.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 16 November 2016 at 19:39, Lukas Slebodnik <lsleb...@redhat.com> wrote:

> On (16/11/16 11:46), Lachlan Musicman wrote:
> >I don't know what I've done wrong, but when I use ipa-client-install on a
> >new host to add to my one way trust domain, I now have a
> >[domain/shadowutils] stanza.
> >
> >This first happened a couple of weeks ago, I saw this bug and thought "it
> >will be solved soon".
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1369118
> >
> >The report says it's been resolved in a recent advisory but I'm still
> >seeing the error.
> >
> It was fixed by reverting upstream commit which
> introduced such seature.
> https://git.fedorahosted.org/cgit/sssd.git/commit/?id=
> 59744cff6edb106ae799b2321cb8731edadf409a
>
> >Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally
> >supplied sssd?
> >
> Yes, theis feature is still available in upstream/fedora.
>
> A) "domain/shadowutils" should not cause any problems.
>If yes then it should be also reproducible on fedora
>please filae a bug.
>
> B) It does not happen with SELinux in enforcing mode.
>Another reason for "setenforce 1" :-)
>
> LS
>
-- 
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] anyone else getting porn spam pretending to be replies to freeipa-users threads?

[Lachlan Musicman]

Gah, just happened to me. Wasn't porn, but was someone called Kimi and the
only content was "Heeey Lachlan, how's it going?"

L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 16 November 2016 at 04:02, Martin Basti  wrote:

>
>
> On 15.11.2016 17:32, Chris Dagdigian wrote:
>
>>
>>
>> Got a porn spam today that had a subject header of:
>>
>> Re: [Freeipa-users] URL is changing on the browser
>>>
>>
>> Have to admit that got through my spam filter and got me to open the
>> email.
>>
>> It's clear that it was not a list message; looks like something may be
>> mining the public list archives to pull email addresses and plausible
>> sounding subject lines.
>>
>> Mildly interested if anyone else got an email like this?
>>
>> -Chris
>>
>>
>>  We are receiving those emails as well (different subjects, domains, but
> the same content)
>
>
> --
> 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] Shadow Utils appears in sssd.conf

[Lachlan Musicman]

I don't know what I've done wrong, but when I use ipa-client-install on a
new host to add to my one way trust domain, I now have a
[domain/shadowutils] stanza.

This first happened a couple of weeks ago, I saw this bug and thought "it
will be solved soon".

https://bugzilla.redhat.com/show_bug.cgi?id=1369118

The report says it's been resolved in a recent advisory but I'm still
seeing the error.

Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally
supplied sssd?

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] packet_write_wait: Connection to x.x.x.x port 22: Broken pipe

[Lachlan Musicman]

Hola,

I'm getting the above error when trying to login - inconsistently and after
the password request.

Using debian's openssh 7.3p1-3 going into Centos 7.2, FreeIPA 4.2 and sssd
1.14.2 (from copr).

When I google, none of the results seem applicable, but I'm not 100% sure,
and testing seems difficult.

On the test client, I've set pam_id_timeout and kr5b_auth_timeout to 30
because we found that helped with the transfer of data between the FreeIPA
server and the enrolled host, and I thought that might be causing the error.

Having added both ServerAliveInterval 60 and ClientAliveInterval 60 just to
humour myself (and the google results) but am still getting this result.
This is a solution I'd rather not implement anyway, but I thought I'd check.

Has anyone seen this before?

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 Troubleshooting (IPA 4.2)

[Lachlan Musicman]

Jake,

I've seen this behaviour and am still struggling to find a solution.

The version of underlying OS and sssd are useful to know fwiw.

To trouble shoot HBAC:

 - in *target machine* sssd.conf, add debug_level=7 to each stanza (can go
as high as 9, but I believe 7 will be sufficient)
 - restart sssd
 - clear logs in /var/log/sssd/ either by deleting or by logrotate
 - make an attempt to login/perform allowed action that gets denied
 - read logs to see what happened
 - I like to run `ipa hbactest --user= --host= --service` on the IPA node
to confirm that the HBAC rules are correct
 - I sometimes also install ipa-tools on the target host and confirm that
the above command gives same and correct answer
 - note that successful results from this command may not translate to
successful application of HBAC on the target host in reality.



cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 2 November 2016 at 09:41, Jake  wrote:

> Hey All,
> I'm having some issues tracing HBAC policies, it seems whenever I disable
> the allow_all policy, I'm no longer able to access services I have allowed
> in my more-specific hbac policy.
>
> What are the troubleshooting steps (logs) I can run on the client to see
> what is being denied and by what policy, Is this all done with sssd?
>
> Thank You,
> -Jake
>
>
> --
> 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] External (AD) groups and sudo/hbac in IPA 4.2

[Lachlan Musicman]

On 12 October 2016 at 15:23, Robert Sturrock  wrote:

> Hi All.
>
> We’re attempting to setup an IPA (4.2) service on RHEL7.2 to provide
> better connectivity to our (large) organisational AD service for Linux
> clients.
>
> We have setup IPA and configured a suitable AD trust (with SID POSIX
> mapping) in the hope that users will be able to access IPA resources
> (hosts, storage) using existing AD credentials and groups.  This working
> fine - we can login to Linux hosts using AD credentials and see the AD
> groups.
>
> However, it would appear that in order to use AD group membership as the
> basis for Linux HBAC or sudo, we need to firstly _map_ the AD groups to an
> equivalent IPA (POSIX) group?  Is this correct?
>
> I can see that it’s possible to define ‘external’ *users* (not groups) in
> some cases, but this function appears to be deprecated.
>
> We have large numbers of groups in our AD (~50k), so obviously that’s a
> lot of mapping!
>
>

Hi Rob,

It should work with groups no problems. We found a few issues with sssd
<1.14. To get the up to date sssd for the hosts, the best bet is the COPR
repos

https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/

As for groups working with HBAC, it should work no problems. Yes to mapping
though. Here is the process:

1. Create an external group for your AD users/groups
2. Add AD group name to that external group (this AD group's existence will
be confirmed by IPA->AD trust or command will fail)
3. Create POSIX group
4. add group created in step 1 to group created in step 3

And here are some example commands to do that, as we executed them here, in
the same order:

ipa group-add --desc="petermac.org.au external map" ad_users_external
--external
ipa group-add-member ad_external --external 'PMCI\Bioinf-Cluster'
ipa group-add --desc="petermac.org.au AD users" ad_users
ipa group-add-member ad_users --groups ad_users_external

Let me know how you go

L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] sssd 1.14.1, HBAC still not working?

[Lachlan Musicman]

After further testing, I've discovered that the dev system wasn't working
as well as I thought it was: HBAC and sshd don't seem to be playing well
together on one server, but fine on the other?

ie, I can run the same commands from both ipa-server and ipa-client:

ipa hbactest  --user=user1 --host=ipa-server.unixdev.petermac.org.au
--service=sshd
ipa hbactest  --user=user1 --host=ipa-client.unixdev.petermac.org.au
--service=sshd


and every response is:

to the ipa-client

Access granted: True

  Matched rules: Admin Users (w sudo)
  Matched rules: Users

to the ipa-server

Access granted: True

  Matched rules: Cluster Admin Users (sudo)
  Not matched rules: Cluster Users


but when I try to login to the ipa-server, I get an instance disconnect? I
can login happily to the ipa-client no problems.

Is there a special rule about sshd and the ipa-server?

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 11 October 2016 at 14:06, Lachlan Musicman <data...@gmail.com> wrote:

> Hola,
>
> I've set up a test domain that's as much as possible the same as the prod
> domain, and successfully got a one way trust against the AD: cantos 7.2,
> ipa 4.2.0-15/api2.156, sssd (copr) 1.14.1-3
>
> On that test domain I believe I have HBAC working successfully.
>
> Once I could show that it was working successfully on the test domain we
> updated all the clients in the prod domain to sssd 1.14.1-3, updated the
> IPA server, ran ipa-server-upgrade and we disabled "allow all" in the HBAC.
>
> And it doesn't work? Two users could login, but none of the others could,
> and the sudo rules weren't applied in so much as the one user that could
> login but shouldn't have had sudo, did.
>
> I tried stopping sssd/clearing cache/start sssd/waiting; and stopping
> sssd/deleting /var/lib/sss/db/* /start sssd/waiting.
>
> Neither of those worked, so I enabled allow all again.
>
> Now I have a bunch of log files to look through, but no clear indication
> of what might have gone wrong from a quick read.
>
> I can see in the logs where one person is ok'd by HBAC for sshd and
> another two are denied - when they should have all been ok'd. And I can
> infer that the reasoning is that HBAC has declared person2 + person3 to not
> be in a group they most definitely are in from the error messages. But
> there is no indication of why sssd hasn't properly picked up that person2
> is in the correct group?
>
> I guess the question is, where do I start fixing this? Which logs should I
> be reading?
>
> What can I compare between the two set ups (dev and prod) that might give
> me insight, given that they are largely set up identically?
>
> Cheers
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
-- 
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] Errors in IPA logs

[Lachlan Musicman]

Hi,

I've reported a bug against SSSD and Lukas has pointed to a number of
FreeIPA errors in our logs.
I've can't find any information on how I might fix these errors or what I
might do to mitigate them. Any pointers appreciated:

First error:

[sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040):
Received 1 sudo rules

[sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080):
ldb_modify failed: [No such attribute](16)[attribute 'member': no matching
attribute value while deleting attribute on 'name=
ipa_bioinf_st...@unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb']


[sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB
returned unexpected error: [No such attribute]

[sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020): Could
not remove member [simpsonlach...@domain.org.au] from group [name=
ipa_bioinf_st...@unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb].
Skipping



Second error is long list of errors that look like


[sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component,
got OU

[sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component,
got Users


I don't know enough about AD to speak meaningfully to these, but a quick
google shows that a group can have cn=Users as it's second component ( see
here for example
https://technet.microsoft.com/en-us/library/dn579255%28v=ws.11%29.aspx )

Is there an LDAP query that I need to define or add to the IPA server?

cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Adjusting nsslapd-cachememsize

[Lachlan Musicman]

Directly editing the lse.ldif didn't work. ipactl start hangs on
pki-tomcatd. I think I've broken it. I seem to recall ldap not liking being
edited by hand.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 17 March 2017 at 19:45, Bob Hinton <b...@rha-ltd.co.uk> wrote:

> Hi Lachlan,
>
> This is probably a complete hack, but the way I've changed
> nsslapd-cachememsize in the past is -
>
> On each ipa replica in turn -
>
>1. ipactl stop
>2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif- (where DOMAIN is your
>server's domain/realm - not sure which) find and change the value of
>nsslapd-cachememsize
>3. ipactl start
>
> This seemed to work in that it made the error messages go away and it made
> heavily loaded servers more stable. However, I've not tried this on a
> recent version of ipa so it may no longer work or not be needed any more.
>
> Regards
>
> Bob
>
> On 17/03/2017 02:20, Lachlan Musicman wrote:
>
> While going through the logs on the FreeIPA server, I noticed this:
>
>
> WARNING: changelog: entry cache size 2097152 B is less than db size
> 12804096 B; We recommend to increase the entry cache size
> nsslapd-cachememsize.
>
>
> I have found a number of documents:
>
> What it is: https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.0/html/Configuration_and_Command_
> Reference/Configuration_Command_File_Reference-Database_Attributes_under_
> cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_
> database_cnplugins_cnconfig-nsslapd_cachememsize.html
>
> How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.1/html/Administration_Guide/memoryusage.html
>
>
> etc etc.
>
> I have no idea of what the secret password is for the "cn=directory
> manager" and can't find any information about where I might find it or
> where or when it might have been set anywhere. I have found a number of
> likely candidates, but none have worked.
>
> I found this page:
>
> https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
>
> but I'd prefer to not change the password if possible.
>
> cheers
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
>
>
>
-- 
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 not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

Yes. What I do would you like? Current debug levels are at 8

L.

On 16 Mar. 2017 7:06 pm, "Jakub Hrozek" <jhro...@redhat.com> wrote:

> On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote:
> > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not
> sure
> > if better to report to here or sssd mailing list. Also sssd in pagure is
> > bare and I didn't want to sully the blank slate.  (
> > https://pagure.io/sssd/issues )
> >
> > The details:
> >
> > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR
> >
> > On the IPA server:
> >
> > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly.
> >
> >
> > When I try to login to the test client, I get denied.
> >
> > On the test client:
> >
> >  - hbac_eval_user_element is returning a wrong value. This is seen in
> > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
> > seen on the IPA server via id username. On the test client id username
> > returns 36 groups, the one missing is an IPA (not AD) group that was made
> > for HBAC rules. I have sanitized logs available.
> >
> >  -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
> > '(objectclass=user)' and finding the record in question shows the same 36
> > groups available. The missing group shouldn't affect ability to login via
> > HBAC
> >
> >  - getent group (groupname) works as expected. Also worth noting that the
> > group missing from id username shows that user in getent.
> >
> > For reference, on the client the sssd service was stopped, the cache
> > deleted, and the service started again the night before after which the
> > server wasn't accessed by anyone. I find that this is necessary for the
> > cache to populate.
> >
> > Should I put in a bug report against SSSD or FreeIPA?
> >
> > While HBAC is in FreeIPA, I think that this is an issue in SSSD
> > (specifically ?
>
> Yes, SSSD.
>
> I remember you had some intermittent issues in the past, is this one
> reproducable?
>
> --
> 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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure
if better to report to here or sssd mailing list. Also sssd in pagure is
bare and I didn't want to sully the blank slate.  (
https://pagure.io/sssd/issues )

The details:

env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR

On the IPA server:

- "ipa hbactest ..." returns TRUE, so everything seems set up correctly.


When I try to login to the test client, I get denied.

On the test client:

 - hbac_eval_user_element is returning a wrong value. This is seen in
sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
seen on the IPA server via id username. On the test client id username
returns 36 groups, the one missing is an IPA (not AD) group that was made
for HBAC rules. I have sanitized logs available.

 -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
'(objectclass=user)' and finding the record in question shows the same 36
groups available. The missing group shouldn't affect ability to login via
HBAC

 - getent group (groupname) works as expected. Also worth noting that the
group missing from id username shows that user in getent.

For reference, on the client the sssd service was stopped, the cache
deleted, and the service started again the night before after which the
server wasn't accessed by anyone. I find that this is necessary for the
cache to populate.

Should I put in a bug report against SSSD or FreeIPA?

While HBAC is in FreeIPA, I think that this is an issue in SSSD
(specifically ?


cheers
L.




--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Errors in IPA logs

[Lachlan Musicman]

On 20 March 2017 at 19:38, Martin Basti <mba...@redhat.com> wrote:

> On 19.03.2017 22:58, Lachlan Musicman wrote:
>
> Hi,
>
> I've reported a bug against SSSD and Lukas has pointed to a number of
> FreeIPA errors in our logs.
> I've can't find any information on how I might fix these errors or what I
> might do to mitigate them. Any pointers appreciated:
>
> First error:
>
> [sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040):
> Received 1 sudo rules
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080):
> ldb_modify failed: [No such attribute](16)[attribute 'member': no matching
> attribute value while deleting attribute on 'name=ipa_bioinf_staff@
> unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb']
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB
> returned unexpected error: [No such attribute]
>
> [sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020):
> Could not remove member [simpsonlach...@domain.org.au] from group [name=
> ipa_bioinf_st...@unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb].
> Skipping
>
>
>
> Second error is long list of errors that look like
>
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component,
> got OU
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component,
> got Users
>
>
> I don't know enough about AD to speak meaningfully to these, but a quick
> google shows that a group can have cn=Users as it's second component ( see
> here for example https://technet.microsoft.com/
> en-us/library/dn579255%28v=ws.11%29.aspx )
>
> Is there an LDAP query that I need to define or add to the IPA server?
>
> cheers
> L.
>
>
> Hello,
>
> can you describe your deployment more? Your DNs doesn't look like created
> by FreeIPA
> This is not how FreeIPA's DIT looks 'name=ipa_bioinf_staff@
> unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb'
>


DNS isn't done by FreeIPA - it's all in AD. With a one way trust and all
users and groups managed by AD - except for overrides and external groups
for HBAC - everything is in AD.

As for the FreeIPA DIT - that is a group created in FreeIPA (through the
GUI iirc). I haven't done anything particularly special to make it look
like that (with the domain inside the cn). Unless it's a strange confluence
of configurations that has created a situation that would make that happen.

cheers
L.

So, wrt to your question, what can I give you/what were you after?
-- 
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] Adjusting nsslapd-cachememsize

[Lachlan Musicman]

While going through the logs on the FreeIPA server, I noticed this:


WARNING: changelog: entry cache size 2097152 B is less than db size
12804096 B; We recommend to increase the entry cache size
nsslapd-cachememsize.


I have found a number of documents:

What it is:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html

How to tune it:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html


etc etc.

I have no idea of what the secret password is for the "cn=directory
manager" and can't find any information about where I might find it or
where or when it might have been set anywhere. I have found a number of
likely candidates, but none have worked.

I found this page:

https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

but I'd prefer to not change the password if possible.

cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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 not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

Which logs do you want from the server?

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 16 March 2017 at 20:09, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote:
> > Yes. What I do would you like? Current debug levels are at 8
>
> Logs and id output from the server and the client at the same time..
>
-- 
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] Upgrade from IPA 4.2

[Lachlan Musicman]

On 4 April 2017 at 04:28, Andrey Ptashnik  wrote:

> Hello,
>
> We have Centos 7.2 and IPA 4.2 version.
> I remember that in previous versions in order to upgrade to the latest one
> I had to run IPA upgrade scripts that would separately upgrade LDAP
> database. Is that the same procedure if I need to upgrade from version 4.2?
>
>

Andrey,

That wasn't my experience. We just did a yum update and it all seemed to
work.

Given it's role, I presume you have or can set up a test env you can try it
on?

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] libsemanage updates fail due to AD user with space

[Lachlan Musicman]

On 3 April 2017 at 19:11, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Mon, Apr 03, 2017 at 11:00:21AM +1000, Lachlan Musicman wrote:
> >
> > With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces
> in
> > their names, libsemanage fails to update:
> >
> > eg from recent monthly upgrade cycle:
> >
> > Updating   :
> > selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
> > 3/14
> > libsemanage.parse_assert_ch: expected character ':', but found 'f'
> > (/etc/selinux/targeted/tmp/seusers.local: 5):
> > lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file
> or
> > directory).
> > libsemanage.seuser_parse: could not parse seuser record (No such file or
> > directory).
> > libsemanage.dbase_file_cache: could not cache file database (No such file
> > or directory).
> > libsemanage.semanage_base_merge_components: could not merge local
> > modifications into policy (No such file or directory).
> >
>
> Hi,
> according to my quick testing this is solved with this PR:
> https://github.com/SSSD/sssd/pull/189
> (Please note that we haven't ran all regression tests on this PR so I
> can't in fact tell if it's correct or not. The code does look OK,
> though).
>
> I was also able to work around the issue by setting:
> override_space = _
> in sssd.conf
>


Thanks Jakub. The problem with the override_space = _ is that we also have
users with _ in their names. I understand that this could be any character,
but we decided that - given what we know about our AD - any character could
also be in a user name.

Looking forward to seeing the patch in upcoming releases.

Cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] subdomain errors

[Lachlan Musicman]

On 4 April 2017 at 01:35, Alexander Bokovoy  wrote:

> On ma, 03 huhti 2017, Orion Poplawski wrote:
>
>> On 04/03/2017 09:03 AM, Orion Poplawski wrote:
>>
>>> On 04/03/2017 02:08 AM, Jakub Hrozek wrote:
>>>
 On Fri, Mar 31, 2017 at 05:08:13PM -0600, Orion Poplawski wrote:

>>>
>>> I'm seeing:
>>
>> [03/Apr/2017:09:07:34.269247507 -0600] sidgen_task_thread - [file
>> ipa_sidgen_task.c, line 194]: Sidgen task starts ...
>> [03/Apr/2017:09:07:34.273308903 -0600] find_sid_for_ldap_entry - [file
>> ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [24613] into an
>> unused
>> SID.
>> [03/Apr/2017:09:07:34.274521892 -0600] do_work - [file
>> ipa_sidgen_task.c, line
>> 154]: Cannot add SID to existing entry.
>> [03/Apr/2017:09:07:34.277196405 -0600] sidgen_task_thread - [file
>> ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
>>
> Look at this list's archives, I've been giving recipes how to fix this
> in February.
>
> My IPA ranges are:
>>
>> # ipa idrange-find
>> 
>> 2 ranges matched
>> 
>>  Range name: AD.NWRA.COM_id_range
>>  First Posix ID of the range: 2
>>  Number of IDs in the range: 2
>>  First RID of the corresponding RID range: 0
>>  Domain SID of the trusted domain: S-1-5-21-89655523-1570529619-2
>> 103694531
>>  Range type: Active Directory domain range
>>
>>  Range name: NWRA.COM_id_range
>>  First Posix ID of the range: 8000
>>  Number of IDs in the range: 2000
>>  First RID of the corresponding RID range: 1000
>>  First RID of the secondary RID range: 1
>>  Range type: local domain range
>> 
>> Number of entries returned 2
>> 
>>
>> So I've been creating these local posix IPA groups for HBAC access (as
>> well as
>> file storage) with the same gid as that assigned to the AD user.  Perhaps
>> that
>> is a problem?
>>
> Yes, that is a problem. But HBAC group is not a problem because HBAC
> group is not a POSIX IPA group at all, it is even stored in a different
> subtree than user groups.
>
>
Can you expand on this please? In what way is this a problem?

We also have local posix IPA groups with the same gid as that assigned to
the AD user (for historical reasons to do with samba shares on networked
disks).

We don't use those groups for HBAC though, we use AD group membership
through external groups for HBAC. (I use the term "we use HBAC" loosely -
it's still in testing :) )

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

Re: [Freeipa-users] Centos7/IPA4.2 : disable/enable hosts

[Lachlan Musicman]

On 11 April 2017 at 00:14, Johan Vermeulen  wrote:

> Hello All,
>
> just getting started with FreeIPA and one of the first features I'm trying
> is adding hosts, something I can't do in our current
> ldap-setup. So I'm looking forward to being able to do this.
> But after adding a host, the only way I see to disable it is unprovision
> it. And after doing that, I can' t find a way to re-provision the host.
>
> Can anybody point me in the right direction regarding this?
>
> Many thanks, J.
>
>

Rob is right - it depends on what you are doing.

But, in the mean time, here are a couple of pointers:

How to enable/disable hosts
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-disable.html


If what you are after is having it in the domain but restricting access,
then you are looking for "Host Based Access Control"

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html


Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] libsemanage updates fail due to AD user with space

[Lachlan Musicman]

Hola,

I've reported this issue before (with a different symptom iirc), but
thought I should mention again, as I have no idea how to competently report
it to selinux.

With SSSD/IPA in use, in a one way trust to AD, and AD users have spaces in
their names, libsemanage fails to update:

eg from recent monthly upgrade cycle:

Updating   :
selinux-policy-targeted-3.13.1-102.el7_3.16.noarch
3/14
libsemanage.parse_assert_ch: expected character ':', but found 'f'
(/etc/selinux/targeted/tmp/seusers.local: 5):
lastname firstn...@domain.com:unconfined_u:s0-s0:c0.c1023 (No such file or
directory).
libsemanage.seuser_parse: could not parse seuser record (No such file or
directory).
libsemanage.dbase_file_cache: could not cache file database (No such file
or directory).
libsemanage.semanage_base_merge_components: could not merge local
modifications into policy (No such file or directory).


cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] SSSD bug found? FreeIPA vs SSSD

[Lachlan Musicman]

Hola,

On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
(via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
-> name.org

I've seen some interesting behaviour.

Being part of a large organisation with a smaller nix environment and a
larger Windows environment we see all the best of odd AD management
behaviour (eg spaces in usernames...).

Turns out some of the groups in AD have an @ symbol in them.

The behavioural difference we see is: given userA in group "name @ of
group" that on the FreeIPA server:

[r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org

works as expected.

But on a client

[r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org

returns nothing.

We believe it is because of the group with the @ in the name.

The AD management team agreed to change the name of one group with an @ in
it's name, and that has solved the problem - id us...@name.org now works on
the sssd client.

Putting aside the critiques of having an @ in a group name, I believe that
if there isn't a bug, there is at least an inconsistency, between how
FreeIPA and sssd handle this situation.

This was a guess based on seeing this in the logs:

(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust
View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry]
(0x1000): OriginalDN:
[ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default
Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
errmsg set
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send]
(0x0400): Executing extended operation
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done]
(0x0400): ldap_extended_operation result: Success(0), (null).
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
...
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain unix.name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
(0x1000): Domain name.org is Active
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data]
(0x0040): find_domain_by_name failed.
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[s2n_response_to_attrs] (0x0040): add_v1_user_data failed.
(Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
[ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.


The last three lines tipped off a colleague who was debugging why this
userA couldn't login to anything.

Since then we have created IPA over rides for the groups with @ symbols in
them. This also works as a solution. It's not our preferred solution, but
we are users, not managers, of the AD system.

Cheers

L.





--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] SSSD bug found? FreeIPA vs SSSD

[Lachlan Musicman]

I am still having problems with FreeIPA/HBAC, SSSD and logging into hosts.
Could this be the reason that SSSD isn't picking up the full list of groups
a user belongs to?

In particular, ipa hbac test says true. "id domain\\username" or "id
username@domain" returns the correct groups. But the
sssd_domain.com.log- shows hbac_eval_user_element returning a list of
groups that doesn't include the IPA groups in the HBAC rule? (it does
return the AD group that is the external group that the IPA group would
register as being HBAC true, but not the matching IPA group)

cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 9 March 2017 at 20:39, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> > On to, 09 maalis 2017, Jakub Hrozek wrote:
> > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > > Hola,
> > > >
> > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and
> sssd
> > > > (via COPR) 1.15.1, which has a one way trust to an AD domain.
> unix.name.org
> > > > -> name.org
> > > >
> > > > I've seen some interesting behaviour.
> > > >
> > > > Being part of a large organisation with a smaller nix environment
> and a
> > > > larger Windows environment we see all the best of odd AD management
> > > > behaviour (eg spaces in usernames...).
> > > >
> > > > Turns out some of the groups in AD have an @ symbol in them.
> > > >
> > > > The behavioural difference we see is: given userA in group "name @ of
> > > > group" that on the FreeIPA server:
> > > >
> > > > [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org
> > > >
> > > > works as expected.
> > > >
> > > > But on a client
> > > >
> > > > [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@name.org
> > > >
> > > > returns nothing.
> > >
> > > Yes, it is a know issue:
> > >https://pagure.io/SSSD/sssd/issue/3219
> > >
> > > There were some users who reported this works better with a modified
> > > re_expression:
> > >re_expression = ((?P.+)@(?P[^@]+$))
> > > but I agree we should fix this by default. However, the fix must be
> done
> > > at both the SSSD level and the IPA extdom plugin, which also searches
> > > for the @-sign in the user and group names.
> > Luckily, a change for extdom plugin seem to be straightforward -- search
> > for the *last* occurence of the domain separator, not the first one. We
> > had a similar issue with nfs idmapd code too.
>
> Yes, the most tricky part would be testing, to make sure the new regular
> expression doesn't break anything. I used the one I showed to unblock
> some RHEL customers that were complaining and were a bit stuck, but I
> didn't have enough time to run all our available tests with it, that's
> why we didn't switch by default..
>
> --
> 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] List SPAM

[Lachlan Musicman]

On 24 April 2017 at 12:24, Prasun Gera  wrote:

> That doesn't work very well. The spam bots use different emails. And gmail
> marks the entire message thread as spam, not just the spam reply.
>
> On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam <
> dewangg...@xtremenitro.org> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Mark as spam, and they gone from my inbox. :)
>>
>>


If you are using gmail:

 - block the email address
 - mark the message as spam (not the thread)
 - you can then delete the message in question


Note that this can still cause issues wrt workplace and SFW images, as
Gmail automatically "previews" images.

I leave them to deal with at home and have reported the problem to my
manager and IT team so they know it's not my fault - as both acknowledge
and understand that this forum has been very valuable to us wrt getting
things working.

L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] Fresh Install of FreeIPA-Server - CentOS7

[Lachlan Musicman]

Robert, did you look in /var/log/ipaserver-install.log as it says?

Was there any other information?

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 11 May 2017 at 13:24, Robert L. Harris  wrote:

> Ok,  I gave up on Ubuntu.  I'm now trying the latest CentOS7.  I built out
> a "minimal server" with some normal base packages which did include the
> freeipa-client but otherwise, just standard tools.  Here's a pastebin of
> the output of the install:  https://pastebin.com/zAWCgkUU
>
> Robert
>
>
> --
> 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] ipa-replica-install hangs: starting certificate server instance

[Lachlan Musicman]

We are seeing this. I'm not at work, but I think it's bug report 6766.

Patch has already been committed (bot by us), we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 18:57, Callum Guy  wrote:

> Hi All,
>
> I am currently stuck trying to setup the first replica of our master IPA
> server. I have tried a number of different approaches including escalating
> from a client and nothing is working for me. I perform a full OS reset each
> time I get stuck.
>
> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this version
> however having performed ipa-server-upgrade - does this mean i'm on 4.4.4?).
>
> The command is shown below - note that i am skipping the conn check as my
> platforms security settings do not allow the SSH session to be established
> back on the master, all ports should be available to the application
> however.
>
> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>
> Directory Manager (existing master) password:
>
> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
> check queries IPA DNS directly and ignores /etc/hosts.)
> Continue? [no]: yes
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/42]: creating directory server user
>   [2/42]: creating directory server instance
>   [3/42]: updating configuration in dse.ldif
>   [4/42]: restarting directory server
>   [5/42]: adding default schema
>   [6/42]: enabling memberof plugin
>   [7/42]: enabling winsync plugin
>   [8/42]: configuring replication version plugin
>   [9/42]: enabling IPA enrollment plugin
>   [10/42]: enabling ldapi
>   [11/42]: configuring uniqueness plugin
>   [12/42]: configuring uuid plugin
>   [13/42]: configuring modrdn plugin
>   [14/42]: configuring DNS plugin
>   [15/42]: enabling entryUSN plugin
>   [16/42]: configuring lockout plugin
>   [17/42]: configuring topology plugin
>   [18/42]: creating indices
>   [19/42]: enabling referential integrity plugin
>   [20/42]: configuring ssl for ds instance
>   [21/42]: configuring certmap.conf
>   [22/42]: configure autobind for root
>   [23/42]: configure new location for managed entries
>   [24/42]: configure dirsrv ccache
>   [25/42]: enabling SASL mapping fallback
>   [26/42]: restarting directory server
>   [27/42]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 4 seconds elapsed
> Update succeeded
>
>   [28/42]: adding sasl mappings to the directory
>   [29/42]: updating schema
>   [30/42]: setting Auto Member configuration
>   [31/42]: enabling S4U2Proxy delegation
>   [32/42]: importing CA certificates from LDAP
>   [33/42]: initializing group membership
>   [34/42]: adding master entry
>   [35/42]: initializing domain level
>   [36/42]: configuring Posix uid/gid generation
>   [37/42]: adding replication acis
>   [38/42]: enabling compatibility plugin
>   [39/42]: activating sidgen plugin
>   [40/42]: activating extdom plugin
>   [41/42]: tuning directory server
>   [42/42]: configuring directory to start on boot
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
> seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
>
> And here is stays and refuses to move on. The ipareplica-install.log log
> reports:
> 2017-05-18T08:40:07Z DEBUG wait_for_open_ports: localhost [8080, 8443]
> timeout 300
> 2017-05-18T08:40:09Z DEBUG Waiting until the CA is running
> 2017-05-18T08:40:09Z DEBUG request POST http://ipa2.SITE.net:8080/ca/
> admin/ca/getStatus
> 2017-05-18T08:40:09Z DEBUG request body ''
>
> I have tried and that port is indeed inaccessible but I can't establish a
> way to progress this issue from any of the the other log files. Also I have
> seen in the 4.4.4 release notes that IPv6 being disabled on the master can
> cause issues, re-enabling (at least in /etc/hosts) did not seem to help.
>
> If anyone is able to offer ideas that would be very much appreciated. I am
> tempted to remove the --setup-ca option to see if this helps.
>
> Thanks,
>
> Callum
>
>
>
> *0333 332   |  

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

[Lachlan Musicman]

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 19:34, Lachlan Musicman <data...@gmail.com> wrote:

> We are seeing this. I'm not at work, but I think it's bug report 6766.
>
> Patch has already been committed (bot by us), we're waiting for IPA 4.5.
>
> cheers
> L.
>
> --
> "Mission Statement: To provide hope and inspiration for collective action,
> to build collective power, to achieve collective transformation, rooted in
> grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 18:57, Callum Guy <callum@x-on.co.uk> wrote:
>
>> Hi All,
>>
>> I am currently stuck trying to setup the first replica of our master IPA
>> server. I have tried a number of different approaches including escalating
>> from a client and nothing is working for me. I perform a full OS reset each
>> time I get stuck.
>>
>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>> version however having performed ipa-server-upgrade - does this mean i'm on
>> 4.4.4?).
>>
>> The command is shown below - note that i am skipping the conn check as my
>> platforms security settings do not allow the SSH session to be established
>> back on the master, all ports should be available to the application
>> however.
>>
>> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
>> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>>
>> Directory Manager (existing master) password:
>>
>> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
>> check queries IPA DNS directly and ignores /etc/hosts.)
>> Continue? [no]: yes
>> Configuring NTP daemon (ntpd)
>>   [1/4]: stopping ntpd
>>   [2/4]: writing configuration
>>   [3/4]: configuring ntpd to start on boot
>>   [4/4]: starting ntpd
>> Done configuring NTP daemon (ntpd).
>> Configuring directory server (dirsrv). Estimated time: 1 minute
>>   [1/42]: creating directory server user
>>   [2/42]: creating directory server instance
>>   [3/42]: updating configuration in dse.ldif
>>   [4/42]: restarting directory server
>>   [5/42]: adding default schema
>>   [6/42]: enabling memberof plugin
>>   [7/42]: enabling winsync plugin
>>   [8/42]: configuring replication version plugin
>>   [9/42]: enabling IPA enrollment plugin
>>   [10/42]: enabling ldapi
>>   [11/42]: configuring uniqueness plugin
>>   [12/42]: configuring uuid plugin
>>   [13/42]: configuring modrdn plugin
>>   [14/42]: configuring DNS plugin
>>   [15/42]: enabling entryUSN plugin
>>   [16/42]: configuring lockout plugin
>>   [17/42]: configuring topology plugin
>>   [18/42]: creating indices
>>   [19/42]: enabling referential integrity plugin
>>   [20/42]: configuring ssl for ds instance
>>   [21/42]: configuring certmap.conf
>>   [22/42]: configure autobind for root
>>   [23/42]: configure new location for managed entries
>>   [24/42]: configure dirsrv ccache
>>   [25/42]: enabling SASL mapping fallback
>>   [26/42]: restarting directory server
>>   [27/42]: setting up initial replication
>> Starting replication, please wait until this has completed.
>> Update in progress, 4 seconds elapsed
>> Update succeeded
>>
>>   [28/42]: adding sasl mappings to the directory
>>   [29/42]: updating schema
>>   [30/42]: setting Auto Member configuration
>>   [31/42]: enabling S4U2Proxy delegation
>>   [32/42]: importing CA certificates from LDAP
>>   [33/42]: initializing group membership
>>   [34/42]: adding master entry
>>   [35/42]: initializing domain level
>>   [36/42]: configuring Posix uid/gid generation
>>   [37/42]: adding replication acis
>>   [38/42]: enabling compatibility plugin
>>   [39/42]: activating sidgen plugin
>>   [40/42]: activating extdom plugin
>>   [41/42]: tuning directory server
>>   [42/42]: configuring directory to start on boot
>> Done configuring directory server (dirsrv).
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>> 30 seconds
>>   [1/27]: creating certificate server user
>>   [2/27]: configuring certificate server instance
>>   [3/27]: stopping certificate server instance

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

[Lachlan Musicman]

Sorry cobber. We only found 6766 today - we've been tackling it on and off
for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 19:53, Callum Guy <callum@x-on.co.uk> wrote:

> Ah, thanks for that Lachlan - its always reassuring to hear that its not
> just me!
>
> As mentioned above I have it running without the CA so that's a good
> start. I am sure we will upgrade as well once 4.5 becomes stable and GA for
> CentOS. I'm not expecting that to happen quickly so will have to work with
> what we have for now.
>
> Do you happen to know if there is any way to build the CA component
> separately?
>
> On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman <data...@gmail.com>
> wrote:
>
>> https://pagure.io/freeipa/issue/6766
>>
>> 4.5.1 - I stand corrected. Can add more tomorrow.
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 19:34, Lachlan Musicman <data...@gmail.com> wrote:
>>
>>> We are seeing this. I'm not at work, but I think it's bug report 6766.
>>>
>>> Patch has already been committed (bot by us), we're waiting for IPA 4.5.
>>>
>>> cheers
>>> L.
>>>
>>> --
>>> "Mission Statement: To provide hope and inspiration for collective
>>> action, to build collective power, to achieve collective transformation,
>>> rooted in grief and rage but pointed towards vision and dreams."
>>>
>>>  - Patrice Cullors, *Black Lives Matter founder*
>>>
>>> On 18 May 2017 at 18:57, Callum Guy <callum@x-on.co.uk> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am currently stuck trying to setup the first replica of our master
>>>> IPA server. I have tried a number of different approaches including
>>>> escalating from a client and nothing is working for me. I perform a full OS
>>>> reset each time I get stuck.
>>>>
>>>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>>>> version however having performed ipa-server-upgrade - does this mean i'm on
>>>> 4.4.4?).
>>>>
>>>> The command is shown below - note that i am skipping the conn check as
>>>> my platforms security settings do not allow the SSH session to be
>>>> established back on the master, all ports should be available to the
>>>> application however.
>>>>
>>>> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101
>>>> --setup-ca --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>>>>
>>>> Directory Manager (existing master) password:
>>>>
>>>> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
>>>> check queries IPA DNS directly and ignores /etc/hosts.)
>>>> Continue? [no]: yes
>>>> Configuring NTP daemon (ntpd)
>>>>   [1/4]: stopping ntpd
>>>>   [2/4]: writing configuration
>>>>   [3/4]: configuring ntpd to start on boot
>>>>   [4/4]: starting ntpd
>>>> Done configuring NTP daemon (ntpd).
>>>> Configuring directory server (dirsrv). Estimated time: 1 minute
>>>>   [1/42]: creating directory server user
>>>>   [2/42]: creating directory server instance
>>>>   [3/42]: updating configuration in dse.ldif
>>>>   [4/42]: restarting directory server
>>>>   [5/42]: adding default schema
>>>>   [6/42]: enabling memberof plugin
>>>>   [7/42]: enabling winsync plugin
>>>>   [8/42]: configuring replication version plugin
>>>>   [9/42]: enabling IPA enrollment plugin
>>>>   [10/42]: enabling ldapi
>>>>   [11/42]: configuring uniqueness plugin
>>>>   [12/42]: configuring uuid plugin
>>>>   [13/42]: configuring modrdn plugin
>>>>   [14/42]: configuring DNS plugin
>>>>   [15/42]: enabling entryUSN plugin
>>>>   [16/42]: configuring lockout plugin
>>>>   [17/42]: configuring topology plugin
>>>>   [18/42]: creating indices
>>>>   [19/4

Re: [Freeipa-users] CentOS patch management on FreeIPA server

[Lachlan Musicman]

On 17 May 2017 at 15:23, Lakshan Jayasekara <
lakshan.jayasek...@lankaclear.com> wrote:
>
> Hi All,
>
>
>
> I’m using FreeIPA server VERSION: 4.4.0, API_VERSION: 2.213 and running
on CentOS 7 and have one replica server as well. I need to patch up centos
system as per PCI DSS compliance. Let me know whether I can proceed as
usual or to follow any sequential steps to achieve the task.


Lakshanth,

You should always have appropriate backup and restore procedures that are
good for you.

Having said that, I regularly update our IPA server with patches (via
Katello/Foreman) without a problem.

I think I even "yum update"d from IPA 4.2 to 4.4 and it just worked.


cheers
L.


--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, Black Lives Matter founder
-- 
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