Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

2015-10-01 Thread Andy Thompson 
> On 09/30/2015 09:04 PM, Andy Thompson wrote:
> >> On Wed, Sep 30, 2015 at 12:17:22PM +, Andy Thompson wrote:
>  On 09/21/2015 10:42 PM, Andy Thompson wrote:
> >> On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:
>  -Original Message-
>  From: Jakub Hrozek [mailto:jhro...@redhat.com]
>  Sent: Monday, September 21, 2015 3:29 PM
>  To: Andy Thompson 
>  Cc: freeipa-users@redhat.com; pbrez...@redhat.com
>  Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> 
>  On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson
> wrote:
> >>
> >> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson
> >> wrote:
> >>> I've narrowed it down a bit doing some testing.  The sudo
> >>> rules work when
> >> I remove the user group restriction from them.  My sudo rules
> >> all have my ad groups in the rule
> >>>
> >>> Rule name: ad_linux_admins
> >>> Enabled: TRUE
> >>> Host category: all
> >>> Command category: all
> >>> RunAs User category: all
> >>> RunAs Group category: all
> >>> User Groups: ad_linux_admins  <- if I remove this then
> >>> the rule gets
> >> applied
> >>
> >> Nice catch. Is the group visible after you login and run id?
> >>
> >> What is the exact IPA server version?
> >
> > Ok I also figured out if I rename my AD groups to match my IPA
> > groups then
>  the sudo rules are applied.
> >
> > I tested a couple things though, if I put a rule in the local
> > sudoers file on a server running sssd 1.11
> >
> > %@   "sudo commands"
> >
> > That rule was not applied.  If I remove the  then
> > the rule got
>  applied.
> >
> > On a server running sssd 1.12 that rule works, but does not
> > work if I
>  remove the .  And none of the IPA sudo rules work.
>  So something changed with the domain suffix between versions it
>  would appear.
> >
> > They key to making the IPA sudo rules work in 1.12 is to
> > remove the
>  default_domain_suffix setting in the sssd.conf, but that's not
>  an option in my environment.
> >
> > So all the moving parts together, it appears that having AD
> > groups with a different name than the IPA groups in
> > conjunction with the default_domain_suffix setting breaks
> > things
> >> right now in 1.12.
> > Appears since I renamed the ad group to match then the rule
> > without a domain suffix will get matched now
> 
>  Hello Andy,
> 
>  I'm sorry for the constant delays, but I was busy with some
>  trust-related fixes lately.
> 
>  Did you have a chance to confirm that just swapping sssd /on
>  the client/ while keeping the same version on the server fixes
>  the issue for
> >> you?
> 
>  Pavel (CC), can you help me out here, please? I have the setup
>  ready on my machine, so tomorrow we can take a look and
>  experiment (I can give you access to my environment via tmate
>  maybe..), but I wasn't able to reproduce the issue locally yet.
> >>>
> >>> It's fine I understand the backlog.
> >>>
> >>> I was not able to backrev the sssd due to dependency issues.  I
> >>> tried
> >> downgrading all the dependencies and got in a loop and stopped
> >> trying.  Are there any tricks you can think of to downgrade the
> >> sssd
>  cleanly?
> >>>
> >>> -andy
> >>>
> >>
> >> What failures are you getting? I normally just download all
> >> \*sss\* packages and then downgrade with rpm -U --oldpackage.
> >
> >
> > I'm just trying to use yum.  If I yum downgrade sssd I get a ton
> > of deps.  If include all the deps it lists
> >
> > yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5
> > sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python
> > python-sssdconfig
> >
> > I get multilib errors with libsss_idmap.
> >
> > Looks like my local repo doesn't have libsss_idmap 1.11 available.
> > Let me
>  look into that and see what repo it sits in and see if I can figure
>  out why it's not pulling in.
> >
> > -andy
> >
> 
>  Hi, since none of us is able to reproduce this in house, can you
>  give us more precise steps how to reproduce and more information?
>  What I have in mind at this moment is:
> 
>  1) How is membership defined? I suspect it goes as AD-USER ->
>  AD-GROUP
>  -> IPA->GROUP, right? What types of groups are used?
> 
> >>>
> >>> I have AD

Re: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops

2015-10-01 Thread Arnold, Paul C CTR USARMY PEO STRI (US) 
In a similar vein, is anyone aware of a (safe) automated work-around that can 
periodically map users into localized Windows accounts? I am conceptualizing 
some sort of powershell script involving a query to 389DS, but automating any 
form of account management that way sounds moderately terrifying, and may be 
out of the scope of this mailing list.

Regards,
--
Paul C. Arnold
IT Systems Engineer
Cole Engineering Services, Inc.


From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on 
behalf of Petr Spacek [pspa...@redhat.com]
Sent: Thursday, October 01, 2015 03:15 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops

This email was sent from a non-Department of Defense email account, and 
contained active links. All links are disabled, and require you to copy and 
paste the address to a Web browser. Please verify the identity of the sender, 
and confirm authenticity of all links contained within the message.

Unfortunately you will not be able to log into Windows workstations using IPA
users because FreeIPA is (at the moment) missing Global Catalog component
which prevents Windows from working with IPA users.

It should work the other way around, but there is nothing you can do at the
moment to make it working with IPA users in Windows. Global Catalog is several
months away in the best case.

Sorry.

--
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] [FreeIPA] SUDO fails with system error

2015-10-01 Thread Markus.Moj 
Dear @all,

 

I´ve an issue with two, Oracle Linux based, clients and my freeipa server. I 
can authenticate on any on the enrolled machines but the two oracle server 
aren´t able to access sudo and I don´t know why.

