Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

[Lukas Slebodnik]

On (27/12/16 10:08), Alan Latteri wrote:
>Can you provide an example of what file this entry should go into and what it 
>look like in file? Do you have to do this on the client side/ server or both?
>
Do you have the same problem?
Could you provide steps how do you run lxc container?

>Thanks,
>Alan
>
>> On Dec 23, 2016, at 4:43 AM, Dan Kemp  wrote:
>> 
>> That did it, thanks! I could have sworn I tried that, maybe I ended up 
>> putting it in in the wrong section. I wish whatever changed going from 4.2.0 
>> to 4.4.0 that made SELinux required, took the selinux enforcement level into 
>> account and updated the file accordingly.
>> 
BTW this bug is not related to ipa-client 4.2 or 4.4.
It might be caused by changes in sssd or libsemanage.

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] Upgrade to 4.4.0 Breaks login.

[Alan Latteri]

Can you provide an example of what file this entry should go into and what it 
look like in file? Do you have to do this on the client side/ server or both?

Thanks,
Alan

> On Dec 23, 2016, at 4:43 AM, Dan Kemp  wrote:
> 
> That did it, thanks! I could have sworn I tried that, maybe I ended up 
> putting it in in the wrong section. I wish whatever changed going from 4.2.0 
> to 4.4.0 that made SELinux required, took the selinux enforcement level into 
> account and updated the file accordingly.
> 
> 
> On Fri, Dec 23, 2016 at 4:31 AM, Alexander Bokovoy  > wrote:
> On to, 22 joulu 2016, Dan Kemp wrote:
> Hello,
> 
> I recently ran an upgrade of my freeipa servers, and most of the clients to
> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install
> and server update, I can no longer log in to update clients via ssh. Login
> to non-update clients works as before.
> 
> The SSH connections fail with:
> 
> Connection closed by UNKNOWN
> 
> I ran sssd with debugging on a failing 4.4.0 client and got this error log:
> 
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 2)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 1)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 0)
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]]
> [selinux_child_create_buffer] (0x4000): buffer size: 45
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
> (0x2000): Setting up signal handler up for pid [437]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
> (0x2000): Signal handler set up for pid [437]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)],
> ldap[0x560c04c32d60]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
> (0x2000): Trace: end of ldap_result list
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler]
> (0x0400): All data has been sent!
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> selinux_child started.
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
> Running with effective IDs: [0][0].
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
> Running with real IDs [0][0].
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> context initialized
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): seuser length: 12
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): seuser: unconfined_u
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): mls_range length: 14
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): mls_range: s0-s0:c0.c1023
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): username length: 7
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
> (0x2000): username: ipauser
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
> performing selinux operations
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
> (0x0020): SELinux policy not managed
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser]
> (0x0020): Cannot create SELinux handle
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls:
> unknown
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [sss_semanage_init]
> (0x0020): SELinux policy not managed
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser]
> (0x0020): Cannot init SELinux management
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
> Cannot set SELinux login context.
> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
> selinux_child failed!
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done]
> (0x0020): selinux_child_parse_response failed: [22][Invalid argument]
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400):
> DP Request [PAM SELinux #3]: Request handler finished [0]: Success
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv]
> (0x0400): DP Request [PAM SELinux #3]: Receiving request data.
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
> (0x0400): DP Request [PAM SELinux #3]: Request removed.
> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
> (0x0400): Number of active DP request: 0
> (Wed Dec 20 20:38:13 2016) 

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Martin Basti]

Great, you are welcome :)


On 27.12.2016 13:41, Maciej Drobniuch wrote:

Martin,

Your troubleshooting style put me on the right track.

The alternative DNS servers had Ipv6  records that did not resolv 
properly.


After deleting those records adding A records (with reverse PTR check) 
and adding host works fine. The PTR record is created in the GUI and 
works fine.


Thank you very much for your time and help with this!

Cheers!
M.

On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch 
> wrote:


# dig soa  0.0.10.in-addr.arpa.

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3,
ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INSOA

;; ANSWER SECTION:
0.0.10.in-addr.arpa.86400INSOAfreeipa1.cs.int
. hostmaster.cs.int
. 1482653944 3600 900 1209600 3600

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int .
0.0.10.in-addr.arpa.86400INNSfreeipa2.cs.int .
0.0.10.in-addr.arpa.86400INNSkrkfreeipa.cs.int
.

