Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-12 Thread Jakub Hrozek 
On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
> On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] 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' and allowed IPA to assign the GID.
> > 2) I created an external group in IPA named
> > '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).
> > 3) I added the group cri-cri_server_administrators_external' as a
> > member of '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
> >  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 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).
> I think you problems are related to this snippet of your domain log
> where SSSD on IPA client was unable to add membership of your user to
> any of these groups:
> 
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [get_groups_dns] (0x0400): Root domain uses fully-qualified names,
> objects might not be correctly added to groups with short names.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [get_groups_dns] (0x0400): Root domain uses fully-qualified names,
> objects might not be correctly added to groups with short names.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [ipa_s2n_save_objects] (0x2000): Updating memberships for
> a.cri.dsulli...@bsdad.uchicago.edu
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-aaa_sms_administrat...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-aaa_cvs_reposit...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-active_us...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12 13:2

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-12 Thread Alexander Bokovoy 

On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] 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' and allowed IPA to assign the GID.
2) I created an external group in IPA named
'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).
3) I added the group cri-cri_server_administrators_external' as a
member of '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
 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 
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).

I think you problems are related to this snippet of your domain log
where SSSD on IPA client was unable to add membership of your user to
any of these groups:

(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[get_groups_dns] (0x0400): Root domain uses fully-qualified names,
objects might not be correctly added to groups with short names.
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[get_groups_dns] (0x0400): Root domain uses fully-qualified names,
objects might not be correctly added to groups with short names.
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[ipa_s2n_save_objects] (0x2000): Updating memberships for
a.cri.dsulli...@bsdad.uchicago.edu
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
object](32)[ldb_wait: No such object (32)]
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_update_members_ex] (0x0020): Could not add member
[a.cri.dsulli...@bsdad.uchicago.edu] to group
[name=cri-aaa_sms_administrat...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
Skipping.
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
object](32)[ldb_wait: No such object (32)]
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_update_members_ex] (0x0020): Could not add member
[a.cri.dsulli...@bsdad.uchicago.edu] to group
[name=cri-aaa_cvs_reposit...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
Skipping.
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
object](32)[ldb_wait: No such object (32)]
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_update_members_ex] (0x0020): Could not add member
[a.cri.dsulli...@bsdad.uchicago.edu] to group
[name=cri-active_us...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
Skipping.
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
object](32)[ldb_wait: No such object (32)]
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
(Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
[sysdb_update_members_ex] (0

[Freeipa-users] Replication Agreement issues noticed with repl-monitor.pl

2016-07-12 Thread Devin Acosta 
I was trying to create another Replica but then noticed it was constantly
having issues trying to finish the joining of the replication. I then ran
the command: repl-monitor.pl, It appears i have several replicaid's and
they seem to be having issues, wondering if this is adding to my issue.

Anyone know how I can resolve this issue and clean up the replication???

See attached Screenshot.


replication-issue.pdf
Description: Adobe PDF document
-- 
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)

2016-07-12 Thread 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 related to the issue descri

Re: [Freeipa-users] Impossible to restart IPA because of the presence of a file called CS.cfg.bak.saved

2016-07-12 Thread Endi Sukma Dewata 

On 7/12/2016 12:17 PM, bahan w wrote:

Hello everyone.

I'm using ipa 3.0.0-47 on a RHEL6.6 OS (multi-masters).

Today I tried to restart the IPA service with the commande
###
service ipa restart
###

And I got the following warning concerning the pkica service :
###
Since the file '/var/lib/pki-ca/conf/CS.cfg.bak.saved' exists, a
previous backup attempt has failed!  Backups will be discontinued until
this issue has been resolved!
###

And then the service get KO.

I wanted to know, may you tell me when this file CS.cfg.bak.saved is
created ?
Also, do you know why the presence of this file prevent the ipa service
to start ?

Thank you in advance for your help.

BR.

Bahan



Hi Bahan,

To my understanding during CS.cfg backup process the old CS.cfg.bak is 
temporarily saved into the CS.cfg.bak.saved. When the backup is complete 
the CS.cfg.bak.saved should be removed automatically.


In your case there might be something wrong in the CS.cfg that causes 
the backup to fail. Try comparing the CS.cfg with CS.cfg.bak.saved to 
see what has changed recently. If you find something wrong, shutdown the 
server, fix the CS.cfg, move CS.cfg.bak.saved somewhere else, then 
restart the server again.


Please also check if the disk is full.

If it's still not working please send the CA debug log 
(/var/log/pki-ca/debug) to pki-users mailing list or to RHEL support 
channel. Thanks.


--
Endi S. Dewata

--
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] (DRAFT) HA mail services with FreeIPA, postfix, dovecot, amavisd-new, clamd and PLAIN/GSSAPI SSO