Here are a few thing I´ve already figured out.

 

Both machines are enrolled from scratch and I see following entries in 
ldap_child.log

(Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3933 [ldap_child_get_tgt_sync] 
(0x0010): Failed to init credentials: Client 'host/@' not 
found in Kerberos database

(Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3934 [ldap_child_get_tgt_sync] 
(0x0010): Failed to init credentials: Client 'host/@' not 
found in Kerberos database

 

Furthermore I get following entries in secure log

pam_unix(sudo:auth): authentication failure; logname= uid=95741 
euid=0 tty=/dev/pts/1 ruser= rhost=  user=

pam_sss(sudo:auth): authentication failure; logname= uid=95741 
euid=0 tty=/dev/pts/1 ruser= rhost= user=

pam_sss(sudo:auth): received for user : 4 (System error)

 

Also I get following entries in sssd_pam.log

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_check_user_search] (0x0400): 
Returning info for user [@]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_initgr_cache_set] (0x2000): 
[] added to PAM initgroup cache

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending 
request with the following data:

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): command: 
PAM_AUTHENTICATE

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): user: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sudo

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: 
/dev/pts/1

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 
1

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
type: 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6457

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 
0x7f0d05f51ab0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): 
pam_dp_send_req returned 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): 
Deleting request: [0x7f0d04221ed0:3:@]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 
0x7f0d05f51ab0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 
0x7f0d05f479e0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): 
received: [4][]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4].

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 26

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x7f0d05f51110][20]

(Thu Oct  1 14:06:17 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x7f0d05f51110][20]

(Thu Oct  1 14:06:17 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
entering pam_cmd_authenticate

 

In krb5_child.log I get following entries

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [main] (0x0400): 
krb5_child started.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x1000): 
total buffer size: [129]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x0100): 
cmd [241] uid [95741] gid [95741] validate [true] enterprise principal 
[false] offline [false] UPN [@]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x2000): 
No old ccache

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x0100): 
ccname: [KEYRING:persistent:95741] old_ccname: [not set] keytab: 
[/etc/krb5.keytab]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [k5c_precreate_ccache] 
(0x4000): Recreating ccache

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [k5c_setup_fast] 
(0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/@]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 
[find_principal_in_keytab] (0x4000): Trying to find principal 
host/@ in keytab.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [match_principal] 
(0x1000): Principal matched to the sample (host/@).

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [check_fast_ccache] 
(0x0200): FAST TGT is still valid.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [become_user] (0x0200): 
Trying to become user [95741][95741].

(Thu Oct  1 14:06:14

Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

2015-10-01 Thread Pavel Březina 

On 09/30/2015 09:04 PM, Andy Thompson wrote:

On Wed, Sep 30, 2015 at 12:17:22PM +, Andy Thompson wrote:

On 09/21/2015 10:42 PM, Andy Thompson wrote:

On Mon, Sep 21, 2015 at 07:39:01PM +, Andy Thompson wrote:

-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com]
Sent: Monday, September 21, 2015 3:29 PM
To: Andy Thompson 
Cc: freeipa-users@redhat.com; pbrez...@redhat.com
Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo

On Mon, Sep 21, 2015 at 02:22:54PM +, Andy Thompson wrote:


On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson

wrote:

I've narrowed it down a bit doing some testing.  The sudo
rules work when

I remove the user group restriction from them.  My sudo rules
all have my ad groups in the rule


Rule name: ad_linux_admins
Enabled: TRUE
Host category: all
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: ad_linux_admins  <- if I remove this then
the rule gets

applied

Nice catch. Is the group visible after you login and run id?

What is the exact IPA server version?


Ok I also figured out if I rename my AD groups to match my IPA
groups then

the sudo rules are applied.


I tested a couple things though, if I put a rule in the local
sudoers file on a server running sssd 1.11

%@   "sudo commands"

That rule was not applied.  If I remove the  then
the rule got

applied.


On a server running sssd 1.12 that rule works, but does not
work if I

remove the .  And none of the IPA sudo rules work.
So something changed with the domain suffix between versions it
would appear.


They key to making the IPA sudo rules work in 1.12 is to
remove the

default_domain_suffix setting in the sssd.conf, but that's not
an option in my environment.


So all the moving parts together, it appears that having AD
groups with a different name than the IPA groups in
conjunction with the default_domain_suffix setting breaks things

right now in 1.12.

Appears since I renamed the ad group to match then the rule
without a domain suffix will get matched now


Hello Andy,

I'm sorry for the constant delays, but I was busy with some
trust-related fixes lately.

Did you have a chance to confirm that just swapping sssd /on
the client/ while keeping the same version on the server fixes
the issue for

you?


Pavel (CC), can you help me out here, please? I have the setup
ready on my machine, so tomorrow we can take a look and
experiment (I can give you access to my environment via tmate
maybe..), but I wasn't able to reproduce the issue locally yet.


It's fine I understand the backlog.

I was not able to backrev the sssd due to dependency issues.  I
tried

downgrading all the dependencies and got in a loop and stopped
trying.  Are there any tricks you can think of to downgrade the
sssd

cleanly?


-andy



What failures are you getting? I normally just download all
\*sss\* packages and then downgrade with rpm -U --oldpackage.



I'm just trying to use yum.  If I yum downgrade sssd I get a ton
of deps.  If include all the deps it lists

yum downgrade sssd sssd-proxy sssd-ipa sssd-common-pac sssd-krb5
sssd-krb5-common sssd-ldap sssd-ad libipa_hbac libipa_hbac-python
python-sssdconfig

I get multilib errors with libsss_idmap.

Looks like my local repo doesn't have libsss_idmap 1.11 available.
Let me