;; ADDITIONAL SECTION:
freeipa1.cs.int .1200INA10.0.0.200
freeipa2.cs.int .1200INA10.0.1.200
krkfreeipa.cs.int .1200INA10.0.2.6

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: wto gru 27 07:33:41 EST 2016
;; MSG SIZE  rcvd: 333


On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti > wrote:

I just noticed previously you sent wrong dig, I need

dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype




On 27.12.2016 13:21, Maciej Drobniuch wrote:

# python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print
a.rrset.name '
0.0.10.in-addr.arpa.

On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti
> wrote:



On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY:
1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int
. hostmaster.cs.int
. 1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111



Hmm, this query doesn't contain ANSWER section, that may
be reason why python-dns failed.

could you check with:

python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN");
print a.rrset.name '




On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti
> wrote:



On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti
> wrote:



On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
>
wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR
record. I've added it manually to the
zone and it's working.


I was asking for SOA and zone name, IMO
there is nothing secret about reverse zone
name from private address space

what returns this command on server?
python -c 'import netaddr; from dns 

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

Martin,

Your troubleshooting style put me on the right track.

The alternative DNS servers had Ipv6  records that did not resolv
properly.

After deleting those records adding A records (with reverse PTR check) and
adding host works fine. The PTR record is created in the GUI and works fine.

Thank you very much for your time and help with this!

Cheers!
M.

On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch 
wrote:

> # dig soa  0.0.10.in-addr.arpa.
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.0.10.in-addr.arpa. IN SOA
>
> ;; ANSWER SECTION:
> 0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int.
> 1482653944 3600 900 1209600 3600
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int.
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int. 1200 IN A 10.0.0.200
> freeipa2.cs.int. 1200 IN A 10.0.1.200
> krkfreeipa.cs.int. 1200 IN A 10.0.2.6
>
> ;; Query time: 15 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: wto gru 27 07:33:41 EST 2016
> ;; MSG SIZE  rcvd: 333
>
>
> On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti  wrote:
>
>> I just noticed previously you sent wrong dig, I need
>>
>> dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype
>>
>>
>>
>>
>> On 27.12.2016 13:21, Maciej Drobniuch wrote:
>>
>> # python -c 'from dns import resolver; a = 
>> resolver.query("0.0.10.in-addr.arpa.",
>> "SOA", "IN"); print a.rrset.name'
>> 0.0.10.in-addr.arpa.
>>
>> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti  wrote:
>>
>>>
>>>
>>> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>>>
>>> $ dig 0.0.10.in-addr.arpa
>>>
>>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;0.0.10.in-addr.arpa. IN A
>>>
>>> ;; AUTHORITY SECTION:
>>> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
>>> 1482653944 3600 900 1209600 3600
>>>
>>> ;; Query time: 197 msec
>>> ;; SERVER: 10.0.0.200#53(10.0.0.200)
>>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
>>> ;; MSG SIZE  rcvd: 111
>>>
>>>
>>> Hmm, this query doesn't contain ANSWER section, that may be reason why
>>> python-dns failed.
>>>
>>> could you check with:
>>>
>>> python -c 'from dns import resolver; a = 
>>> resolver.query("0.0.10.in-addr.arpa.",
>>> "SOA", "IN"); print a.rrset.name'
>>>
>>>
>>>
>>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti 
>>> wrote:
>>>


 On 27.12.2016 12:07, Maciej Drobniuch wrote:

 Hi Martin!

 Thank you for your time!

 On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti 
 wrote:

>
>
> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Appreciate your help!
>
> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti 
> wrote:
>
>>
>>
>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Thank you for reply.
>>
>> 1. The dig is returning proper PTR record. I've added it manually to
>> the zone and it's working.
>>
>>
>> I was asking for SOA and zone name, IMO there is nothing secret about
>> reverse zone name from private address space
>>
>> what returns this command on server?
>> python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>>
>>
>> # python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
> print resolver.zone_for_name(revn)'
> 165.0.0.10.in-addr.arpa.
> in-addr.arpa.
>
>
> It looks that python-dns failed to find proper zone, what is supposed
> to be authoritative zone for that record in your system?
> How do your reverse zones look?
>
 I have the reverse zone added.
 0.0.10.in-addr.arpa.

 Do you know maybe how python/ipa is determining what's the dns server
 for the internal zone?
 As far I understood this is not a "access rights issue". It's a DNS PTR
 resolution problem with python(ipa's using python) ?


 It doesn't care about resolver, python-dns is checking SOA records, it
 removes labels from left and tries to find best match zone

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

# dig soa  0.0.10.in-addr.arpa.

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa. IN SOA

;; ANSWER SECTION:
0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int.
1482653944 3600 900 1209600 3600

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int.
0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int.

;; ADDITIONAL SECTION:
freeipa1.cs.int. 1200 IN A 10.0.0.200
freeipa2.cs.int. 1200 IN A 10.0.1.200
krkfreeipa.cs.int. 1200 IN A 10.0.2.6

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: wto gru 27 07:33:41 EST 2016
;; MSG SIZE  rcvd: 333


On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti  wrote:

> I just noticed previously you sent wrong dig, I need
>
> dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype
>
>
>
>
> On 27.12.2016 13:21, Maciej Drobniuch wrote:
>
> # python -c 'from dns import resolver; a = 
> resolver.query("0.0.10.in-addr.arpa.",
> "SOA", "IN"); print a.rrset.name'
> 0.0.10.in-addr.arpa.
>
> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti  wrote:
>
>>
>>
>> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>>
>> $ dig 0.0.10.in-addr.arpa
>>
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;0.0.10.in-addr.arpa. IN A
>>
>> ;; AUTHORITY SECTION:
>> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
>> 1482653944 3600 900 1209600 3600
>>
>> ;; Query time: 197 msec
>> ;; SERVER: 10.0.0.200#53(10.0.0.200)
>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
>> ;; MSG SIZE  rcvd: 111
>>
>>
>> Hmm, this query doesn't contain ANSWER section, that may be reason why
>> python-dns failed.
>>
>> could you check with:
>>
>> python -c 'from dns import resolver; a = 
>> resolver.query("0.0.10.in-addr.arpa.",
>> "SOA", "IN"); print a.rrset.name'
>>
>>
>>
>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti  wrote:
>>
>>>
>>>
>>> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>>>
>>> Hi Martin!
>>>
>>> Thank you for your time!
>>>
>>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti  wrote:
>>>


 On 22.12.2016 10:57, Maciej Drobniuch wrote:

 Hi Martin

 Appreciate your help!

 On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti 
 wrote:

>
>
> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Thank you for reply.
>
> 1. The dig is returning proper PTR record. I've added it manually to
> the zone and it's working.
>
>
> I was asking for SOA and zone name, IMO there is nothing secret about
> reverse zone name from private address space
>
> what returns this command on server?
> python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
> print resolver.zone_for_name(revn)'
>
>
> # python -c 'import netaddr; from dns import resolver; ip =
 netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
 print resolver.zone_for_name(revn)'
 165.0.0.10.in-addr.arpa.
 in-addr.arpa.


 It looks that python-dns failed to find proper zone, what is supposed
 to be authoritative zone for that record in your system?
 How do your reverse zones look?

>>> I have the reverse zone added.
>>> 0.0.10.in-addr.arpa.
>>>
>>> Do you know maybe how python/ipa is determining what's the dns server
>>> for the internal zone?
>>> As far I understood this is not a "access rights issue". It's a DNS PTR
>>> resolution problem with python(ipa's using python) ?
>>>
>>>
>>> It doesn't care about resolver, python-dns is checking SOA records, it
>>> removes labels from left and tries to find best match zone
>>>
>>> what returns dig 0.0.10.in-addr.arpa.  SOA ?
>>>
>>>
>>>
>>>



 2. The problem exists while adding host entries or A records with
> "create reverse" option.
>
> That's why I asked to run dig, the code uses DNS system to determine
> zone.
>
> 3. If I'll bind a host with ipa-client-install the PTR record gets
> created in the reverse zone and it works
>
> Ok
>
 Manually creating the PTR record works fine as well.

>
>
> 4. The resolv.conf file has only the IPA server IP addres/localhost
> added.
>
>
> Have you changed it recently?
>
 

Re: [Freeipa-users] List SPAM

[Martin Basti]

On 27.12.2016 13:22, Outback Dingo wrote:

Im still getting nude porn spam emails and pics from a user

Kimi Rachel 



It is not a user, it is a SPAM bot mining public archives. We don't have 
any control about it we can just un-publish archives (tested, spam 
stopped after that) but they contain a lot of information for users.


JFTR the email is changing.

--
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] DNS reverse zone is not managed by this server

[Martin Basti]

I just noticed previously you sent wrong dig, I need

dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype




On 27.12.2016 13:21, Maciej Drobniuch wrote:
# python -c 'from dns import resolver; a = 
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print 
a.rrset.name '

0.0.10.in-addr.arpa.

On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti > wrote:




On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int
. hostmaster.cs.int
. 1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111



Hmm, this query doesn't contain ANSWER section, that may be reason
why python-dns failed.

could you check with:

python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print
a.rrset.name '




On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti > wrote:



On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti
> wrote:



On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
> wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've
added it manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is
nothing secret about reverse zone name from private
address space

what returns this command on server?
python -c 'import netaddr; from dns import
resolver; ip = netaddr.IPAddress("10.0.0.165");
revn = ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver;
ip = netaddr.IPAddress("10.0.0.165"); revn =
ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone,
what is supposed to be authoritative zone for that
record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the
dns server for the internal zone?
As far I understood this is not a "access rights issue".
It's a DNS PTR resolution problem with python(ipa's using
python) ?