2016-07-12 Thread Günther J . Niederwimmer 
Hello,

some days ago I found this doc, now I like to setup a secure mail server but 
the article is now missing?

Can this come back?

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

  Günther J. Niederwimmer

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

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-12 Thread Sullivan, Daniel [AAA] 
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’
 and allowed IPA to assign the GID.
2) I created an external group in IPA named 
'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).
3) I added the group 
cri-cri_server_administrators_external
 as a member of 
'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
 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
 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
Target host: 
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 
mailto:jstep...@redhat.com>> 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]]] 
[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 related to the issue described in this 
thread 
(https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/DTX4LP5VI2AHANMT4QFXERCN7US2TCUB/),
 except that clearing the cache does not fix the problem.  I am further stumped 
by the fact that I have an additional machine that was deployed from an 
identical VMWare template image which IPA HBAC works correctly on.  From a 
client perspective I am working with a fully updated version of RHEL 6.8 with 
ipa-client 3.0.0-50.el6.1 and sssd 1.13.3-22.el6.  We have a domain with 2 IPA 
domain controllers (RHEL 7.2 and ipa-server 4.2.0-15.el7_2.6.1); I have since 
shut down one

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-12 Thread Justin Stephenson 

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]]]
   [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 related to the issue described in this 
thread 
(https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/DTX4LP5VI2AHANMT4QFXERCN7US2TCUB/),
 except that clearing the cache does not fix the problem.  I am further stumped 
by the fact that I have an additional machine that was deployed from an 
identical VMWare template image which IPA HBAC works correctly on.  From a 
client perspective I am working with a fully updated version of RHEL 6.8 with 
ipa-client 3.0.0-50.el6.1 and sssd 1.13.3-22.el6.  We have a domain with 2 IPA 
domain controllers (RHEL 7.2 and ipa-server 4.2.0-15.el7_2.6.1); I have since 
shut down one of the two domain controllers and cleared the cache 
(/var/lib/sssd/db/*) on both clients and restarted sssd (to isolate a potential 
replication problem between DCs); the HBAC rule validates correctly on the only 
remaining DC (basically an!
   any any rule). HBAC (the ability to login via sshd) continues to work on 
only one of the two clients.

>From what I can tell, both clients have the same version of all ipa-client and 
sssd (and presumably related packages as both clients are fully updated). I have 
compared their /etc/sshd/sshd_config, /etc/sssd/sssd.conf and all configurations 
in /etc/pam.d and both systems appear consistent.

I feel that it is worthwhile to mention that I believe that one of the two 
machines in question (the one that is not working) was bound as a CentrifyDC 
client.  We are planning on replacing CentrifyDC with FreeIPA (for several 
reasons), so it is important that we are able to take an existing CentrifyDC 
client, unbind it, uninstall the CentrifyDC package(s), and install FreeIPA in 
its place.  Regardless of whether CentrifyDC was previously installed, I feel 
that my somewhat thorough examination of /etc/sshd/sshd_config and the contents 
of /etc/pam.d would negate any potential residual configuration from Centrify 
that would cause this sort of problem.  I have posted my domain log here: 
http://pastebin.com/41KeSnq4

It is also probably worthwhile to mention that I am authenticating as a user in 
a trusted domain, although I believe this should be apparent in the the 
pastebin.

I am hoping that a subject matter expert in IPA and or SSSD would be able to 
help me further diagnose the access denied by HBAC entry that is present in the 
pastebin specified above.  As I said, I have cleared /var/lib/sss/db/* and 
reinstalled IPA-client several times.  I have also rebooted the system 
completely.

Thank you for considering helping me; I appreciate your time and expertise.

Best,

Dan





This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please
notify the sender and destroy all copies of the transmittal.

Thank you
University of Chicago Medicine and Biological Sciences




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

[Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-12 Thread Sullivan, Daniel [AAA] 
Hi,

I am experiencing an HBAC issue that is proving to be very difficult to 
diagnose.  It appears very closely related to the issue described in this 
thread 
(https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/DTX4LP5VI2AHANMT4QFXERCN7US2TCUB/),
 except that clearing the cache does not fix the problem.  I am further stumped 
by the fact that I have an additional machine that was deployed from an 
identical VMWare template image which IPA HBAC works correctly on.  From a 
client perspective I am working with a fully updated version of RHEL 6.8 with 
ipa-client 3.0.0-50.el6.1 and sssd 1.13.3-22.el6.  We have a domain with 2 IPA 
domain controllers (RHEL 7.2 and ipa-server 4.2.0-15.el7_2.6.1); I have since 
shut down one of the two domain controllers and cleared the cache 
(/var/lib/sssd/db/*) on both clients and restarted sssd (to isolate a potential 
replication problem between DCs); the HBAC rule validates correctly on the only 
remaining DC (basically an!
  any any rule). HBAC (the ability to login via sshd) continues to work on only 
one of the two clients.

>From what I can tell, both clients have the same version of all ipa-client and 
>sssd (and presumably related packages as both clients are fully updated). I 
>have compared their /etc/sshd/sshd_config, /etc/sssd/sssd.conf and all 
>configurations in /etc/pam.d and both systems appear consistent.

I feel that it is worthwhile to mention that I believe that one of the two 
machines in question (the one that is not working) was bound as a CentrifyDC 
client.  We are planning on replacing CentrifyDC with FreeIPA (for several 
reasons), so it is important that we are able to take an existing CentrifyDC 
client, unbind it, uninstall the CentrifyDC package(s), and install FreeIPA in 
its place.  Regardless of whether CentrifyDC was previously installed, I feel 
that my somewhat thorough examination of /etc/sshd/sshd_config and the contents 
of /etc/pam.d would negate any potential residual configuration from Centrify 
that would cause this sort of problem.  I have posted my domain log here: 
http://pastebin.com/41KeSnq4

It is also probably worthwhile to mention that I am authenticating as a user in 
a trusted domain, although I believe this should be apparent in the the 
pastebin.

I am hoping that a subject matter expert in IPA and or SSSD would be able to 
help me further diagnose the access denied by HBAC entry that is present in the 
pastebin specified above.  As I said, I have cleared /var/lib/sss/db/* and 
reinstalled IPA-client several times.  I have also rebooted the system 
completely.

Thank you for considering helping me; I appreciate your time and expertise.

Best,

Dan





This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


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

Re: [Freeipa-users] How does FreeIPA Fetch the Master DNS?

2016-07-12 Thread Rob Crittenden 

Russ Kaehler wrote:

Hello,

I'd like to review the section of code specifically related to how
FreeIPA fetches the master DNS. When I run this:

ipa -vv user-show admin


The following printout emerges:


ipa: INFO: trying https://nqa-ipa-master-int.sprinklr.com/ipa/json
ipa: INFO: Forwarding 'user_show' to json server
'https://nqa-ipa-master-int.sprinklr.com/ipa/json'
ipa: INFO: Request: {
  "id": 0,
  "method": "user_show",
  "params": [ [ "admin" ],
  { "all": false, "no_members": false, "raw": false, "rights": false,

Where in the code does this line get populated with the DNS URI?

ipa: INFO: trying https://ipa-master.foo.com/ipa/json


It will occasionally attempt to connect to the wrong DNS server and I'd
like to correct that behavior. My request is specifically to know where
to look in the code so I can investigate this matter.


Not sure if this is a terminology issue or not but it isn't contacting 
DNS servers, it is contacting an IPA master (which may be the same as 
your DNS servers if IPA is serving DNS).


It can get this from a number of places: DNS SRV records, 
/etc/ipa/default.conf or whatever is in the session cookie (depending on 
version of IPA).


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

[Freeipa-users] How does FreeIPA Fetch the Master DNS?

2016-07-12 Thread Russ Kaehler 
Hello,

I'd like to review the section of code specifically related to how FreeIPA
fetches the master DNS. When I run this:

ipa -vv user-show admin


The following printout emerges:


ipa: INFO: trying https://nqa-ipa-master-int.sprinklr.com/ipa/json
ipa: INFO: Forwarding 'user_show' to json server '
https://nqa-ipa-master-int.sprinklr.com/ipa/json'
ipa: INFO: Request: {
 "id": 0,
 "method": "user_show",
 "params": [ [ "admin" ],
 { "all": false, "no_members": false, "raw": false, "rights": false,

Where in the code does this line get populated with the DNS URI?

ipa: INFO: trying https://ipa-master.foo.com/ipa/json


It will occasionally attempt to connect to the wrong DNS server and I'd
like to correct that behavior. My request is specifically to know where to
look in the code so I can investigate this matter.

Cheers,
Russ
-- 
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

2016-07-12 Thread pgb205 
+freeipa-users list

  From: pgb205 
 To: Sumit Bose  
 Sent: Tuesday, July 12, 2016 2:12 PM
 Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
   
Sumit, thanks for replying
So the first issue is my fault, probably from when I was sanitizing logs. 
our active directory domain is ad_domain.local, but users would expect to login 
as userid@ad_domain.com or just userid.for ipa the kerberos realm is 
IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
ewr-fipa_server used to be old trial server so I am not sure why it's still in 
the dns lookup results. I'll check this part further.
Lastly. only the connection to one of the domain controllers on AD side is 
open. As discussed previously with Alexandr BokovoyI forced, in /etc/krb5.conf, 
a connection to this single, accessible domain controller. Are there any other 
files where I would needto lock down the connections between ipa->ad so that 
all traffic goes to specific active directory domain controller?
thanks again for replying so quickly.

  From: Sumit Bose 
 To: pgb205  
Cc: Sumit Bose 
 Sent: Tuesday, July 12, 2016 5:37 AM
 Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
  
On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> Sumit, 
> sssd log files attached with debug=10 in all sections.I have attempted 
> several logins for comparison as well as kinit commands

I came across two issues in the logs.

First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
FreeIPA cannot resolve those principals correctly. It was planned for
IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
please try to work-around suggested at the end of
http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
ewr-fipa_server.ad_domain.com but cannot find it an return the error code
for "Cannot contact any KDC for requested realm".

Second there are some issues access AD DCs via LDAP. SSSD tries to
connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
both fails. It is not clear from the logs if already the DNS lookup for
those fails or if the connection itself runs into a timeout. In the
former case you should make sure that the names can be resolved in the
IPA server in the latter you can try to increase ldap_network_timeout
(see man sssd-ldap for details). Since SSSD cannot connect to the DCs it
switches the AD domains to offline. The authentication request is
handled offline as well but since there are no cached credentials you
get the permission denied error.

HTH

bye,
Sumit

> 
>      From: Sumit Bose 
>  To: pgb205  
> Cc: "Freeipa-users@redhat.com" 
>  Sent: Monday, July 11, 2016 3:06 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>    
> On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote:
> > I have successfully established trust and am able to obtain ticket granting 
> > ticketkinit user@AD_DOMAIN.COMI can also do kinit admin@IPA_DOMAIN.COMssh 
> > 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 ProviderError: 3 
> > Account info lookup failedWill 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.
> 
> Yes, full SSSD logs with debug_level=10 would be best.
> 
> > --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.conffor line 
> > [libdefaults] default_realm=AD_DOMAN.COM and then restarting ipa services.
> 
> No, please do not change the default_realm. This is not related to the
> issues you are seeing.
> 
> bye,
> Sumit
> 
> > 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] Impossible to restart IPA because of the presence of a file called CS.cfg.bak.saved

2016-07-12 Thread bahan w 
Hello everyone.

I'm using ipa 3.0.0-47 on a RHEL6.6 OS (multi-masters).

Today I tried to restart the IPA service with the commande
###
service ipa restart
###

And I got the following warning concerning the pkica service :
###
Since the file '/var/lib/pki-ca/conf/CS.cfg.bak.saved' exists, a previous
backup attempt has failed!  Backups will be discontinued until this issue
has been resolved!
###

And then the service get KO.

I wanted to know, may you tell me when this file CS.cfg.bak.saved is
created ?
Also, do you know why the presence of this file prevent the ipa service to
start ?

Thank you in advance for your help.

BR.

Bahan
-- 
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] Can I migrate group password hashes from NIS?

2016-07-12 Thread Petr Spacek 
On 12.7.2016 17:13, Joanna Delaporte wrote:
> Hi Rob,
> 
> I'm sorry, I don't know how to list available pre-defined attributes, and I
> wasn't able to find it just now looking through the help menu. Is the
> attribute key grpassword, grouppassword, or something else?

The attribute called 'userpassword' can be added to 'posixGroup' object class
as well. I would start with that, but again, it is completely untested.

Please report your finding, I'm curious :-)

Petr^2 Spacek

> On Wed, Jul 6, 2016 at 4:24 PM, Rob Crittenden  wrote:
> 
>> Joanna Delaporte wrote:
>>
>>> I have successfully migrated some user password hashes from an NIS
>>> domain. I am wondering if there is a similar method for migrating group
>>> passwords. I haven't found any discussion or documentation on it.
>>>
>>
>> You do it the same way as users. Note that there are no IPA commands to
>> manage a group password and group passwords are completely untested (the
>> attribute is available though).

-- 
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] Can I migrate group password hashes from NIS?

2016-07-12 Thread Joanna Delaporte 
Hi Rob,

I'm sorry, I don't know how to list available pre-defined attributes, and I
wasn't able to find it just now looking through the help menu. Is the
attribute key grpassword, grouppassword, or something else?

Thanks!
Joanna

On Wed, Jul 6, 2016 at 4:24 PM, Rob Crittenden  wrote:

> Joanna Delaporte wrote:
>
>> I have successfully migrated some user password hashes from an NIS
>> domain. I am wondering if there is a similar method for migrating group
>> passwords. I haven't found any discussion or documentation on it.
>>
>
> You do it the same way as users. Note that there are no IPA commands to
> manage a group password and group passwords are completely untested (the
> attribute is available though).
>
> rob
>
>


-- 


Joanna Delaporte
Linux Systems Administrator | Parkland College
joannadelapo...@gmail.com
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Could not delete change record

2016-07-12 Thread Christophe TREFOIS 
Ok thanks Ludwig!

Got scared for a second :)

Best,

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




On 12 Jul 2016, at 15:42, Ludwig Krispenz 
mailto:lkris...@redhat.com>> wrote:


On 07/12/2016 11:25 AM, Christophe TREFOIS wrote:
Hi,

I have 3 replicas running 4.1 and 3 replicas running 4.2.

One of the 4.2 replicas is the new master (CRL) and is at the moment 
replicating against the old 4.1 cluster (we are in the process of migrating).

Upon restart of the 4.2 master, I receive many messages in slapd error log 
about delete_changerecord as seen below.

Is this something to worry about, or will it go away by itself?
it should go away, it is a problem of incorrect starting point for retro 
changelog trimming and it tries to remove already deleted records.

Thank you for your help,

[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15892 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15893 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15894 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15895 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15896 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15897 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15898 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15899 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15900 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15901 (rc: 32)


Christophe




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

--
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] Could not delete change record

2016-07-12 Thread Ludwig Krispenz 


On 07/12/2016 11:25 AM, Christophe TREFOIS wrote:

Hi,

I have 3 replicas running 4.1 and 3 replicas running 4.2.

One of the 4.2 replicas is the new master (CRL) and is at the moment 
replicating against the old 4.1 cluster (we are in the process of 
migrating).


Upon restart of the 4.2 master, I receive many messages in slapd error 
log about delete_changerecord as seen below.


Is this something to worry about, or will it go away by itself?
it should go away, it is a problem of incorrect starting point for retro 
changelog trimming and it tries to remove already deleted records.


Thank you for your help,

[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15892 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15893 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15894 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15895 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15896 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15897 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15898 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15899 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15900 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: 
could not delete change record 15901 (rc: 32)


*Christophe*





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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 service named in one of our IPA server cannot start

2016-07-12 Thread Petr Spacek 
On 9.7.2016 02:47, lm gnid wrote:
> Hello,
> 
> In one of our IPA server, named service suddenly cannot start, so I followed  
> the link bellow:
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart
> 
> Found some errors like bellow:
> 
> ==> messages <==
> 
> Jul  8 23:30:30 eupreprd-ops-ipa-01 named-pkcs11[5002]: LDAP error: Invalid 
> credentials: SASL(-14): authorization failure: : bind to LDAP server failed
> 
> It should be a "Invalid credentials: bind to LDAP server failed " error, 
> however, the commands bellow shows no issues to me:
> 
> [root@eupreprd-ops-ipa-01 ~]# kvno 
> DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
> DNS/eupreprd-ops-ipa-01.internal@internal.com: kvno = 2
> 
> [root@eupreprd-ops-ipa-01 ~]# klist -kt /etc/named.keytab
> 
> Keytab name: FILE:/etc/named.keytab
> 
> KVNO Timestamp   Principal
> 
>  --- 
> --
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
> 
> 
> [root@eupreprd-ops-ipa-01 ~]# kinit -kt /etc/named.keytab 
> DNS/eupreprd-ops-ipa-01.internal.com
> 
> [root@eupreprd-ops-ipa-01 ~]
> 
> 
> 
> [root@eupreprd-ops-ipa-01 ~]# ldapsearch -H 
> 'ldapi://%2fvar%2frun%2fslapd-INTERNAL-COM.socket"' -Y GSSAPI -b 'cn=dns, 
> dc=internal,dc=com'
> 
> ..
> 
> 
> 
> For now, I have use the "(Workaround) Use simple LDAP BIND insted of 
> Kerberos" to make it work, but still want to know how to recover to "sasl"?


Huh, this is really weird. The only idea I have is that there is some
replication issue between the IPA servers so server1 has different key for the
DNS service principal than server2.

In theory servers to contact can be chosen randomly (in theory) so named might
have been unlucky and attempted to contact 'wrong' server while kinit might
have been lucky and contacted the 'right' one.

Please check things mentioned in
http://www.freeipa.org/page/Troubleshooting#Replication_issues

I hope it helps!

-- 
Petr^2 Spacek

-- 
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] Could not delete change record

2016-07-12 Thread Christophe TREFOIS 
Hi,

I have 3 replicas running 4.1 and 3 replicas running 4.2.

One of the 4.2 replicas is the new master (CRL) and is at the moment 
replicating against the old 4.1 cluster (we are in the process of migrating).

Upon restart of the 4.2 master, I receive many messages in slapd error log 
about delete_changerecord as seen below.

Is this something to worry about, or will it go away by itself?

Thank you for your help,

[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15892 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15893 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15894 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15895 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15896 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15897 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15898 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15899 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15900 (rc: 32)
[12/Jul/2016:11:16:43 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 15901 (rc: 32)


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

2016-07-12 Thread Sumit Bose 
On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman 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...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> 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  wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy  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

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