look into that and see what repo it sits in and see if I can figure
out why it's not pulling in.


-andy



Hi, since none of us is able to reproduce this in house, can you
give us more precise steps how to reproduce and more information?
What I have in mind at this moment is:

1) How is membership defined? I suspect it goes as AD-USER ->
AD-GROUP
-> IPA->GROUP, right? What types of groups are used?



I have AD user->AD group->external IPA group->IPA group


2) sssd.conf might also turn out to be useful

3) Remove SSSD and sudo logs, reproduce and send us all the logs
please with the commands to reproduce. Not just snippets.



I can gather this up and get it over to you.

Actually I just realized I have two other environments and this is working

without issue in those environments.  I haven't done a full sudo rollout in
those environments yet so I didn't think to check those, but the admins rule
is working correctly and I haven't renamed any ad groups to match my IPA
groups.


Could it be something in a sudo rule or something in AD that's interfering

with this working correctly?

I would first try to find the difference in the environment. Are sssd versions
the same on the clients and servers? Are sudo versions the same?

...etc.

Pavel has a sudo troubleshooting guide in the works, maybe it would help..


All updates are controlled from the same repo so versions are all the same 
between the environments, that's why I'm wondering if something in AD could 
cause this.  Can't imagine what it would be though.  Groups are all mapped in 
the same way.
>Sudo is setup the same and works fine it was just

[Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI

2015-10-01 Thread Fujisan 
Hello,

I want to add user 'user1'  with the freeipa web UI. It is not present in
the list of users in the web UI but when I click "add", it says 'user with
name "user1" already exists'.

ldapsearch shows 'user1' is there:
---
$ ldapsearch -x -h ipasrv uid=user1
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI

2015-10-01 Thread Alexander Bokovoy 

On Thu, 01 Oct 2015, Fujisan wrote:

Hello,

I want to add user 'user1'  with the freeipa web UI. It is not present in
the list of users in the web UI but when I click "add", it says 'user with
name "user1" already exists'.

ldapsearch shows 'user1' is there:
---
$ ldapsearch -x -h ipasrv uid=user1
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] [FreeIPA] SUDO fails with system error

2015-10-01 Thread Jakub Hrozek 
On Thu, Oct 01, 2015 at 12:14:34PM +, markus@mc.ingenico.com wrote:
> Dear @all,
> 
>  
> 
> I´ve an issue with two, Oracle Linux based, clients and my freeipa server. I 
> can authenticate on any on the enrolled machines but the two oracle server 
> aren´t able to access sudo and I don´t know why.
  ~~~
What version of OEL and sssd?

> 
> Here are a few thing I´ve already figured out.
> 
>  
> 
> Both machines are enrolled from scratch and I see following entries in 
> ldap_child.log
> 
> (Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3933 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 
> 'host/@' not found in Kerberos database
> 
> (Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3934 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 
> 'host/@' not found in Kerberos database

This looks like the enrollment is not correct, are you able to kinit -k
?

> 
>  
> 
> Furthermore I get following entries in secure log
> 
> pam_unix(sudo:auth): authentication failure; logname= uid=95741 
> euid=0 tty=/dev/pts/1 ruser= rhost=  user=
> 
> pam_sss(sudo:auth): authentication failure; logname= uid=95741 
> euid=0 tty=/dev/pts/1 ruser= rhost= user=
> 
> pam_sss(sudo:auth): received for user : 4 (System error)

You said you were able to authenticate, but here the authentication is
throwing system error. How did you authenticate, was it maye with ssh
keys?

Is that all you have in krb5_child.log? I don't see the child exiting in
the logs..

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

Re: [Freeipa-users] Sudo entry not found by sssd in the cache db

2015-10-01 Thread Molnár Domokos 
 
"Pavel Březina"  írta:
>On 09/15/2015 09:10 AM, Molnár Domokos wrote:
>>
>> "Molnár Domokos"  írta:
>>
>> On 09/14/2015 03:08 PM, Pavel Březina wrote:
>>> On 09/11/2015 02:40 PM, Molnár Domokos wrote:
 Full log attached.
 "Molnár Domokos"  írta:


 "Pavel Březina"  írta:

 On 09/09/2015 09:31 PM, Molnár Domokos wrote:
  > I have a working IPA server and a working client
 config on an OpenSuse
  > 13.2 with the following versions:
  > nappali:~ # rpm -qa |grep sssd
  > sssd-tools-1.12.2-3.4.1.i586
  > sssd-krb5-1.12.2-3.4.1.i586
  > python-sssd-config-1.12.2-3.4.1.i586
  > sssd-ipa-1.12.2-3.4.1.i586
  > sssd-1.12.2-3.4.1.i586
  > sssd-dbus-1.12.2-3.4.1.i586
  > sssd-krb5-common-1.12.2-3.4.1.i586
  > sssd-ldap-1.12.2-3.4.1.i586
  > sssd is confihured for nss, pam, sudo
  > There is a test sudo rule defined in the ipa server,
 which applies to
  > user "doma".  However when the user tries to use sudo
 the rule does not
  > work.
  > doma@nappali:/home/doma> sudo ls
  > domas password:
  > doma is not allowed to run sudo on nappali.  This
 incident will be reported.
  > The corresponding log in the sssd_sudo.log is this:
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_cmd_get_version] (0x0200):
  > Received client version [1].
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_cmd_get_version] (0x0200):
  > Offered version [1].
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_parse_name_for_domains]
  > (0x0200): name doma matched without domain, user 
 is doma
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_parse_name_for_domains]
  > (0x0200): name doma matched without domain, user 
 is doma
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sudosrv_cmd_parse_query_done]
  > (0x0200): Requesting default options for [doma] from
 []
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sudosrv_get_user] (0x0200):
  > Requesting info about [doma@szilva]
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
  > [sudosrv_get_sudorules_query_cache] (0x0200):
 Searching sysdb with
  >
 
 [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
  > [sudosrv_get_sudorules_query_cache] (0x0200):
 Searching sysdb with
  > [(&(objectClass=sudoRule)(|(name=defaults)))]
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_parse_name_for_domains]
  > (0x0200): name doma matched without domain, user 
 is doma
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sss_parse_name_for_domains]
  > (0x0200): name doma matched without domain, user 
 is doma
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sudosrv_cmd_parse_query_done]
  > (0x0200): Requesting rules for [doma] from []
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
 [sudosrv_get_user] (0x0200):
  > Requesting info about [doma@szilva]
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
  > [sudosrv_get_sudorules_query_cache] (0x0200):
 Searching sysdb with
  >
 
 [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*))(&(dataExpireTimestamp<=1441826725)))]
  > (Wed Sep  9 21:25:25 2015) [sssd[sudo]]
  > [sudosrv_get_sudorules_query_cache] (0x0200):
 Searching sysdb with
  >
 
 [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=doma)(sudoUser=#181643)(sudoUser=%ipausers)(sudoUser=%picture_access)(sudoUser=%doma)(sudoUser=+*)))]
  > (Wed Sep  9 21:25:30 2015) [sssd[sudo]] [client_recv]
 (0x0200): Client
  > disconnected!
  > This seems perfectly OK with one exception. The query
 against the sysdb
  > does not find the entry. This is strange because the
 entry is there.

Re: [Freeipa-users] ipa upgrade failed

2015-10-01 Thread Martin Basti 



On 10/01/2015 05:03 PM, Andrew E. Bruno wrote:

Running CentOS 7.1.1503.

Upgrading via yum update from:

   ipa-server.x86_64 0:4.1.0-18.el7.centos.3

   --to--

   ipa-server.x86_64 0:4.1.0-18.el7.centos.4
   


We have 3 replicates. Upgrading the first replicate (first-master) went
fine. Upgrading the second replicate failed.

Got the following error during the update on the second replicate:

Pre schema upgrade failed with [Errno 111] Connection refused
IPA upgrade failed.

Where should I look for more info? Looked in the usual places and didn't
see anything out of the ordinary. How can I fix/verify the upgrade?

Thanks!

--Andrew


Hello,

can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors 
for more specific errors?


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] NFS Automount Domain Homedirs