It doesn't care about resolver, python-dns is checking SOA
records, it removes labels from left and tries to find best
match zone

what returns dig 0.0.10.in-addr.arpa.  SOA ?









2. The problem exists while adding host entries or
A records with "create reverse" option.

That's why I asked to run dig, the code uses DNS
system to determine zone.


3. If I'll bind a host with ipa-client-install the
PTR record gets created in the reverse zone and it
works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not
see the local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs.
(I've manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY:
1, ADDITIONAL: 2

   

[Freeipa-users] List SPAM

[Outback Dingo]

Im still getting nude porn spam emails and pics from a user

Kimi Rachel 

-- 
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 Servers out of sync - DNS records

[Outback Dingo]

> According to log, it looks that replication has been restored a week ago
>
> can you use https://github.com/peterpakos/ipa_check_consistency to check
> what else is missing?
>
> If it finds missing entries, probably re-initialization will be needed
>
> Martin


really odd... i just did a yum update -y during our conversation on
both servers, now ipa2 is synced again...

-- 
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] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

# python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name'
0.0.10.in-addr.arpa.

On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti  wrote:

>
>
> On 27.12.2016 13:04, Maciej Drobniuch wrote:
>
> $ dig 0.0.10.in-addr.arpa
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.0.10.in-addr.arpa. IN A
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
> 1482653944 3600 900 1209600 3600
>
> ;; Query time: 197 msec
> ;; SERVER: 10.0.0.200#53(10.0.0.200)
> ;; WHEN: Tue Dec 27 13:02:24 CET 2016
> ;; MSG SIZE  rcvd: 111
>
>
> Hmm, this query doesn't contain ANSWER section, that may be reason why
> python-dns failed.
>
> could you check with:
>
> python -c 'from dns import resolver; a = 
> resolver.query("0.0.10.in-addr.arpa.",
> "SOA", "IN"); print a.rrset.name'
>
>
>
> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti  wrote:
>
>>
>>
>> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>>
>> Hi Martin!
>>
>> Thank you for your time!
>>
>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti  wrote:
>>
>>>
>>>
>>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>>
>>> Hi Martin
>>>
>>> Appreciate your help!
>>>
>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti 
>>> wrote:
>>>


 On 22.12.2016 09:37, Maciej Drobniuch wrote:

 Hi Martin

 Thank you for reply.

 1. The dig is returning proper PTR record. I've added it manually to
 the zone and it's working.


 I was asking for SOA and zone name, IMO there is nothing secret about
 reverse zone name from private address space

 what returns this command on server?
 python -c 'import netaddr; from dns import resolver; ip =
 netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
 print resolver.zone_for_name(revn)'


 # python -c 'import netaddr; from dns import resolver; ip =