2015-10-01 Thread Alexander Bokovoy 

On Wed, 30 Sep 2015, Sadettin Albasan wrote:

Here is a list of installed sssd packages:

sssd-client-1.12.4-47.el6.x86_64
sssd-common-1.12.4-47.el6.x86_64
sssd-ad-1.12.4-47.el6.x86_64
sssd-1.12.4-47.el6.x86_64
python-sssdconfig-1.12.4-47.el6.noarch
sssd-krb5-common-1.12.4-47.el6.x86_64
sssd-ipa-1.12.4-47.el6.x86_64
sssd-ldap-1.12.4-47.el6.x86_64
sssd-proxy-1.12.4-47.el6.x86_64
sssd-tools-1.12.4-47.el6.x86_64
sssd-common-pac-1.12.4-47.el6.x86_64
sssd-krb5-1.12.4-47.el6.x86_64

Thanks.

My apologies, we checked with Sumit and apparently, SSSD in RHEL 6.7 was
built without support for NFS idmap module.

Can you check if using CentOS 7 client and server for NFS would work?

--
/ Alexander Bokovoy

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

[Freeipa-users] ipa upgrade failed

2015-10-01 Thread Andrew E. Bruno 
Running CentOS 7.1.1503.

Upgrading via yum update from:  

  ipa-server.x86_64 0:4.1.0-18.el7.centos.3

  --to--

  ipa-server.x86_64 0:4.1.0-18.el7.centos.4
  

We have 3 replicates. Upgrading the first replicate (first-master) went
fine. Upgrading the second replicate failed.

Got the following error during the update on the second replicate:

Pre schema upgrade failed with [Errno 111] Connection refused
IPA upgrade failed.

Where should I look for more info? Looked in the usual places and didn't
see anything out of the ordinary. How can I fix/verify the upgrade?

Thanks!

--Andrew

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

2015-10-01 Thread Simo Sorce 

On 30/09/15 21:22, TomK wrote:



On 9/30/2015 8:12 AM, Martin Kosek wrote:

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the
freeipa-users
mailing list so not sure if the other message will get posted.)

Before I post a ticket to RH Support for an RFE, I'll post the
request here
to get some feedback on options and what ideas folks have.  I've a
situation
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper
RFC for
LDAP.  With SSSD rules I can define the rules to read the user 'host'
attribute but not the group 'host' attribute:


|access_provider = ldap ldap_access_order = host
ldap_user_authorized_host =
host|


Essentially TomK to be given access to hosts listed in the 'host'
attribute
but denied entry into lab05 for example (not listed in any group 'host'
attribute above) to the server.   If I have a new user that has
joined that
particular team at our organization, I can simply add her/him to the
above
groups and this user would get access only to the listed servers in
'host'
attribute by default. I don't need to specify new groups in customized
sssd.conf or ldap.conf files or in sshd config files.  Hence less to
update
with Salt or any other CM suite.  I've managed to setup SUDO rules
and with
the openssh-ldap.diff schema SSH public keys could be stored in AD
as well
and be read by OpenSSH.  So aside from the HBAC capability on groups,
virtually all our needs are handled by the WS2012 AD DC as it has to
follow
the OpenLDAP standard anyway.  Now to get this we considered and are
still
considering FreeIPA.  However this idea poses a set of challenges:

1) In large organizations where the AD support department are only
trained in
Windows AD setup and configuration (Only windows guy's) this would
require a
minimal of 3 bodies to support that know LDAP/Linux.  This is a
large cost.

2) The additional server requires the same hardening as the Windows
AD DC
servers meaning a new procedure has to be carved out for the 2+ FreeIPA
servers to be supported, hardened and maintained (upgraded).

Now I probably sound somewhat anti-FreeIPA, however the challenges of
implementing it in large organizations surface after some
deliberation, so
probably better to list then as it may help direct development of
the product
to contend with the challenges (Like having a document fully
dedicated to
hardening a FreeIPA server with selinux and other technologies in
easy to
maintain configuration).   I could be mistaken but some folks
mention that
it's 'better' to implement this sort of HBAC through other means (??
iptables
??) but never tried the alternatives yet.

So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to
enable
reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups and
then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html


More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups


I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin


We already defined HBAC rules in the manner that all the links you
pointed out indicate as an early implementation.  As a product, there is
no issue in IDM from that perspective.  This is all great and the
product is fine from that perspective.

It would be good to have a dual option of either allowing SSSD or IDM /
FreeIPA have full HBAC capability not just FreeIPA / IDM as in our
organization that would be a huge cost savings vs implementing IDM as a
separate Linux DC to be managed by a separate team.  So for those
customers that wish to go directly to AD or have already invested in AD
can choose SSSD only (If MS bundles AD with certain purchases, for
example, that is an actual cost savings for a company).  Other customers
who wish to keep the two separate so they do not flood AD DC's with non
Windows AD settings can integrate IDM.

There will be cases where there could be a potential to save on costs vs
AD so the Linux IDM could be chosen as an Enterprise DC to which Windows

Re: [Freeipa-users] User removed from IPA but still present in LDAP, so cannot him again in IPA web UI

2015-10-01 Thread Fujisan 
I get this:

-
$ ldapsearch -D cn=directory\ manager -W -b cn=accounts,dc=mydomain
'(uid=user1*)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] ipa upgrade failed

2015-10-01 Thread Martin Basti 



On 10/01/2015 05:28 PM, Andrew E. Bruno wrote:

On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote:


On 10/01/2015 05:03 PM, Andrew E. Bruno wrote:

Running CentOS 7.1.1503.

Upgrading via yum update from:

   ipa-server.x86_64 0:4.1.0-18.el7.centos.3

   --to--

   ipa-server.x86_64 0:4.1.0-18.el7.centos.4

We have 3 replicates. Upgrading the first replicate (first-master) went
fine. Upgrading the second replicate failed.

Got the following error during the update on the second replicate:

Pre schema upgrade failed with [Errno 111] Connection refused
IPA upgrade failed.

Where should I look for more info? Looked in the usual places and didn't
see anything out of the ordinary. How can I fix/verify the upgrade?

Thanks!

--Andrew


Hello,

can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for
more specific errors?

Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time of 
the upgrade:

[01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation 
threads - op stack size 84 max work q size 59 max work q stack size 59
[01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled
[01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting up
[01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B is 
less than db size 28639232B; We recommend to increase the entry cache size 
nsslapd-cachememsize.
[01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time Directory 
Server was running, recovering database.
...
tion.
[01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - 
_cl5NewDBFile: PR_DeleteSemaphore: 
/var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema;
 NSPR error - -5943
[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - 
_cl5NewDBFile: PR_DeleteSemaphore: 
/var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema;
 NSPR error - -5943
[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. 
Check if DB RUV needs to be updated
[01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial credentials 
for principal [ldap/srv-d13-39-02.int.ccr.buffalo@int.ccr.buffalo.edu] in 
keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" 
(srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to go into 
backoff mode. Will retry later.
[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
replica_check_for_data_reload: Warning: disordely shutdown for replica 
dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated
[01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could 
not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local 
error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
Minor code may provide more information (No Kerberos credentials available)) 
errno 0 (Success)
...
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22231 (rc: 32)
[01/Oct/2015:10:45:09 -0400] - slapd started.  Listening on 
/var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22232 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22233 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22234 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22235 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22236 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22237 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22238 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22239 (rc: 32)
[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could not 
delete change record 22240 (rc: 32)
..


These delete_changerecord are repeated all the way to 321722.


Here's the errors from /var/log/ipaupgrade.log


2015-10-01T14:44:49Z DEBUG   [4/10]: starting directory server
2015-10-01T14:44:49Z DEBUG Starting external process
2015-10-01T14:44:49Z DEBUG args='/bin/systemctl' 'start' 
'dirsrv@INT-CCR-BUFFALO-EDU.service'
2015-10-01T14:44:50Z DEBUG Process finished, return code=0
2015-10-01T14:44:50Z DEBUG stdout=
2015-10-01T14:44:50Z DEBUG stderr=
2015-10-01T14:44:50Z DEBUG   duration: 0 seconds
2015-10-01T14:44:50Z DEBUG   [5/10]:

Re: [Freeipa-users] Trust Issues W/ Logins on Windows Desktops

2015-10-01 Thread Simo Sorce 

On 01/10/15 03:15, Petr Spacek wrote:

On 30.9.2015 20:36, Matt Wells wrote:

Hi all, I hoped I may glean some brilliance from the group.
I have a Freeipa Server sitting atop a Fedora 21 server.  The initial plan
was to replicate users+passwords with Windows 2012R2 server but following
some of the information in the other posts and docs we've moved to a
trust.  The trust has been setup using the documentation and in short it's
worked without issue.  I'm able to get principles from the Windows realm (
marvel.comics.com).  So what I'm attempting and failing to do is
authenticating my IPA users to the Windows 8 desktops.  Ideally I don't
want any users in AD, it's simply there to deliver a GPO and in the next
year it will be phased out and we'll be replacing Windows 8 with linux
desktops.

So
marvel.comics.com = windows
dc.comics.com = freeipa

# rpm -qi freeipa-server
Name: freeipa-server
Version : 4.1.4
Release : 1.fc21
Architecture: x86_64
Install Date: Tue 25 Aug 2015 08:17:56 PM UTC
Group   : System Environment/Base
Size: 4521059
License : GPLv3+
Signature   : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID
89ad4e8795a43f54
Source RPM  : freeipa-4.1.4-1.fc21.src.rpm
Build Date  : Thu 26 Mar 2015 03:16:19 PM UTC
Build Host  : buildhw-07.phx2.fedoraproject.org
[root@freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a
Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17
22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release
Fedora release 21 (Twenty One)

To cut to the chase here's me logging into a Windows 8 desktop system.  I
try to login 3 different ways; this system is a member of the marvel
domain.  Time is extremely close, close enough that I feel really good
about ruling it out.  Any light you all could shed on this would be
outstanding.  Thank you all for your time on this, I really appreciate all
the time and effort this team puts into reading these posts.

Username: dc/greenlantern
Password: 

[root@freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i
greenlantern
[30/Sep/2015:17:55:33 +] conn=1172 op=46 SRCH
base="dc=dc,dc=comics,dc=com" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern@dc
)(krbPrincipalName=greenlantern@dc)))" attrs="krbPrincipalName
krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
objectClass"

Username: greenlanter@dc
Password: 


[30/Sep/2015:17:59:48 +] conn=1172 op=86 SRCH
base="dc=dc,dc=comics,dc=com" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern@dc
)(krbPrincipalName=greenlantern@dc)))" attrs="krbPrincipalName
krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
objectClass"


Username: greenlan...@dc.comics.com
Password: 

[30/Sep/2015:17:59:35 +] conn=1172 op=84 SRCH
base="dc=dc,dc=comics,dc=com" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5...@dc.comics.com
@DC.COMICS.COM 
)(krbPrincipalName=greenlantern\5...@dc.comics.com@DC.COMICS.COM
)))" attrs="krbPrincipalName krbCanonicalName
ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType ipatokenRadiusConfigLink objectClass"


>From what I can tell, everything looks good to wbinfo; we see the domain
and he see's us.  In the AD trust I can go under the trust and validate the
trust with no issues.
[root@freeipaServer slapd-MARVEL-COMICS-COM]#  wbinfo --online-status
BUILTIN : online
DC : online
MARVEL : online

Re: [Freeipa-users] ipa upgrade failed

2015-10-01 Thread Andrew E. Bruno 
On Thu, Oct 01, 2015 at 05:40:34PM +0200, Martin Basti wrote:
> 
> 
> On 10/01/2015 05:28 PM, Andrew E. Bruno wrote:
> >On Thu, Oct 01, 2015 at 05:09:23PM +0200, Martin Basti wrote:
> >>
> >>On 10/01/2015 05:03 PM, Andrew E. Bruno wrote:
> >>>Running CentOS 7.1.1503.
> >>>
> >>>Upgrading via yum update from:
> >>>
> >>>   ipa-server.x86_64 0:4.1.0-18.el7.centos.3
> >>>
> >>>   --to--
> >>>
> >>>   ipa-server.x86_64 0:4.1.0-18.el7.centos.4
> >>>
> >>>We have 3 replicates. Upgrading the first replicate (first-master) went
> >>>fine. Upgrading the second replicate failed.
> >>>
> >>>Got the following error during the update on the second replicate:
> >>>
> >>>Pre schema upgrade failed with [Errno 111] Connection refused
> >>>IPA upgrade failed.
> >>>
> >>>Where should I look for more info? Looked in the usual places and didn't
> >>>see anything out of the ordinary. How can I fix/verify the upgrade?
> >>>
> >>>Thanks!
> >>>
> >>>--Andrew
> >>>
> >>Hello,
> >>
> >>can you check /var/log/ipaupgrade.log and /var/log/dirsrv/slapd-*/errors for
> >>more specific errors?
> >Here's the errors from /var/log/dirsrv/slapd-*/errors right around the time 
> >of the upgrade:
> >
> >[01/Oct/2015:10:42:37 -0400] - slapd shutting down - signaling operation 
> >threads - op stack size 84 max work q size 59 max work q stack size 59
> >[01/Oct/2015:10:44:50 -0400] - Information: Non-Secure Port Disabled
> >[01/Oct/2015:10:44:50 -0400] - 389-Directory/1.3.3.1 B2015.218.023 starting 
> >up
> >[01/Oct/2015:10:44:50 -0400] - WARNING: changelog: entry cache size 512000B 
> >is less than db size 28639232B; We recommend to increase the entry cache 
> >size nsslapd-cachememsize.
> >[01/Oct/2015:10:44:50 -0400] - Detected Disorderly Shutdown last time 
> >Directory Server was running, recovering database.
> >...
> >tion.
> >[01/Oct/2015:10:45:03 -0400] NSMMReplicationPlugin - changelog program - 
> >_cl5NewDBFile: PR_DeleteSemaphore: 
> >/var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/9fc73292-2b0911e5-a53bd3a1-f3bbc58c.sema;
> > NSPR error - -5943
> >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - changelog program - 
> >_cl5NewDBFile: PR_DeleteSemaphore: 
> >/var/lib/dirsrv/slapd-INT-CCR-BUFFALO-EDU/cldb/d0a7671e-2b0911e5-a53bd3a1-f3bbc58c.sema;
> > NSPR error - -5943
> >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
> >replica_check_for_data_reload: Warning: disordely shutdown for replica 
> >o=ipaca. Check if DB RUV needs to be updated
> >[01/Oct/2015:10:45:08 -0400] set_krb5_creds - Could not get initial 
> >credentials for principal 
> >[ldap/srv-d13-39-02.int.ccr.buffalo@int.ccr.buffalo.edu] in keytab 
> >[FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
> >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
> >agmt="cn=cloneAgreement1-srv-d13-39-02.int.ccr.buffalo.edu-pki-tomcat" 
> >(srv-d13-38-02:389): Unable to acquire replica: the replica instructed us to 
> >go into backoff mode. Will retry later.
> >[01/Oct/2015:10:45:08 -0400] NSMMReplicationPlugin - 
> >replica_check_for_data_reload: Warning: disordely shutdown for replica 
> >dc=int,dc=ccr,dc=buffalo,dc=edu. Check if DB RUV needs to be updated
> >[01/Oct/2015:10:45:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could 
> >not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local 
> >error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  
> >Minor code may provide more information (No Kerberos credentials available)) 
> >errno 0 (Success)
> >...
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22231 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] - slapd started.  Listening on 
> >/var/run/slapd-INT-CCR-BUFFALO-EDU.socket for LDAPI requests
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22232 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22233 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22234 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22235 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22236 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22237 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22238 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22239 (rc: 32)
> >[01/Oct/2015:10:45:09 -0400] DSRetroclPlugin - delete_changerecord: could 
> >not delete change record 22240 (rc: 32)
> >..
> >
> >
> >These delete_changerecord are repeated all the way to 321722.
> >
> >
> >Here's the errors from /var/log/ipaupgrade.log
>

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

2015-10-01 Thread Rob Crittenden 
Dominik Korittki wrote:
> Hello folks,
> 
> I am running two FreeIPA Servers with around 100 users and around 15.000
> hosts, which are used by users to login via ssh. The FreeIPA servers
> (which are Centos 7.0) ran good for a while, but as more and more hosts
> got migrated to serve as FreeIPA hosts, it started to get slow and
> unstable.
> 
> For example, its hard to maintain hostgroups, which have more than 1.000
> hosts. The ipa host-* commands are getting slower as the hostgroup
> grows. Is this normal?

You mean the ipa hostgroup-* commands? Whenever the entry is displayed
(show and add) it needs to dereference all members so yes, it is
understandable that it gets somewhat slower with more members. How slow
are we talking about?

> We also experience random dirsrv segfaults. Here's a dmesg line from the
> latest:
> 
> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]

You probably want to start here:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes


> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
> problem.
> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
> solve my problems?
> 
> FreeIPA server version is 3.3.3-28.el7.centos
> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0
> 
> 
> 
> Kind regards,
> Dominik Korittki
> 

-- 
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] Trust Issues W/ Logins on Windows Desktops

2015-10-01 Thread Petr Spacek 
On 30.9.2015 20:36, Matt Wells wrote:
> Hi all, I hoped I may glean some brilliance from the group.
> I have a Freeipa Server sitting atop a Fedora 21 server.  The initial plan
> was to replicate users+passwords with Windows 2012R2 server but following
> some of the information in the other posts and docs we've moved to a
> trust.  The trust has been setup using the documentation and in short it's
> worked without issue.  I'm able to get principles from the Windows realm (
> marvel.comics.com).  So what I'm attempting and failing to do is
> authenticating my IPA users to the Windows 8 desktops.  Ideally I don't
> want any users in AD, it's simply there to deliver a GPO and in the next
> year it will be phased out and we'll be replacing Windows 8 with linux
> desktops.
> 
> So
> marvel.comics.com = windows
> dc.comics.com = freeipa
> 
> # rpm -qi freeipa-server
> Name: freeipa-server
> Version : 4.1.4
> Release : 1.fc21
> Architecture: x86_64
> Install Date: Tue 25 Aug 2015 08:17:56 PM UTC
> Group   : System Environment/Base
> Size: 4521059
> License : GPLv3+
> Signature   : RSA/SHA256, Thu 26 Mar 2015 10:58:02 PM UTC, Key ID
> 89ad4e8795a43f54
> Source RPM  : freeipa-4.1.4-1.fc21.src.rpm
> Build Date  : Thu 26 Mar 2015 03:16:19 PM UTC
> Build Host  : buildhw-07.phx2.fedoraproject.org
> [root@freeipaServer slapd-DEV-MOSAIC451-COM]# uname -a
> Linux freeipaServer.dc.comics.com 4.1.6-100.fc21.x86_64 #1 SMP Mon Aug 17
> 22:20:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> [root@freeipaServer slapd-DEV-MOSAIC451-COM]# cat /etc/redhat-release
> Fedora release 21 (Twenty One)
> 
> To cut to the chase here's me logging into a Windows 8 desktop system.  I
> try to login 3 different ways; this system is a member of the marvel
> domain.  Time is extremely close, close enough that I feel really good
> about ruling it out.  Any light you all could shed on this would be
> outstanding.  Thank you all for your time on this, I really appreciate all
> the time and effort this team puts into reading these posts.
> 
> Username: dc/greenlantern
> Password: 
> 
> [root@freeipaServer slapd-DC-COMICS-COM]# tail -f * | egrep --color -i
> greenlantern
> [30/Sep/2015:17:55:33 +] conn=1172 op=46 SRCH
> base="dc=dc,dc=comics,dc=com" scope=2
> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern@dc
> )(krbPrincipalName=greenlantern@dc)))" attrs="krbPrincipalName
> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
> passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
> objectClass"
> 
> Username: greenlanter@dc
> Password: 
> 
> 
> [30/Sep/2015:17:59:48 +] conn=1172 op=86 SRCH
> base="dc=dc,dc=comics,dc=com" scope=2
> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern@dc
> )(krbPrincipalName=greenlantern@dc)))" attrs="krbPrincipalName
> krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey
> krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration
> krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange
> krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth
> krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences
> krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock
> passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink
> objectClass"
> 
> 
> Username: greenlan...@dc.comics.com
> Password: 
> 
> [30/Sep/2015:17:59:35 +] conn=1172 op=84 SRCH
> base="dc=dc,dc=comics,dc=com" scope=2
> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=greenlantern\5...@dc.comics.com
> @DC.COMICS.COM 
> )(krbPrincipalName=greenlantern\5...@dc.comics.com@DC.COMICS.COM
> )))" attrs="krbPrincipalName krbCanonicalName
> ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference
> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
> ipaUserAuthType ipatokenRadiusConfigLink objectClass"
> 
> 
>>From what I can tell, everything looks good to wbinfo; we see the domain
> and he see's us.  In the AD trust I can go under the trust