>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>> print resolver.zone_for_name(revn)'
>>> 165.0.0.10.in-addr.arpa.
>>> in-addr.arpa.
>>>
>>>
>>> It looks that python-dns failed to find proper zone, what is supposed to
>>> be authoritative zone for that record in your system?
>>> How do your reverse zones look?
>>>
>> I have the reverse zone added.
>> 0.0.10.in-addr.arpa.
>>
>> Do you know maybe how python/ipa is determining what's the dns server for
>> the internal zone?
>> As far I understood this is not a "access rights issue". It's a DNS PTR
>> resolution problem with python(ipa's using python) ?
>>
>>
>> It doesn't care about resolver, python-dns is checking SOA records, it
>> removes labels from left and tries to find best match zone
>>
>> what returns dig 0.0.10.in-addr.arpa.  SOA ?
>>
>>
>>
>>
>>>
>>>
>>>
>>> 2. The problem exists while adding host entries or A records with
 "create reverse" option.

 That's why I asked to run dig, the code uses DNS system to determine
 zone.

 3. If I'll bind a host with ipa-client-install the PTR record gets
 created in the reverse zone and it works

 Ok

>>> Manually creating the PTR record works fine as well.
>>>


 4. The resolv.conf file has only the IPA server IP addres/localhost
 added.


 Have you changed it recently?

>>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
>>> reverse zone.
>>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
>>> created the ptr)
>>>
>>> # dig -x 10.0.0.165
>>>
>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; E: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;165.0.0.10.in-addr.arpa. IN PTR
>>>
>>> ;; ANSWER SECTION:
>>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>>>
>>> ;; AUTHORITY SECTION:
>>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>>>
>>>
>>> This authority section looks suspicious, I would expect something like
>>> 0.0.10.in-addr.arpa.
>>>
>>> Back to question about your reverse zones.
>>>
>> I've intentionally hid our internal ip space, sorry, good catch my finger
>> has slipped :).
>>
>>
>> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig
>> returned in authority section.
>>
>>
>>
>>>
>>> ;; ADDITIONAL SECTION:
>>> freeipa1.cs.int. 1200 IN A 10.0.0.200
>>>
>>> ;; Query time: 3 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; WHEN: czw gru 22 04:51:23 EST 2016
>>> ;; 

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Martin Basti]

On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int . 
hostmaster.cs.int . 1482653944 3600 900 
1209600 3600


;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111


Hmm, this query doesn't contain ANSWER section, that may be reason why 
python-dns failed.


could you check with:

python -c 'from dns import resolver; a = 
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name'



On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti > wrote:




On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti > wrote:



On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
> wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added
it manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing
secret about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip
= netaddr.IPAddress("10.0.0.165"); revn =
ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns;
print revn; print resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is
supposed to be authoritative zone for that record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the dns
server for the internal zone?
As far I understood this is not a "access rights issue". It's a
DNS PTR resolution problem with python(ipa's using python) ?


It doesn't care about resolver, python-dns is checking SOA
records, it removes labels from left and tries to find best match zone

what returns dig 0.0.10.in-addr.arpa.  SOA ?









2. The problem exists while adding host entries or A
records with "create reverse" option.

That's why I asked to run dig, the code uses DNS system
to determine zone.


3. If I'll bind a host with ipa-client-install the PTR
record gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see
the local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs.
(I've manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,
ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int
.



This authority section looks suspicious, I would expect
something like 0.0.10.in-addr.arpa.

Back to question about your reverse zones.

I've intentionally hid our internal ip space, sorry, good catch
my finger has slipped :).


So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig
returned in authority section.






;; ADDITIONAL SECTION:
freeipa1.cs.int .1200INA10.0.0.200

;; Query 

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa. IN A

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111


On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti  wrote:

>
>
> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>
> Hi Martin!
>
> Thank you for your time!
>
> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti  wrote:
>
>>
>>
>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Appreciate your help!
>>
>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti  wrote:
>>
>>>
>>>
>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>
>>> Hi Martin
>>>
>>> Thank you for reply.
>>>
>>> 1. The dig is returning proper PTR record. I've added it manually to the
>>> zone and it's working.
>>>
>>>
>>> I was asking for SOA and zone name, IMO there is nothing secret about
>>> reverse zone name from private address space
>>>
>>> what returns this command on server?
>>> python -c 'import netaddr; from dns import resolver; ip =
>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>> print resolver.zone_for_name(revn)'
>>>
>>>
>>> # python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>> 165.0.0.10.in-addr.arpa.
>> in-addr.arpa.
>>
>>
>> It looks that python-dns failed to find proper zone, what is supposed to
>> be authoritative zone for that record in your system?
>> How do your reverse zones look?
>>
> I have the reverse zone added.
> 0.0.10.in-addr.arpa.
>
> Do you know maybe how python/ipa is determining what's the dns server for
> the internal zone?
> As far I understood this is not a "access rights issue". It's a DNS PTR
> resolution problem with python(ipa's using python) ?
>
>
> It doesn't care about resolver, python-dns is checking SOA records, it
> removes labels from left and tries to find best match zone
>
> what returns dig 0.0.10.in-addr.arpa.  SOA ?
>
>
>
>
>>
>>
>>
>> 2. The problem exists while adding host entries or A records with "create
>>> reverse" option.
>>>
>>> That's why I asked to run dig, the code uses DNS system to determine
>>> zone.
>>>
>>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>>> created in the reverse zone and it works
>>>
>>> Ok
>>>
>> Manually creating the PTR record works fine as well.
>>
>>>
>>>
>>> 4. The resolv.conf file has only the IPA server IP addres/localhost
>>> added.
>>>
>>>
>>> Have you changed it recently?
>>>
>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
>> reverse zone.
>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
>> created the ptr)
>>
>> # dig -x 10.0.0.165
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; OPT PSEUDOSECTION:
>> ; E: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;165.0.0.10.in-addr.arpa. IN PTR
>>
>> ;; ANSWER SECTION:
>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>>
>> ;; AUTHORITY SECTION:
>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>>
>>
>> This authority section looks suspicious, I would expect something like
>> 0.0.10.in-addr.arpa.
>>
>> Back to question about your reverse zones.
>>
> I've intentionally hid our internal ip space, sorry, good catch my finger
> has slipped :).
>
>
> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig returned
> in authority section.
>
>
>
>>
>> ;; ADDITIONAL SECTION:
>> freeipa1.cs.int. 1200 IN A 10.0.0.200
>>
>> ;; Query time: 3 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: czw gru 22 04:51:23 EST 2016
>> ;; MSG SIZE  rcvd: 124
>>
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>> Cheers!
>>> M.
>>>
>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti  wrote:
>>>
 Hello all :)

 On 20.12.2016 01:33, Maciej Drobniuch wrote:

 Hi All!

 I get the following message while adding a new hostname.

 "The host was added but the DNS update failed with: DNS reverse zone
 in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"


 IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
 what will be in SOA answer?

 What is the name of reverse zone you have on IPA DNS server?


 Martin


 The 