[Freeipa-users] FreeIPA install

2015-10-01 Thread Andrew Meyer 
I just created a new FreeIPA setup at my home and i'm getting the following:
[Thu Oct 01 14:02:10.082255 2015] [core:notice] [pid 18792] AH00094: Command 
line: '/usr/sbin/httpd -D FOREGROUND'
[Thu Oct 01 14:02:14.742680 2015] [:error] [pid 18795] ipa: INFO: *** PROCESS 
START ***
[Thu Oct 01 14:02:14.745250 2015] [:error] [pid 18794] ipa: INFO: *** PROCESS 
START ***
[Thu Oct 01 14:02:42.984969 2015] [:error] [pid 18798] SSL Library Error: 
-12271 SSL client cannot verify your certificate
[Thu Oct 01 15:21:56.837422 2015] [:error] [pid 18801] SSL Library Error: 
-12271 SSL client cannot verify your certificate

I tried running the ipa-manage-cacert to generate a new one and install it.  
But no go.
Running CentOS 7.1 with latest updates.  Is there a bug in generating the SSL 
cert?

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

2015-10-01 Thread TomK 



On 10/1/2015 12:04 PM, Simo Sorce wrote:

On 30/09/15 21:22, TomK wrote:



On 9/30/2015 8:12 AM, Martin Kosek wrote:

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the
freeipa-users
mailing list so not sure if the other message will get posted.)

Before I post a ticket to RH Support for an RFE, I'll post the
request here
to get some feedback on options and what ideas folks have.  I've a
situation
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper
RFC for
LDAP.  With SSSD rules I can define the rules to read the user 'host'
attribute but not the group 'host' attribute:


|access_provider = ldap ldap_access_order = host
ldap_user_authorized_host =
host|


Essentially TomK to be given access to hosts listed in the 'host'
attribute
but denied entry into lab05 for example (not listed in any group 
'host'

attribute above) to the server.   If I have a new user that has
joined that
particular team at our organization, I can simply add her/him to the
above
groups and this user would get access only to the listed servers in
'host'
attribute by default. I don't need to specify new groups in 
customized

sssd.conf or ldap.conf files or in sshd config files. Hence less to
update
with Salt or any other CM suite.  I've managed to setup SUDO rules
and with
the openssh-ldap.diff schema SSH public keys could be stored in AD
as well
and be read by OpenSSH.  So aside from the HBAC capability on groups,
virtually all our needs are handled by the WS2012 AD DC as it has to
follow
the OpenLDAP standard anyway.  Now to get this we considered and are
still
considering FreeIPA.  However this idea poses a set of challenges:

1) In large organizations where the AD support department are only
trained in
Windows AD setup and configuration (Only windows guy's) this would
require a
minimal of 3 bodies to support that know LDAP/Linux.  This is a
large cost.

2) The additional server requires the same hardening as the Windows
AD DC
servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA

servers to be supported, hardened and maintained (upgraded).

Now I probably sound somewhat anti-FreeIPA, however the challenges of
implementing it in large organizations surface after some
deliberation, so
probably better to list then as it may help direct development of
the product
to contend with the challenges (Like having a document fully
dedicated to
hardening a FreeIPA server with selinux and other technologies in
easy to
maintain configuration).   I could be mistaken but some folks
mention that
it's 'better' to implement this sort of HBAC through other means (??
iptables
??) but never tried the alternatives yet.

So, cutting to the end, would it be possible to add an attribute 
like:


|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to
enable
reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups 
and

then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html 




More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups 




I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin


We already defined HBAC rules in the manner that all the links you
pointed out indicate as an early implementation.  As a product, there is
no issue in IDM from that perspective.  This is all great and the
product is fine from that perspective.

It would be good to have a dual option of either allowing SSSD or IDM /
FreeIPA have full HBAC capability not just FreeIPA / IDM as in our
organization that would be a huge cost savings vs implementing IDM as a
separate Linux DC to be managed by a separate team.  So for those
customers that wish to go directly to AD or have already invested in AD
can choose SSSD only (If MS bundles AD with certain purchases, for
example, that is an actual cost savings for a company).  Other customers
who wish to keep the two separate so they do not flood AD DC's with non
Windows AD settings can integrate IDM.

There will be cases where there could be a potential to save on costs vs
AD so the Linux IDM