Re: [Freeipa-users] IPA Servers out of sync - DNS records

[Martin Basti]

On 27.12.2016 12:55, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 6:47 AM, Martin Basti  wrote:


On 27.12.2016 12:40, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti  wrote:


On 27.12.2016 00:25, Outback Dingo wrote:

Seems my secondary ipa server is somehow out of sync with the master,
is there any way to force a sync update ?


Can you elaborate more?

What exactly from DNS records is out of sync?

Martin


it appears as though at least one A record is missing there might be
more but thats the first i noticed



Can you please search for replication conflicts

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

and do you have any replication errors in /var/log/dirsrv/slapd-*/errors
log on servers?

Martin

from the master ipa

[root@ipa dingo]# cat /var/log/dirsrv/slapd-*/errors
389-Directory/1.3.4.0 B2016.215.1556
ipa.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM)

[20/Dec/2016:22:38:51 -0500] - SSL alert: Configured NSS Ciphers
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_SEED_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] SSL Initialization - Configured SSL
version range: min: TLS1.0, max: TLS1.2
[20/Dec/2016:22:38:51 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up
[20/Dec/2016:22:38:51 -0500] - WARNING: changelog: entry cache size
2097152B is less than db size 4169728B; We recommend to 

Re: [Freeipa-users] IPA Servers out of sync - DNS records

[Martin Basti]

On 27.12.2016 12:40, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti  wrote:


On 27.12.2016 00:25, Outback Dingo wrote:

Seems my secondary ipa server is somehow out of sync with the master,
is there any way to force a sync update ?


Can you elaborate more?

What exactly from DNS records is out of sync?

Martin


it appears as though at least one A record is missing there might be
more but thats the first i noticed



Can you please search for replication conflicts

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

and do you have any replication errors in 
/var/log/dirsrv/slapd-*/errors  log on servers?


Martin

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

Re: [Freeipa-users] IPA Servers out of sync - DNS records

[Outback Dingo]

On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti  wrote:
>
>
> On 27.12.2016 00:25, Outback Dingo wrote:
>>
>> Seems my secondary ipa server is somehow out of sync with the master,
>> is there any way to force a sync update ?
>>
>
> Can you elaborate more?
>
> What exactly from DNS records is out of sync?
>
> Martin


it appears as though at least one A record is missing there might be
more but thats the first i noticed

-- 
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] DNS reverse zone is not managed by this server

[Martin Basti]

On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti > wrote:




On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti > wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it
manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing
secret about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is
supposed to be authoritative zone for that record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the dns server 
for the internal zone?
As far I understood this is not a "access rights issue". It's a DNS 
PTR resolution problem with python(ipa's using python) ?


It doesn't care about resolver, python-dns is checking SOA records, it 
removes labels from left and tries to find best match zone


what returns dig 0.0.10.in-addr.arpa.  SOA ?








2. The problem exists while adding host entries or A records
with "create reverse" option.

That's why I asked to run dig, the code uses DNS system to
determine zone.


3. If I'll bind a host with ipa-client-install the PTR
record gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see the
local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've
manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,
ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int
.



This authority section looks suspicious, I would expect something
like 0.0.10.in-addr.arpa.

Back to question about your reverse zones.

I've intentionally hid our internal ip space, sorry, good catch my 
finger has slipped :).


So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig 
returned in authority section.






;; ADDITIONAL SECTION:
freeipa1.cs.int .1200INA10.0.0.200

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE  rcvd: 124



Martin




Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti
> wrote:

Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS
reverse zone in-addr.arpa. for IP address 10.0.0.165 is
not managed by this server"


IPA failed to get correct reverse zone, can you try dig
-x 10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse
zone - all OK

While adding a new host,  the A record is being created
but the PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to
reinstall again because of problems with
kerberos(probably dependencies).

Not sure what is the root cause of the issue.

Re: [Freeipa-users] Unable to add attributes to default user schema

[Martin Basti]

On 26.12.2016 20:51, Carlos Raúl Laguna wrote:

Hello everyone,

I am trying to add a new attribute ¨mailQuota¨ to the default user 
schema, so far i add the objectclass mailrecipient to the default user 
objectclasses which contain this specific atribute but so far i only 
capable to add the attribute manually with user-mod 
--addattr=mailQuota=102400 but when invoke config-mod 
--addattr=mailQuota=102400 i get ipa: ERROR: attribute "mailQuota" not 
allowed. Any way to get around this, also does 
https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf is 
still relevant for freeipa 4.3.2 ?


Thanks in advance



Hello,

this is not right,
config-mod --addattr=mailQuota=102400

this is not a way how to set a new attr with default value for users, to 
set custom value you need to use custom user_add pre-callback, slide 17


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

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Maciej Drobniuch]

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti  wrote:

>
>
> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>
> Hi Martin
>
> Appreciate your help!
>
> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti  wrote:
>
>>
>>
>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Thank you for reply.
>>
>> 1. The dig is returning proper PTR record. I've added it manually to the
>> zone and it's working.
>>
>>
>> I was asking for SOA and zone name, IMO there is nothing secret about
>> reverse zone name from private address space
>>
>> what returns this command on server?
>> python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>>
>>
>> # python -c 'import netaddr; from dns import resolver; ip =
> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print
> resolver.zone_for_name(revn)'
> 165.0.0.10.in-addr.arpa.
> in-addr.arpa.
>
>
> It looks that python-dns failed to find proper zone, what is supposed to
> be authoritative zone for that record in your system?
> How do your reverse zones look?
>
I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the dns server for
the internal zone?
As far I understood this is not a "access rights issue". It's a DNS PTR
resolution problem with python(ipa's using python) ?


>
>
>
> 2. The problem exists while adding host entries or A records with "create
>> reverse" option.
>>
>> That's why I asked to run dig, the code uses DNS system to determine zone.
>>
>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>> created in the reverse zone and it works
>>
>> Ok
>>
> Manually creating the PTR record works fine as well.
>
>>
>>
>> 4. The resolv.conf file has only the IPA server IP addres/localhost added.
>>
>>
>> Have you changed it recently?
>>
> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
> reverse zone.
> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
> created the ptr)
>
> # dig -x 10.0.0.165
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; E: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;165.0.0.10.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>
> ;; AUTHORITY SECTION:
> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>
>
> This authority section looks suspicious, I would expect something like
> 0.0.10.in-addr.arpa.
>
> Back to question about your reverse zones.
>
I've intentionally hid our internal ip space, sorry, good catch my finger
has slipped :).

>
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int. 1200 IN A 10.0.0.200
>
> ;; Query time: 3 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: czw gru 22 04:51:23 EST 2016
> ;; MSG SIZE  rcvd: 124
>
>>
>>
>> Martin
>>
>>
>>
>> Cheers!
>> M.
>>
>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti  wrote:
>>
>>> Hello all :)
>>>
>>> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>>>
>>> Hi All!
>>>
>>> I get the following message while adding a new hostname.
>>>
>>> "The host was added but the DNS update failed with: DNS reverse zone
>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>>>
>>>
>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
>>> what will be in SOA answer?
>>>
>>> What is the name of reverse zone you have on IPA DNS server?
>>>
>>>
>>> Martin
>>>
>>>
>>> The reverse zone is configured and working.
>>> When I am manually adding the PTR record to the reverse zone - all OK
>>>
>>> While adding a new host,  the A record is being created but the PTR
>>> fails with the message above.
>>>
>>> Reinstalling centos+IPA worked once but I had to reinstall again because
>>> of problems with kerberos(probably dependencies).
>>>
>>> Not sure what is the root cause of the issue.
>>>
>>> VERSION: 4.4.0, API_VERSION: 2.213
>>>
>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42
>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> Any help appreciated!
>>> --
>>> Best regards
>>>
>>> Maciej Drobniuch
>>> Network Security Engineer
>>> Collective-sense LLC
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> Collective-sense LLC
>>
>>
>>
>
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> 2410 Camino Ramon, Suite 129
> San Ramon, CA 94583
>
>
>
Happy new year!

-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

Re: [Freeipa-users] Upgrade to 4.4.0 Breaks login.

[Dan Kemp]

That did it, thanks! I could have sworn I tried that, maybe I ended up
putting it in in the wrong section. I wish whatever changed going from
4.2.0 to 4.4.0 that made SELinux required, took the selinux enforcement
level into account and updated the file accordingly.


On Fri, Dec 23, 2016 at 4:31 AM, Alexander Bokovoy 
wrote:

> On to, 22 joulu 2016, Dan Kemp wrote:
>
>> Hello,
>>
>> I recently ran an upgrade of my freeipa servers, and most of the clients
>> to
>> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install
>> and server update, I can no longer log in to update clients via ssh. Login
>> to non-update clients works as before.
>>
>> The SSH connections fail with:
>>
>> Connection closed by UNKNOWN
>>
>> I ran sssd with debugging on a failing 4.4.0 client and got this error
>> log:
>>
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 2)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 1)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit
>> ldb transaction (nesting: 0)
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]]
>> [selinux_child_create_buffer] (0x4000): buffer size: 45
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
>> (0x2000): Setting up signal handler up for pid [437]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup]
>> (0x2000): Signal handler set up for pid [437]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
>> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)],
>> ldap[0x560c04c32d60]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result]
>> (0x2000): Trace: end of ldap_result list
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler]
>> (0x0400): All data has been sent!
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> selinux_child started.
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
>> Running with effective IDs: [0][0].
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x2000):
>> Running with real IDs [0][0].
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> context initialized
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): seuser length: 12
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): seuser: unconfined_u
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): mls_range length: 14
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): mls_range: s0-s0:c0.c1023
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): username length: 7
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [unpack_buffer]
>> (0x2000): username: ipauser
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0400):
>> performing selinux operations
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
>> [sss_semanage_init]
>> (0x0020): SELinux policy not managed
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [get_seuser]
>> (0x0020): Cannot create SELinux handle
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
>> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls:
>> unknown
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437
>> [sss_semanage_init]
>> (0x0020): SELinux policy not managed
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [set_seuser]
>> (0x0020): Cannot init SELinux management
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
>> Cannot set SELinux login context.
>> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437 [main] (0x0020):
>> selinux_child failed!
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler]
>> (0x0400): EOF received, client finished
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done]
>> (0x0020): selinux_child_parse_response failed: [22][Invalid argument]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done]
>> (0x0400):
>> DP Request [PAM SELinux #3]: Request handler finished [0]: Success
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv]
>> (0x0400): DP Request [PAM SELinux #3]: Receiving request data.
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
>> (0x0400): DP Request [PAM SELinux #3]: Request removed.
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor]
>> (0x0400): Number of active DP request: 0
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply]
>> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local]
>> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler]
>>