Re: [Freeipa-users] ipa-server-install ERROR: IPA CA certificate not found in ...

2016-08-23 Thread Zarko Dudic 



On 8/16/2016 11:09 AM, Alexander Bokovoy wrote:

On Tue, 16 Aug 2016, Zarko Dudic wrote:

Thanks Rob. This command creates the CSR.

# ipa-server-install  --subject 
'OU=CorpArch,O=Corporation,L=Town,ST=California,C=US' --external-ca


And verification with command :

# openssl req -in /root/ipa.csr -noout -text

... shows "Subject: C=US, ST=California, L=Town, O=Corporation, 
OU=CorpArch, CN=Certificate Authority"


Since the CN is unconfigurable, how it's expected to be signed by 3rd 
party external CA, they usually want to see FQDN.

This is not a certificate signing request for a host-based certificate.
This is a certificate signing request for a CA root certificate. It is
unlikely that you will get it signed by a public CA because that
signature basically makes your IPA CA a sub-CA.



Hi Alexander,
It makes sense what you say here, I was trying this because the doc 
"Linux Domain Identity, Authentication, and Policy Guide" in the  " 
2.3.2. Determining What CA Configuration to Use" reads:


An external CA is the root CA

The Certificate System CA is subordinate to an external CA.
However, all certificates for the IdM domain are still issued by the 
Certificate System instance.
The external CA can be a corporate CA or a third-party CA, such as 
Verisign or Thawte.
The certificates issued within the IdM domain are potentially subject to 
restrictions set by the external root CA for attributes like the 
validity period.







This is quite different from signing a server certificate.

--external-ca option is provided to allow your IPA CA to be a sub-ca for
a corporate CA. I don't know any publicly available CA that could
actually sign it for you.



--
Thanks,
Zarko

--
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] Default gid for AD trust users

2016-08-23 Thread Orion Poplawski 
Is there any way to control the default gid for AD trust users?  At the moment
each user has it's own default group, e.g.:

uid=22603(user@ad.domain) gid=22603(user@ad.domain)

It would be nice to be able to set this to an actual group.

Thanks.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.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

[Freeipa-users] Two masters and one of them is desynchronized

2016-08-23 Thread bahan w 
Hello !

I am using IPA 3.0.0 on RedHat 6.6 servers.

I have two masters and this evening, I realized that one of them was
desynchronized, some users and groups were missing.

I was wondering if there was an ipa command to resynchronize replica which
are not sync with the other ?

Thank you in advance for your help.

Best regards.

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

[Freeipa-users] The 3rd party cert for IPA Web GUI

2016-08-23 Thread Z D 
Hi there, is it possible to have a cert (say from VeriSign) for a IPA host and 
use it for httpd (Web GUI), without breaking anything else? I've acquired one 
and added it to nssdb (/etc/httpd/alias).


# certutil -L -d /etc/httpd/alias
Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI
ipaCert  u,u,u
Server-Cert  u,u,u
COMP.COM IPA CA CT,C,C
Signing-Cert u,u,u
CA-LDAP01-CHAINEDu,u,u
Comp SSL CA - G2 - VeriSign, Inc.  ,,

It's now used in /etc/httpd/conf.d/nss.conf and the cert looks good via a 
browser. But it's breaking something, since I see this:

# ipa user-show admin
ipa: ERROR: cert validation failed for 
"CN=ca-ldap01.comp.com,OU=Corp,O=Corporation,L=City,ST=California,C=US" 
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by the user.)
ipa: ERROR: cannot connect to 'https://ca-ldap01.comp.com/ipa/json': 
(SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by the user.


Adding this cert to /etc/dirsrv/slapd-CORP-COM/ nssdb didn't resolve the issue. 
Thanks for any advice.

Zarko
-- 
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] Deleting a duplicate user

2016-08-23 Thread Alexander Bokovoy 

On Tue, 23 Aug 2016, Alexander Bokovoy wrote:

On Tue, 23 Aug 2016, Zak Wolfinger wrote:

We were in the final stages of migrating FreeIPA from 3.0 to 4.2.
During the migration, both the 3.0 replicas and the 4.2 replicas were
in the replica pool.  User account changes made to 3.0 would replicate
to 4.2 just fine, but changes wouldn’t replicate from 4.2 to 3.0.

Admins should have been aware of this and performing all changes to the
3.0 replicas.  However 2 accounts were created on the 4.2 replicas and
then also added to the 3.0 replicas.  This resulted in a replication
conflict and each user account has a duplicate with the same username
but different UIDs.

I want to delete the duplicates.  “ipa user-del” will not take the UID
as an identifier, only the username.  Using just the username fails
with an error due to the duplicate accounts.

The old 3.0 replicas have all been removed from the pool and
decommissioned.  It would be tons of work to bring them back into
production.

Any thoughts on how to fix this issue?

You can delete wrong entry using ldapdelete.

Search for the records with 'ipa user-find' first:

[root ipa]# ipa user-find --all --raw --login myuser | grep dn:
dn: 
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=myuser,cn=users,cn=accounts,dc=,dc=exampe,dc=com

This gives you a DN of the conflict entry. Now you can delete it with
ldapdelete:

[root ipa]# ldapdelete -Y GSSPAI 
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=myuser,cn=users,cn=accounts,dc=,dc=exampe,dc=com

s/GSSPAI/GSSAPI/, of course.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Deleting a duplicate user

2016-08-23 Thread Alexander Bokovoy 

On Tue, 23 Aug 2016, Zak Wolfinger wrote:

We were in the final stages of migrating FreeIPA from 3.0 to 4.2.
During the migration, both the 3.0 replicas and the 4.2 replicas were
in the replica pool.  User account changes made to 3.0 would replicate
to 4.2 just fine, but changes wouldn’t replicate from 4.2 to 3.0.

Admins should have been aware of this and performing all changes to the
3.0 replicas.  However 2 accounts were created on the 4.2 replicas and
then also added to the 3.0 replicas.  This resulted in a replication
conflict and each user account has a duplicate with the same username
but different UIDs.

I want to delete the duplicates.  “ipa user-del” will not take the UID
as an identifier, only the username.  Using just the username fails
with an error due to the duplicate accounts.

The old 3.0 replicas have all been removed from the pool and
decommissioned.  It would be tons of work to bring them back into
production.

Any thoughts on how to fix this issue?

You can delete wrong entry using ldapdelete.

Search for the records with 'ipa user-find' first:

[root ipa]# ipa user-find --all --raw --login myuser | grep dn:
 dn: 
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=myuser,cn=users,cn=accounts,dc=,dc=exampe,dc=com

This gives you a DN of the conflict entry. Now you can delete it with
ldapdelete:

[root ipa]# ldapdelete -Y GSSPAI 
nsuniqueid=ef3d3a81-2e3111e4-8c13b928-a98b9061+uid=myuser,cn=users,cn=accounts,dc=,dc=exampe,dc=com

--
/ 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] Deleting a duplicate user

2016-08-23 Thread Zak Wolfinger 
We were in the final stages of migrating FreeIPA from 3.0 to 4.2.  During the 
migration, both the 3.0 replicas and the 4.2 replicas were in the replica pool. 
 User account changes made to 3.0 would replicate to 4.2 just fine, but changes 
wouldn’t replicate from 4.2 to 3.0.

Admins should have been aware of this and performing all changes to the 3.0 
replicas.  However 2 accounts were created on the 4.2 replicas and then also 
added to the 3.0 replicas.  This resulted in a replication conflict and each 
user account has a duplicate with the same username but different UIDs.

I want to delete the duplicates.  “ipa user-del” will not take the UID as an 
identifier, only the username.  Using just the username fails with an error due 
to the duplicate accounts.

The old 3.0 replicas have all been removed from the pool and decommissioned.  
It would be tons of work to bring them back into production.

Any thoughts on how to fix this issue?

Cheers,
Zak Wolfinger

Infrastructure Engineer  |  Emma®
zak.wolfin...@myemma.com 
800.595.4401 or 615.292.5888 x197
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at www.myemma.com 



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

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

2016-08-23 Thread Rakesh Rajasekharan 
I think thers something seriously wrong with my system

not able to run any  IPA commands

klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@xyz.com

Valid starting   Expires  Service principal
2016-08-23T16:26:36  2016-08-24T16:26:22  krbtgt/xyz@xyz.com


[root@prod-ipa-master-1a :~] ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful



[root@prod-ipa-master :~] ipa user-find p-testuser
ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may
provide more information', 851968)/("Cannot contact any KDC for realm '
XYZ.COM'", -1765328228)



Thanks

Rakesh

On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
rakesh.rajasekha...@gmail.com> wrote:

> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
>
> But, the hang is still there. though I dont see the sigfault now
>
>
>
>
> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
>
>> My disk was getting filled too fast
>>
>> logs under /var/log/dirsrv was coming around 5 gb quickly filling up
>>
>> Is there a way to make the logging less verbose
>>
>>
>>
>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek  wrote:
>>
>>> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
>>> > I was able to fix that may be temporarily... when i checked the
>>> network..
>>> > there was another process that was running and consuming a lot of
>>> network (
>>> > i have no idea who did that. I need to seriously start restricting
>>> people
>>> > access to this machine )
>>> >
>>> > after killing that perfomance improved drastically
>>> >
>>> > But now, suddenly I started experiencing the same hang.
>>> >
>>> > This time , I gert the following error when checked dmesg
>>> >
>>> > [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
>>> > 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
>>> > [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
>>> > Sending cookies.  Check SNMP counters.
>>> > [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
>>> > 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
>>> > [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
>>> > 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>>>
>>> Okay, this one is serious. The LDAP server crashed.
>>>
>>> 1. Make sure all your packages are up-to-date.
>>>
>>> Please see
>>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>>> ebugging-crashes
>>> for further instructions how to debug this.
>>>
>>> Petr^2 Spacek
>>>
>>> >
>>> > and in /var/log/dirsrv/example-com/errors
>>> >
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291138 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291139 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291140 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291141 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291142 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291143 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291144 (rc: 32)
>>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3291145 (rc: 32)
>>> > [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
>>> > [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord:
>>> could
>>> > not delete change record 3292734 (rc: 51)
>>> >
>>> >
>>> > Can  i do something about this error.. I treid to restart ipa a couple
>>> of
>>> > time but that did not help
>>> >
>>> > Thanks
>>> > Rakesh
>>> >
>>> > On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek 
>>> wrote:
>>> >
>>> >> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>> >>> I am running my set up on AWS cloud, and entropy is low at around
>>> 180 .
>>> >>>
>>> >>> I plan to increase it bu installing haveged . But, would low entropy
>>> by
>>> >> any
>>> >>> chance cause this issue of intermittent hang .
>>> >>> Also, the hang is mostly observed when registering around 20 clients
>>> >>> together
>>> >>
>>> >> Possibly, I'm not sure. If you want to dig into this, I would do this:
>>> >> 1. look what process hangs on client (using pstree command or so)
>>> >> $ pstree
>>> >>
>>> >> 2. look to what server and port is the hanging

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

2016-08-23 Thread Rakesh Rajasekharan 
i changed the loggin level to 4 . Modifying nsslapd-accesslog-level

But, the hang is still there. though I dont see the sigfault now




On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
rakesh.rajasekha...@gmail.com> wrote:

> My disk was getting filled too fast
>
> logs under /var/log/dirsrv was coming around 5 gb quickly filling up
>
> Is there a way to make the logging less verbose
>
>
>
> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek  wrote:
>
>> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
>> > I was able to fix that may be temporarily... when i checked the
>> network..
>> > there was another process that was running and consuming a lot of
>> network (
>> > i have no idea who did that. I need to seriously start restricting
>> people
>> > access to this machine )
>> >
>> > after killing that perfomance improved drastically
>> >
>> > But now, suddenly I started experiencing the same hang.
>> >
>> > This time , I gert the following error when checked dmesg
>> >
>> > [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
>> > 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
>> > [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
>> > Sending cookies.  Check SNMP counters.
>> > [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
>> > 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
>> > [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
>> > 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>>
>> Okay, this one is serious. The LDAP server crashed.
>>
>> 1. Make sure all your packages are up-to-date.
>>
>> Please see
>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#
>> debugging-crashes
>> for further instructions how to debug this.
>>
>> Petr^2 Spacek
>>
>> >
>> > and in /var/log/dirsrv/example-com/errors
>> >
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291138 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291139 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291140 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291141 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291142 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291143 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291144 (rc: 32)
>> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3291145 (rc: 32)
>> > [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
>> > [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord:
>> could
>> > not delete change record 3292734 (rc: 51)
>> >
>> >
>> > Can  i do something about this error.. I treid to restart ipa a couple
>> of
>> > time but that did not help
>> >
>> > Thanks
>> > Rakesh
>> >
>> > On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek 
>> wrote:
>> >
>> >> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>> >>> I am running my set up on AWS cloud, and entropy is low at around 180
>> .
>> >>>
>> >>> I plan to increase it bu installing haveged . But, would low entropy
>> by
>> >> any
>> >>> chance cause this issue of intermittent hang .
>> >>> Also, the hang is mostly observed when registering around 20 clients
>> >>> together
>> >>
>> >> Possibly, I'm not sure. If you want to dig into this, I would do this:
>> >> 1. look what process hangs on client (using pstree command or so)
>> >> $ pstree
>> >>
>> >> 2. look to what server and port is the hanging client connected to
>> >> $ lsof -p 
>> >>
>> >> 3. jump to server and see what process is bound to the target port
>> >> $ netstat -pn
>> >>
>> >> 4. see where the process if hanging
>> >> $ strace -p 
>> >>
>> >> I hope it helps.
>> >>
>> >> Petr^2 Spacek
>> >>
>> >>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
>> >>> rakesh.rajasekha...@gmail.com> wrote:
>> >>>
>>  yes there seems to be something thats worrying.. I have faced this
>> today
>>  as well.
>>  There are few hosts around 280 odd left and when i try adding them to
>> >> IPA
>>  , the slowness begins..
>> 
>>  all the ipa commands like ipa user-find.. etc becomes very slow in
>>  responding.
>> 
>>  the SYNC_RECV are not many though just around 80-90 and today that
>> was
>>  around 20 only
>> 
>> 
>>  I have for now increased tcp_max_syn_backlog to 5000.
>>  For now the slowness seems to have gone.. but I will do a try adding
>> the
>>  clients again tomorrow and see how it

[Freeipa-users] IPA to IPA trust

2016-08-23 Thread Andrey Ptashnik 
Hello IPA team,

Is there a way to implement IPA to IPA trust between different domains?
We are thinking of using more than one domain, however we will need users to 
cross login from one domain to another.

Regards,
Andrey

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

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

2016-08-23 Thread Rakesh Rajasekharan 
My disk was getting filled too fast

logs under /var/log/dirsrv was coming around 5 gb quickly filling up

Is there a way to make the logging less verbose



On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek  wrote:

> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
> > I was able to fix that may be temporarily... when i checked the network..
> > there was another process that was running and consuming a lot of
> network (
> > i have no idea who did that. I need to seriously start restricting people
> > access to this machine )
> >
> > after killing that perfomance improved drastically
> >
> > But now, suddenly I started experiencing the same hang.
> >
> > This time , I gert the following error when checked dmesg
> >
> > [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
> > 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
> > [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
> > Sending cookies.  Check SNMP counters.
> > [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
> > 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
> > [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
> > 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>
> Okay, this one is serious. The LDAP server crashed.
>
> 1. Make sure all your packages are up-to-date.
>
> Please see
> http://directory.fedoraproject.org/docs/389ds/
> FAQ/faq.html#debugging-crashes
> for further instructions how to debug this.
>
> Petr^2 Spacek
>
> >
> > and in /var/log/dirsrv/example-com/errors
> >
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291138 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291139 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291140 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291141 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291142 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291143 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291144 (rc: 32)
> > [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3291145 (rc: 32)
> > [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
> > [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord: could
> > not delete change record 3292734 (rc: 51)
> >
> >
> > Can  i do something about this error.. I treid to restart ipa a couple of
> > time but that did not help
> >
> > Thanks
> > Rakesh
> >
> > On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek  wrote:
> >
> >> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
> >>> I am running my set up on AWS cloud, and entropy is low at around 180 .
> >>>
> >>> I plan to increase it bu installing haveged . But, would low entropy by
> >> any
> >>> chance cause this issue of intermittent hang .
> >>> Also, the hang is mostly observed when registering around 20 clients
> >>> together
> >>
> >> Possibly, I'm not sure. If you want to dig into this, I would do this:
> >> 1. look what process hangs on client (using pstree command or so)
> >> $ pstree
> >>
> >> 2. look to what server and port is the hanging client connected to
> >> $ lsof -p 
> >>
> >> 3. jump to server and see what process is bound to the target port
> >> $ netstat -pn
> >>
> >> 4. see where the process if hanging
> >> $ strace -p 
> >>
> >> I hope it helps.
> >>
> >> Petr^2 Spacek
> >>
> >>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
> >>> rakesh.rajasekha...@gmail.com> wrote:
> >>>
>  yes there seems to be something thats worrying.. I have faced this
> today
>  as well.
>  There are few hosts around 280 odd left and when i try adding them to
> >> IPA
>  , the slowness begins..
> 
>  all the ipa commands like ipa user-find.. etc becomes very slow in
>  responding.
> 
>  the SYNC_RECV are not many though just around 80-90 and today that was
>  around 20 only
> 
> 
>  I have for now increased tcp_max_syn_backlog to 5000.
>  For now the slowness seems to have gone.. but I will do a try adding
> the
>  clients again tomorrow and see how it goes
> 
>  Thanks
>  Rakesh
> 
>  The issues
> 
>  On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek 
> >> wrote:
> 
> > On 18.8.2016 17:23, Rakesh Rajasekharan wrote:
> >> Hi
> >>
> >> I am migrating to freeipa from openldap and have around 4000 clients
> >>
> >> I had openned a another thread on that, but chose to start a new one
>

Re: [Freeipa-users] can't get sudo to work.

2016-08-23 Thread Rob Crittenden 

Pavel Březina wrote:

On 08/23/2016 01:55 PM, Tony Brian Albers wrote:

Here you are:


[root ~]# ldapsearch -Y GSSAPI -b $dc
'(ou=*)' -s onelevel



# profile, $domain
dn: ou=profile,$dc
objectClass: top
objectClass: organizationalUnit
ou: profiles
ou: profile

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1



Sudo rules are not downloaded by SSSD because ou=sudoers is missing on
the IPA server, or it may have incorrect ACL. Does someone from IPA team
know why?


Perhaps the compat tree is disabled:

$ ipa-compat-manage status

rob


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

Re: [Freeipa-users] IPA Error 4301: CertificateOperationError

2016-08-23 Thread Rob Crittenden 

Fraser Tweedale wrote:

On Mon, Aug 22, 2016 at 11:52:46PM +, Z D wrote:

Hello,

There is the error on ver 4.2 while viewing certs: "IPA Error
4301: CertificateOperationError", next it read " Certificate
operation cannot be completed: Unable to communicate with CMS
([Errno 113] No route to host)".

I suspect you'll be asking for below two commands, here are results.

# ipa cert-show 1
   Certificate: MIIDlzCCAn+gAwIBAgIBATANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1VUy5P
..shortened ...
H6S7tS4pT9w77K8=
   Subject: CN=Certificate Authority,O=COMP.COM
   Issuer: CN=Certificate Authority,O=COMP.COM
   Not Before: Wed Aug 17 17:20:41 2016 UTC
   Not After: Sun Aug 17 17:20:41 2036 UTC
   Fingerprint (MD5): 00:a5:2c:2d:ea:c8:27:33:62:35:75:53:12:6a:0d:c1
   Fingerprint (SHA1): 
d1:58:78:83:31:b8:ad:ae:af:2c:e7:05:44:67:6e:3a:37:8c:00:1a
   Serial number (hex): 0x1
   Serial number: 1

# ipactl restart
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting ipa_memcached Service
Restarting httpd Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful

Any help is appreciated, thanks
Zarko



"while viewing certs" -> do you mean in the IPA Web UI?

The successful `cert-show' command indicates that the CA is up and
running, but the error message indicates that the host running the
failing action cannot contact the CA.  You should check DNS and
firewall settings as a first step.


If a request for a certificate operation comes into an IPA master that 
isn't running a CA the request is sent to one that does. It sure seems 
like that is happening in this case and the chosen CA isn't available.


rob

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

Re: [Freeipa-users] private user groups for existing users

2016-08-23 Thread Rob Crittenden 

siology.io wrote:

  i've noticed that some of my users (imported from openldap) don't have
personal user groups, but the new ones that i make within freeipa do.

Is there a way of marking the existing accounts such that they get user
groups made for them ? I couldn't seem to see the groups that IPA is
making in the LDAP output so it must be creating them via some other means.

Is there some sort of  'ipa user create-private-group ' command ?

The only work around i have is to make hundreds of fake private groups
by making normal user groups each with one user, which'll clutter the UI
up with pointless groups.


Yeah, there is a ticket open to allow UPG creation in migration but as 
you see, it isn't done yet.


There is no documented way to do it but it should be possible with 
ldapmodify. I forget the exact ordering but I'd probably do the group 
first, then the user. In theory you can convert a group to be managed by 
adding:


objectclass: mepmanagedentry
mepmanagedby: uid=,cn=users,cn=accounts,$SUFFIX

And removing:

objectclass: groupofnames
objectclass: nestedgroup

You also need to update the user with:

objectclass: meporiginentry
mepmanagedentry: cn=,cn=groups,cn=accounts,$SUFFIX

Just don't do this with any groups that have members.

Definitely worth experimenting on a non-production installation.

rob

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

Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert certificate renewal

2016-08-23 Thread Rob Crittenden 

realstarhealer wrote:

Hi Rob,


I was concerned, just because it nowhere clearly stated what
ipa-ca-agent / caAdminCert with default serial id #6 is used for and how
it affects the system when expired.


It isn't used at all. This is the admin cert typically used when 
interfacing with the dogtag UI. You are certainly free to renew it but 
it isn't something that IPA typically needs.



So if it is not needed by IPA, I also do not strictly need to recreate a
new valid Cert for that.


Right


Is it sure, that it is unnecessarily, can we verify this somehow? Just
want to be sure that my 1+ Hosts will not suddenly stop to
authenticate us in the next days, because of this one.


There have been some bumps in renewals over the years but never one due 
to this certificate.


rob




Greeting


Vitali




*Von:* Rob Crittenden 
*Gesendet:* Montag, 22. August 2016 17:27
*An:* realstarhealer; freeipa-users@redhat.com
*Betreff:* Re: AW: AW: [Freeipa-users] ipa-cert-agent, Object Signing
Cert certificate renewal
realstarhealer wrote:

Hi,

It seemes I confused you. I just used the CVE Tutorial as a hint on
generally how to create a new Cert for ipa-ca-agent (for uid admin).
There is nothing wrong with my IPA RA (ipaCert), as it is monitored via
certmonger and has been renewed recently.

So returning to my previous question, is it sufficient to replace the
expired  #6 for uid admin in ldap with my new Cert, i created or is #6
used in more location than this one?


You'd also need to update the description value.

Why are you concerned about updating this certificate? IPA doesn't use
it in any way AFAIK.

rob



Thanks and Greetings
Vitali


 Ursprüngliche Nachricht 
Von: Rob Crittenden 
Datum: 22.08.16 16:40 (GMT+01:00)
An: realstarhealer , Freeipa-users@redhat.com
Cc: Jan Cholasta 
Betreff: Re: AW: [Freeipa-users] ipa-cert-agent, Object Signing Cert
certificate renewal

Please keep responses on the list.

realstarhealer wrote:

Hi Rob,

setting back the date and restarting did not help, in fact it can't,
because certmonger is not tracking these two by default.

Regarding the ipa-ca-agent Cert:
I followed CVE-2015-5284 slightly to create a new valid ipa-ca-agent
certificate.


You re-created the wrong cert. You need the cert with subject 'CN=IPA
RA,O=' The RA agent (original serial # usually 7) and the CA
Agent (original serial # usually 6) have different purposes.

Were you affected by the CVE? I'm not sure why you'd try to replace it
in this way.

As for the tracking, you'd do something like this (untested b/c I don't
have a 4.1 install):

# getcert start-tracking -d /etc/httpd/alias -n ipaCert -p
/etc/httpd/alias/pwdfile.txt -c dogtag-ipa-ca-renew-agent -C renew_ra_cert


Via pki cert-find --name 'ipa-ca-agent' I can now see both, the new and
the expired.
Via freeipa webui I can also See both.
Via ldapsearch -D 'cn=Directory Manager' -W -b 'ou=people,o=ipaca' I see
uid=admin using the old expired Cert ID.

Is it sufficient to ldapmodify the new valid Cert to uid=admin to solve
this? As far as I can See,  it is the only place this Cert is used.


The instructions on the wiki at
https://www.freeipa.org/page/CVE-2015-5284 seem to confuse the RA agent

CVE-2015-5284 - FreeIPA 
www.freeipa.org
CVE-2015-5284 Summary. The ipa-kra-install command, which configures KRA
for IPA, puts the CA agent certificate and private key to a world
readable file, /etc/httpd ...




with the CA agent. I don't know the details of that CVE but someone
needs to revisit these docs. I'd prefer some clarity around SUBJECT, it
will always be CN=IPA RA,

Similarly there is no need to update ca-agent.p12 file if the RA agent
cert is being replaced.

rob



Greetings
Vitali


 Ursprüngliche Nachricht 
Von: Rob Crittenden 
Datum: 18.08.16 15:28 (GMT+01:00)
An: realstarhealer , freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert
certificate renewal

realstarhealer wrote:

Hi,

I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
noticed some expired certificates recently. Most of them but 2 are
auto-renewing by certmonger as I checked. All of them are self signed.

"CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by
certmonger, ipa-ca-agent expired some days ago and has not been renewed.
Second one expires soon. No consequences noticed so far.
Can you tell me what they both are for and - if needed - how I should
renew that separately? Preferable with certmonger. An Output how the
tracking config should look like would be nice.


The object signing cert can probably be ignored. This was used to sign a
jar file used to automatically configure Firefox but that approach
doesn't work any more.

Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert certificate renewal

2016-08-23 Thread realstarhealer 
Hi Rob,


I was concerned, just because it nowhere clearly stated what ipa-ca-agent / 
caAdminCert with default serial id #6 is used for and how it affects the system 
when expired.


So if it is not needed by IPA, I also do not strictly need to recreate a new 
valid Cert for that.


Is it sure, that it is unnecessarily, can we verify this somehow? Just want to 
be sure that my 1+ Hosts will not suddenly stop to authenticate us in the 
next days, because of this one.


Greeting


Vitali



Von: Rob Crittenden 
Gesendet: Montag, 22. August 2016 17:27
An: realstarhealer; freeipa-users@redhat.com
Betreff: Re: AW: AW: [Freeipa-users] ipa-cert-agent, Object Signing Cert 
certificate renewal

realstarhealer wrote:
> Hi,
>
> It seemes I confused you. I just used the CVE Tutorial as a hint on
> generally how to create a new Cert for ipa-ca-agent (for uid admin).
> There is nothing wrong with my IPA RA (ipaCert), as it is monitored via
> certmonger and has been renewed recently.
>
> So returning to my previous question, is it sufficient to replace the
> expired  #6 for uid admin in ldap with my new Cert, i created or is #6
> used in more location than this one?

You'd also need to update the description value.

Why are you concerned about updating this certificate? IPA doesn't use
it in any way AFAIK.

rob

>
> Thanks and Greetings
> Vitali
>
>
>  Ursprüngliche Nachricht 
> Von: Rob Crittenden 
> Datum: 22.08.16 16:40 (GMT+01:00)
> An: realstarhealer , Freeipa-users@redhat.com
> Cc: Jan Cholasta 
> Betreff: Re: AW: [Freeipa-users] ipa-cert-agent, Object Signing Cert
> certificate renewal
>
> Please keep responses on the list.
>
> realstarhealer wrote:
>> Hi Rob,
>>
>> setting back the date and restarting did not help, in fact it can't,
>> because certmonger is not tracking these two by default.
>>
>> Regarding the ipa-ca-agent Cert:
>> I followed CVE-2015-5284 slightly to create a new valid ipa-ca-agent
>> certificate.
>
> You re-created the wrong cert. You need the cert with subject 'CN=IPA
> RA,O=' The RA agent (original serial # usually 7) and the CA
> Agent (original serial # usually 6) have different purposes.
>
> Were you affected by the CVE? I'm not sure why you'd try to replace it
> in this way.
>
> As for the tracking, you'd do something like this (untested b/c I don't
> have a 4.1 install):
>
> # getcert start-tracking -d /etc/httpd/alias -n ipaCert -p
> /etc/httpd/alias/pwdfile.txt -c dogtag-ipa-ca-renew-agent -C renew_ra_cert
>
>> Via pki cert-find --name 'ipa-ca-agent' I can now see both, the new and
>> the expired.
>> Via freeipa webui I can also See both.
>> Via ldapsearch -D 'cn=Directory Manager' -W -b 'ou=people,o=ipaca' I see
>> uid=admin using the old expired Cert ID.
>>
>> Is it sufficient to ldapmodify the new valid Cert to uid=admin to solve
>> this? As far as I can See,  it is the only place this Cert is used.
>
> The instructions on the wiki at
> https://www.freeipa.org/page/CVE-2015-5284 seem to confuse the RA agent
CVE-2015-5284 - FreeIPA
www.freeipa.org
CVE-2015-5284 Summary. The ipa-kra-install command, which configures KRA for 
IPA, puts the CA agent certificate and private key to a world readable file, 
/etc/httpd ...



> with the CA agent. I don't know the details of that CVE but someone
> needs to revisit these docs. I'd prefer some clarity around SUBJECT, it
> will always be CN=IPA RA,
>
> Similarly there is no need to update ca-agent.p12 file if the RA agent
> cert is being replaced.
>
> rob
>
>>
>> Greetings
>> Vitali
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Rob Crittenden 
>> Datum: 18.08.16 15:28 (GMT+01:00)
>> An: realstarhealer , freeipa-users@redhat.com
>> Betreff: Re: [Freeipa-users] ipa-cert-agent, Object Signing Cert
>> certificate renewal
>>
>> realstarhealer wrote:
>>> Hi,
>>>
>>> I am in charge for a freeipa 4.1.0.18.el7 server with ldap backend and
>>> noticed some expired certificates recently. Most of them but 2 are
>>> auto-renewing by certmonger as I checked. All of them are self signed.
>>>
>>> "CN=ipa-ca-agent" and "CN=Object Signing Cert" are not subscribed by
>>> certmonger, ipa-ca-agent expired some days ago and has not been renewed.
>>> Second one expires soon. No consequences noticed so far.
>>> Can you tell me what they both are for and - if needed - how I should
>>> renew that separately? Preferable with certmonger. An Output how the
>>> tracking config should look like would be nice.
>>
>> The object signing cert can probably be ignored. This was used to sign a
>> jar file used to automatically configure Firefox but that approach
>> doesn't work any more.
>>
>> The agent cert is used by IPA to communicate to dogtag so yeah, that's
>> pretty important.
>>
>> Since it is expired you'd need to go back in

[Freeipa-users] private user groups for existing users

2016-08-23 Thread siology.io 
 i've noticed that some of my users (imported from openldap) don't have
personal user groups, but the new ones that i make within freeipa do.

Is there a way of marking the existing accounts such that they get user
groups made for them ? I couldn't seem to see the groups that IPA is making
in the LDAP output so it must be creating them via some other means.

Is there some sort of  'ipa user create-private-group ' command ?

The only work around i have is to make hundreds of fake private groups by
making normal user groups each with one user, which'll clutter the UI up
with pointless groups.
-- 
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] SUDO and group lookup in AD trust

2016-08-23 Thread Troels Hansen 
Running RHEL 7.2: 

ipa-client-4.2.0-15.el7_2.18 
sssd-ipa-1.13.0-40.el7_2.12.x86_64 
ipa-server-4.2.0-15.el7_2.18.x86_64 

I have a sudo rule where I try to give sudo access based on a AD group. 

# groups drext...@net.dr.dk 
drext...@net.dr.dk : drext...@net.dr.dk ... 
domain_us...@linux.dr.dk 

I'm member of the group domain_users via AD. 

SUDO rule in LDAP: 

# guffe, sudoers, linux.dr.dk 
dn: cn=guffe,ou=sudoers,dc=linux,dc=dr,dc=dk 
sudoUser: %domain_users 
sudoRunAsGroup: ALL 
objectClass: sudoRole 
objectClass: top 
sudoCommand: /usr/bin/cat /var/log/messages 
sudoRunAsUser: ALL 
sudoHost: ALL 
cn: guffe 


sudo debug log shows: 
 
Aug 23 14:48:26 sudo[27307] Received 1 rule(s) 
 

 
Aug 23 14:48:26 sudo[27307] val[0]=%domain_users 
Aug 23 14:48:26 sudo[27307] -> usergr_matches @ ./match.c:802 
Aug 23 14:48:26 sudo[27307] -> user_in_group @ ./pwutil.c:940 
Aug 23 14:48:26 sudo[27307] -> sudo_get_grlist @ ./pwutil.c:877 
Aug 23 14:48:26 sudo[27307] -> rbfind @ ./redblack.c:273 
Aug 23 14:48:26 sudo[27307] <- rbfind @ ./redblack.c:277 := 0x7ff224cb31d0 
Aug 23 14:48:26 sudo[27307] <- sudo_get_grlist @ ./pwutil.c:930 := 
0x7ff224cb3348 
Aug 23 14:48:26 sudo[27307] -> sudo_getgrnam @ ./pwutil.c:719 
Aug 23 14:48:26 sudo[27307] -> rbfind @ ./redblack.c:273 
Aug 23 14:48:26 sudo[27307] <- rbfind @ ./redblack.c:280 := (nil) 
Aug 23 14:48:26 sudo[27307] -> rbinsert @ ./redblack.c:181 
Aug 23 14:48:26 sudo[27307] <- rbinsert @ ./redblack.c:261 := (nil) 
Aug 23 14:48:26 sudo[27307] <- sudo_getgrnam @ ./pwutil.c:745 := (nil) 
Aug 23 14:48:26 sudo[27307] -> sudo_grlist_delref @ ./pwutil.c:816 
Aug 23 14:48:26 sudo[27307] -> sudo_grlist_delref_item @ ./pwutil.c:805 
Aug 23 14:48:26 sudo[27307] <- sudo_grlist_delref_item @ ./pwutil.c:810 
Aug 23 14:48:26 sudo[27307] <- sudo_grlist_delref @ ./pwutil.c:818 
Aug 23 14:48:26 sudo[27307] <- user_in_group @ ./pwutil.c:1010 := false 
Aug 23 14:48:26 sudo[27307] <- usergr_matches @ ./match.c:835 := false 
Aug 23 14:48:26 sudo[27307] <- sudo_sss_filter_sudoUser @ ./sssd.c:683 := false 
 

Soo, a rule is matched, but I'm not in the group? 



I have tried setting 
use_fully_qualified_names = true 

in sssd.conf, but no luck. The sudo is still denied. 

Am I missing something? 


-- 


Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere. 
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

2016-08-23 Thread Petr Spacek 
On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
> I was able to fix that may be temporarily... when i checked the network..
> there was another process that was running and consuming a lot of network (
> i have no idea who did that. I need to seriously start restricting people
> access to this machine )
> 
> after killing that perfomance improved drastically
> 
> But now, suddenly I started experiencing the same hang.
> 
> This time , I gert the following error when checked dmesg
> 
> [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
> 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
> Sending cookies.  Check SNMP counters.
> [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
> 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
> [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
> 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00

Okay, this one is serious. The LDAP server crashed.

1. Make sure all your packages are up-to-date.

Please see
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes
for further instructions how to debug this.

Petr^2 Spacek

> 
> and in /var/log/dirsrv/example-com/errors
> 
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291138 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291139 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291140 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291141 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291142 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291143 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291144 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291145 (rc: 32)
> [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
> [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3292734 (rc: 51)
> 
> 
> Can  i do something about this error.. I treid to restart ipa a couple of
> time but that did not help
> 
> Thanks
> Rakesh
> 
> On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek  wrote:
> 
>> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>> I am running my set up on AWS cloud, and entropy is low at around 180 .
>>>
>>> I plan to increase it bu installing haveged . But, would low entropy by
>> any
>>> chance cause this issue of intermittent hang .
>>> Also, the hang is mostly observed when registering around 20 clients
>>> together
>>
>> Possibly, I'm not sure. If you want to dig into this, I would do this:
>> 1. look what process hangs on client (using pstree command or so)
>> $ pstree
>>
>> 2. look to what server and port is the hanging client connected to
>> $ lsof -p 
>>
>> 3. jump to server and see what process is bound to the target port
>> $ netstat -pn
>>
>> 4. see where the process if hanging
>> $ strace -p 
>>
>> I hope it helps.
>>
>> Petr^2 Spacek
>>
>>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
>>> rakesh.rajasekha...@gmail.com> wrote:
>>>
 yes there seems to be something thats worrying.. I have faced this today
 as well.
 There are few hosts around 280 odd left and when i try adding them to
>> IPA
 , the slowness begins..

 all the ipa commands like ipa user-find.. etc becomes very slow in
 responding.

 the SYNC_RECV are not many though just around 80-90 and today that was
 around 20 only


 I have for now increased tcp_max_syn_backlog to 5000.
 For now the slowness seems to have gone.. but I will do a try adding the
 clients again tomorrow and see how it goes

 Thanks
 Rakesh

 The issues

 On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek 
>> wrote:

> On 18.8.2016 17:23, Rakesh Rajasekharan wrote:
>> Hi
>>
>> I am migrating to freeipa from openldap and have around 4000 clients
>>
>> I had openned a another thread on that, but chose to start a new one
> here
>> as its a separate issue
>>
>> I was able to change the nssslapd-maxdescriptors adding an ldif file
>>
>> cat nsslapd-modify.ldif
>> dn: cn=config
>> changetype: modify
>> replace: nsslapd-maxdescriptors
>> nsslapd-maxdescriptors: 17000
>>
>> and running the ldapmodify command
>>
>> I have now started moving clients running an openldap to Freeipa and
> have
>> today moved close to 2000 clients

Re: [Freeipa-users] can't get sudo to work.

2016-08-23 Thread Jeff Goddard 
Not sure if it's related or not but I also reported an instance of similar
behavior of this on Ubuntu 16.0.1

On Tue, Aug 23, 2016 at 2:24 AM, Tony Brian Albers 
wrote:

> Hi guys,
>
> I've been trying to get sudo to work for our day-to-day admin who have
> their own usergroup in IPA called subadmin.
>
> For some reason I can't really get sudo to work, I suspect I am missing
> something simple, but I can't really figure out what it is.
>
> This is my config:
>
> # ipa sudorule-find
> ---
> 1 Sudo Rule matched
> ---
>   Rule name: All
>   Enabled: TRUE
>   Host category: all
>   Command category: all
>   User Groups: subadmin
> 
> Number of entries returned 1
> 
> #
>
>
>
>
> # ipa group-find subadmin
> ---
> 1 group matched
> ---
>   Group name: subadmin
>   Description: For daily administration of users and hosts
>   GID: 10003
>   Member users: abr-sadm, pmd-sadm, tba-sadm, bja-sadm, alberto-ibm
>   Roles: Sub-admins
>   Member of Sudo rule: All
> 
> Number of entries returned 1
> 
> #
>
>
>
>
>
> And on a client:
>
> # cat /etc/sssd/sssd.conf
> [domain/kac.lokalnet]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = kac.sblokalnet
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = kac-man-001.kac.lokalnet
> chpass_provider = ipa
> ipa_server = _srv_, kac-adm-001.kac.lokalnet
> ldap_tls_cacert = /etc/ipa/ca.crt
> autofs_provider = ipa
> ipa_automount_location = default
> krb5_renewable_lifetime = 50d
> krb5_renew_interval = 3600
> [sssd]
> services = nss, sudo, pam, autofs, ssh
> config_file_version = 2
>
> domains = kac.lokalnet
> [nss]
> homedir_substring = /home
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
> [ifp]
>
>
>
>
>
>
> nsswitch.conf:
>
> passwd: files sss
> shadow: files sss
> group:  files sss
> #initgroups: files
>
> #hosts: db files nisplus nis dns
> hosts:  files dns myhostname
>
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:nisplus [NOTFOUND=return] files
> #ethers: nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
>
> bootparams: nisplus [NOTFOUND=return] files
>
> ethers: files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:files
> services:   files sss
>
> netgroup:   files sss
>
> publickey:  nisplus
>
> automount:  sss files
> aliases:files nisplus
> sudoers:files sss
>
>
>
>
> And for a subadmin account:
>
> -sh-4.2$ sudo -l
> [sudo] password for tba-sadm:
> Your password will expire in 6 day(s).
> User tba-sadm is not allowed to run sudo on kac-man-001.
> -sh-4.2$
>
>
>
> Any suggestions?  Help is much appreciated.
>
> TIA
>
> /tony
>
> --
> Best regards,
>
> Tony Albers
> Systems administrator, IT-development
> State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
> Tel: +45 8946 2316
>
>
>
>
> --
> 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
>



Jeff
-- 
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] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Petr Spacek 
On 23.8.2016 13:21, Matt . wrote:
> And then allow the ip of the ipa server for update or tranfser on the slave ?
> 
> Because I don't see anything coming in.

The config has two parts:

1. master (IPA DNS)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#zone-transfers

2. slave (non-IPA DNS)
http://www.zytrax.com/books/dns/ch4/index.html#slave

You need to configure both sides. Slave will then periodically pull the zone
and re-transfer zone whenever IPA DNS sends a NOTIFY message to the slave.

Log on slave should tell you if it is receiving something or not.

-- 
Petr^2 Spacek


> 
> 2016-08-23 12:47 GMT+02:00 Petr Spacek :
>> On 23.8.2016 12:43, Matt . wrote:
>>> OK, but what kind of records are you talking about then ?
>>
>> I'm not sure what else should I say.
>>
>> NS records: the ones added by
>>
>> $ ipa record-add  @ --ns-rec=.
>> (please note the trailing period)
>>
>> Does it answer your question?
>>
>> Petr^2 Spacek
>>
>>>
>>> 2016-08-23 12:25 GMT+02:00 Petr Spacek :
 On 23.8.2016 09:07, Martin Basti wrote:
>
>
> On 23.08.2016 02:08, Matt . wrote:
>> Hi Guys,
>>
>> What is the way to notify or update a Bind slave which is not an IPA 
>> server ?
>>
>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>> IPA master or is there a different way how to accomplish this ?
>>
>> I hope this is possible and anyone can explain me how.
>>
>> Thanks!
>>
>> Matt
>>
>
> Hi,
>
> some info about transfers can be found here:
> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
>
> Yes you need manually update named.conf with also-notify

 Well, the also-notify might not (always) work, it is not directly 
 supported by
 bind-dyndb-ldap.

 It should work automatically if you list your slave servers in NS records,
 BIND will automatically send notify messages to all servers listed in NS 
 records.

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

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Matt . 
And then allow the ip of the ipa server for update or tranfser on the slave ?

Because I don't see anything coming in.

2016-08-23 12:47 GMT+02:00 Petr Spacek :
> On 23.8.2016 12:43, Matt . wrote:
>> OK, but what kind of records are you talking about then ?
>
> I'm not sure what else should I say.
>
> NS records: the ones added by
>
> $ ipa record-add  @ --ns-rec=.
> (please note the trailing period)
>
> Does it answer your question?
>
> Petr^2 Spacek
>
>>
>> 2016-08-23 12:25 GMT+02:00 Petr Spacek :
>>> On 23.8.2016 09:07, Martin Basti wrote:


 On 23.08.2016 02:08, Matt . wrote:
> Hi Guys,
>
> What is the way to notify or update a Bind slave which is not an IPA 
> server ?
>
> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
> IPA master or is there a different way how to accomplish this ?
>
> I hope this is possible and anyone can explain me how.
>
> Thanks!
>
> Matt
>

 Hi,

 some info about transfers can be found here:
 http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG

 Yes you need manually update named.conf with also-notify
>>>
>>> Well, the also-notify might not (always) work, it is not directly supported 
>>> by
>>> bind-dyndb-ldap.
>>>
>>> It should work automatically if you list your slave servers in NS records,
>>> BIND will automatically send notify messages to all servers listed in NS 
>>> records.
>>>
>>> --
>>> 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

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Petr Spacek 
On 23.8.2016 12:43, Matt . wrote:
> OK, but what kind of records are you talking about then ?

I'm not sure what else should I say.

NS records: the ones added by

$ ipa record-add  @ --ns-rec=.
(please note the trailing period)

Does it answer your question?

Petr^2 Spacek

> 
> 2016-08-23 12:25 GMT+02:00 Petr Spacek :
>> On 23.8.2016 09:07, Martin Basti wrote:
>>>
>>>
>>> On 23.08.2016 02:08, Matt . wrote:
 Hi Guys,

 What is the way to notify or update a Bind slave which is not an IPA 
 server ?

 Do I need to manuallu add an also-notify to the /etc/bind.conf on the
 IPA master or is there a different way how to accomplish this ?

 I hope this is possible and anyone can explain me how.

 Thanks!

 Matt

>>>
>>> Hi,
>>>
>>> some info about transfers can be found here:
>>> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
>>>
>>> Yes you need manually update named.conf with also-notify
>>
>> Well, the also-notify might not (always) work, it is not directly supported 
>> by
>> bind-dyndb-ldap.
>>
>> It should work automatically if you list your slave servers in NS records,
>> BIND will automatically send notify messages to all servers listed in NS 
>> records.
>>
>> --
>> 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

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Matt . 
OK, but what kind of records are you talking about then ?

2016-08-23 12:25 GMT+02:00 Petr Spacek :
> On 23.8.2016 09:07, Martin Basti wrote:
>>
>>
>> On 23.08.2016 02:08, Matt . wrote:
>>> Hi Guys,
>>>
>>> What is the way to notify or update a Bind slave which is not an IPA server 
>>> ?
>>>
>>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>>> IPA master or is there a different way how to accomplish this ?
>>>
>>> I hope this is possible and anyone can explain me how.
>>>
>>> Thanks!
>>>
>>> Matt
>>>
>>
>> Hi,
>>
>> some info about transfers can be found here:
>> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
>>
>> Yes you need manually update named.conf with also-notify
>
> Well, the also-notify might not (always) work, it is not directly supported by
> bind-dyndb-ldap.
>
> It should work automatically if you list your slave servers in NS records,
> BIND will automatically send notify messages to all servers listed in NS 
> records.
>
> --
> 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

-- 
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] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Petr Spacek 
On 23.8.2016 09:07, Martin Basti wrote:
> 
> 
> On 23.08.2016 02:08, Matt . wrote:
>> Hi Guys,
>>
>> What is the way to notify or update a Bind slave which is not an IPA server ?
>>
>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>> IPA master or is there a different way how to accomplish this ?
>>
>> I hope this is possible and anyone can explain me how.
>>
>> Thanks!
>>
>> Matt
>>
> 
> Hi,
> 
> some info about transfers can be found here:
> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
> 
> Yes you need manually update named.conf with also-notify

Well, the also-notify might not (always) work, it is not directly supported by
bind-dyndb-ldap.

It should work automatically if you list your slave servers in NS records,
BIND will automatically send notify messages to all servers listed in NS 
records.

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

Re: [Freeipa-users] clean-ruv

2016-08-23 Thread Ludwig Krispenz 


On 08/23/2016 11:52 AM, Ian Harding wrote:

Ah.  I see.  I mixed those up but I see that those would have to be
consistent.

However, I have been trying to beat some invalid RUV to death for a long
time and I can't seem to kill them.

For example, bellevuenfs has 9 and 16 which are invalid:

[ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 7
nsds50ruv: {replicageneration} 55c8f3640004
nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
568ac3cc0007 57
nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
57b1037700020014
nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a4780100010012
nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
57a40386000f 5
nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
57a2dccd000e
nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
57a422f90011
nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
57a4f20d00060013
nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
57a417060010
nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
570484ee0009 5


So I try to kill them like so:
[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

No abort CLEANALLRUV tasks running
[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

and it never finishes.

seattlenfs is the first master, that's the only place I should have to
run this command, right?
right, you need to run it only on one master, but this ease of use can 
become the problem.
The cleanallruv task is propagated to all servers in the topology and it 
does this based on the replication agreements it finds.
A frequent cause of failure is that replication agreements still exist 
pointing to no longer existing servers. It is a bit tedious, but could 
you run the following search on ALL

of your current replicas (as directory manager):

ldapsearch .. -b "cn=config" "objectclass=nsds5replicationagreement" 
nsds5replicahost


if you find any agreement where nsds5replicahost is a host no longer 
existing or working, delete these agreements.


I'm about to burn everything down and ipa-server-install --uninstall but
I've done that before a couple times and that seems to be what got me
into this mess...

Thank you for your help.




On 08/23/2016 01:37 AM, Ludwig Krispenz wrote:

looks like you are searching the nstombstone below "o=ipaca", but you
are cleaning ruvs in "dc=bpt,dc=rocks",

your attrlist_replace error refers to the bpt,rocks backend, so you
should search the tombstone entry ther, then determine which replicaIDs
to remove.

Ludwig

On 08/23/2016 09:20 AM, Ian Harding wrote:

I've followed the procedure in this thread:

https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html

and found my list of RUV that don't have an existing replica id.

I've tried to remove them like so:

[root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
Enter LDAP Password:
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=bpt,dc=rocks
replica-id: 97
replica-force-cleaning: yes
cn: clean 97

adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"

[root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
CLEANALLRUV tasks
RID 9: Waiting to process all the updates from the deleted replica...

Re: [Freeipa-users] can't get sudo to work.

2016-08-23 Thread Pavel Březina 

On 08/23/2016 11:26 AM, Tony Brian Albers wrote:

Thanks Jakub,

I've attached a file with the output from looking in the log files
mentioned in the link you gave me.

I'm not sure exactly what is wrong, I don't know how to interpret
messages like: name 'tba-sadm' matched without domain, user is tba
-sadm   (is that good or bad?)

Any advice is appreciated.


Hi,
unfortunately the attached file is empty. Can you resend it? You can 
send it to me privately if you want. I will need both sssd and sudo logs 
(both described in the troubleshooting page).


Thank you.



/tony


--
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] Unknown Error - error (pop-up) window

2016-08-23 Thread Pavel Vomacka 



On 08/22/2016 09:46 PM, Zarko Dudic wrote:

Hi all,

IPA version: ipa-server-4.2.0-15.0.1.el7_2.18.x86_64
Kernel: 3.8.13-118.10.2.el7uek.x86_64

I start seeing pop-up window titled "Unknown Error" with message 
"error" and buttons Retry and Cancel. It happens when selecting almost 
anything on the Web interface, from Identity to IPA Server.
Certainly changes have been made, like adding identities, adding certs 
in nssdb, but can't think of anything that can cause such error.
And when errors happen, no new logs in /var/log/httpd both access and 
error logs. Also no new logs in /var/log/dirsrv/slapd-REALM/


For starter, can you please suggest any troubleshooting steps and 
other logs to query.



Hello,

You are probably facing this issue: 
https://fedorahosted.org/freeipa/ticket/4821 , pvoborni wrote a comment 
with some situations when this error might be seen. Try to check them ( 
https://fedorahosted.org/freeipa/ticket/4821#comment:3 ).


--
Pavel^3 Vomacka

--
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] clean-ruv

2016-08-23 Thread Ian Harding 
Ah.  I see.  I mixed those up but I see that those would have to be
consistent.

However, I have been trying to beat some invalid RUV to death for a long
time and I can't seem to kill them.

For example, bellevuenfs has 9 and 16 which are invalid:

[ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 7
nsds50ruv: {replicageneration} 55c8f3640004
nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
568ac3cc0007 57
nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
57b1037700020014
nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a4780100010012
nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
57a40386000f 5
nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
57a2dccd000e
nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
57a422f90011
nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
57a4f20d00060013
nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
57a417060010
nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
570484ee0009 5


So I try to kill them like so:
[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389

Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

No abort CLEANALLRUV tasks running
[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...

and it never finishes.

seattlenfs is the first master, that's the only place I should have to
run this command, right?

I'm about to burn everything down and ipa-server-install --uninstall but
I've done that before a couple times and that seems to be what got me
into this mess...

Thank you for your help.




On 08/23/2016 01:37 AM, Ludwig Krispenz wrote:
> looks like you are searching the nstombstone below "o=ipaca", but you
> are cleaning ruvs in "dc=bpt,dc=rocks",
> 
> your attrlist_replace error refers to the bpt,rocks backend, so you
> should search the tombstone entry ther, then determine which replicaIDs
> to remove.
> 
> Ludwig
> 
> On 08/23/2016 09:20 AM, Ian Harding wrote:
>> I've followed the procedure in this thread:
>>
>> https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html
>>
>> and found my list of RUV that don't have an existing replica id.
>>
>> I've tried to remove them like so:
>>
>> [root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
>> Enter LDAP Password:
>> dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
>> objectclass: top
>> objectclass: extensibleObject
>> replica-base-dn: dc=bpt,dc=rocks
>> replica-id: 97
>> replica-force-cleaning: yes
>> cn: clean 97
>>
>> adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"
>>
>> [root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
>> CLEANALLRUV tasks
>> RID 9: Waiting to process all the updates from the deleted replica...
>> RID 96: Successfully cleaned rid(96).
>> RID 97: Successfully cleaned rid(97).
>>
>> No abort CLEANALLRUV tasks running
>>
>>
>> and yet, they are still there...
>>
>> [root@seattlenfs ianh]# ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
>> "cn=Directory Manager" -W -b "o=ipaca"
>> "(&(objectclass=nstombstone)(nsUniqueId=---))"
>>
>> | grep "nsds50ruv\|nsDS5ReplicaId"
>> Enter LDAP Password:
>> nsDS5ReplicaId: 81
>> nsds50ruv: {replicageneration} 55c8f3ae0060
>> nsds50ruv: {replica 81 ldap://seattlenfs.bpt.rocks:389}
>> 568ac4310051 5
>> nsds50ruv: {replica 1065

Re: [Freeipa-users] can't get sudo to work.

2016-08-23 Thread Tony Brian Albers 
Thanks Jakub,

I've attached a file with the output from looking in the log files
mentioned in the link you gave me.

I'm not sure exactly what is wrong, I don't know how to interpret
messages like: name 'tba-sadm' matched without domain, user is tba
-sadm   (is that good or bad?)

Any advice is appreciated.

/tony


On Tue, 2016-08-23 at 09:17 +0200, Jakub Hrozek wrote:
> On Tue, Aug 23, 2016 at 07:11:44AM +, Tony Brian Albers wrote:
> > Thanks Simon,
> > 
> > Is this a known issue?  We're on Centos 7.2 and yes, the sssd version is
> > 1.13
> > 
> > /tony
> 
> IIRC Simpson's issue was related to using AD trusts and
> default_domain_suffix. I would recommend looking at logs first before
> jumping to conclusions.
> 

-- 
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316



-- 
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] clean-ruv

2016-08-23 Thread Ludwig Krispenz 
looks like you are searching the nstombstone below "o=ipaca", but you 
are cleaning ruvs in "dc=bpt,dc=rocks",


your attrlist_replace error refers to the bpt,rocks backend, so you 
should search the tombstone entry ther, then determine which replicaIDs 
to remove.


Ludwig

On 08/23/2016 09:20 AM, Ian Harding wrote:

I've followed the procedure in this thread:

https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html

and found my list of RUV that don't have an existing replica id.

I've tried to remove them like so:

[root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
Enter LDAP Password:
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=bpt,dc=rocks
replica-id: 97
replica-force-cleaning: yes
cn: clean 97

adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"

[root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
CLEANALLRUV tasks
RID 9: Waiting to process all the updates from the deleted replica...
RID 96: Successfully cleaned rid(96).
RID 97: Successfully cleaned rid(97).

No abort CLEANALLRUV tasks running


and yet, they are still there...

[root@seattlenfs ianh]# ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 81
nsds50ruv: {replicageneration} 55c8f3ae0060
nsds50ruv: {replica 81 ldap://seattlenfs.bpt.rocks:389}
568ac4310051 5
nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57b103d40429000
nsds50ruv: {replica 1070 ldap://bellevuenfs.bpt.rocks:389}
57a4f270042e000
nsds50ruv: {replica 1075 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a47865043300
nsds50ruv: {replica 1080 ldap://bellevuenfs.bpt.rocks:389}
57a417670438000
nsds50ruv: {replica 1085 ldap://fremontnis.bpt.rocks:389}
57a403e6043d
nsds50ruv: {replica 1090 ldap://freeipa-dal.bpt.rocks:389}
57a2dd350442000
nsds50ruv: {replica 1095 ldap://freeipa-sea.bpt.rocks:389}
579a963c0447000
nsds50ruv: {replica 96 ldap://freeipa-sea.bpt.rocks:389}
55c8f3bd0060
nsds50ruv: {replica 86 ldap://fremontnis.bpt.rocks:389}
5685b24e0056 5
nsds50ruv: {replica 91 ldap://seattlenis.bpt.rocks:389}
567ad6180001005b 5
nsds50ruv: {replica 97 ldap://freeipa-dal.bpt.rocks:389}
55c8f3ce0061
nsds50ruv: {replica 76 ldap://bellevuenis.bpt.rocks:389}
56f385eb0007004c
nsds50ruv: {replica 71 ldap://bellevuenfs.bpt.rocks:389}
570485690047
nsds50ruv: {replica 66 ldap://bpt-nyc1-nfs.bpt.rocks:389}
5733e594000a0042
nsds50ruv: {replica 61 ldap://edinburghnfs.bpt.rocks:389}
57442125003d
nsds50ruv: {replica 1195 ldap://edinburghnfs.bpt.rocks:389}
57a4239004ab00

What have I done wrong?

The problem I am trying to solve is that seattlenfs.bpt.rocks sends
updates to all its children, but their changes don't come back because
of these errors:

[23/Aug/2016:00:02:16 -0700] attrlist_replace - attr_replace
(nsslapd-referral,
ldap://seattlenfs.bpt.rocks:389/dc%3Dbpt%2Cdc%3Drocks) failed.

in effect, the replication agreements are one-way.

Any ideas?

- Ian



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

[Freeipa-users] clean-ruv

2016-08-23 Thread Ian Harding 
I've followed the procedure in this thread:

https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html

and found my list of RUV that don't have an existing replica id.

I've tried to remove them like so:

[root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
Enter LDAP Password:
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=bpt,dc=rocks
replica-id: 97
replica-force-cleaning: yes
cn: clean 97

adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"

[root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
CLEANALLRUV tasks
RID 9: Waiting to process all the updates from the deleted replica...
RID 96: Successfully cleaned rid(96).
RID 97: Successfully cleaned rid(97).

No abort CLEANALLRUV tasks running


and yet, they are still there...

[root@seattlenfs ianh]# ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 81
nsds50ruv: {replicageneration} 55c8f3ae0060
nsds50ruv: {replica 81 ldap://seattlenfs.bpt.rocks:389}
568ac4310051 5
nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57b103d40429000
nsds50ruv: {replica 1070 ldap://bellevuenfs.bpt.rocks:389}
57a4f270042e000
nsds50ruv: {replica 1075 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a47865043300
nsds50ruv: {replica 1080 ldap://bellevuenfs.bpt.rocks:389}
57a417670438000
nsds50ruv: {replica 1085 ldap://fremontnis.bpt.rocks:389}
57a403e6043d
nsds50ruv: {replica 1090 ldap://freeipa-dal.bpt.rocks:389}
57a2dd350442000
nsds50ruv: {replica 1095 ldap://freeipa-sea.bpt.rocks:389}
579a963c0447000
nsds50ruv: {replica 96 ldap://freeipa-sea.bpt.rocks:389}
55c8f3bd0060
nsds50ruv: {replica 86 ldap://fremontnis.bpt.rocks:389}
5685b24e0056 5
nsds50ruv: {replica 91 ldap://seattlenis.bpt.rocks:389}
567ad6180001005b 5
nsds50ruv: {replica 97 ldap://freeipa-dal.bpt.rocks:389}
55c8f3ce0061
nsds50ruv: {replica 76 ldap://bellevuenis.bpt.rocks:389}
56f385eb0007004c
nsds50ruv: {replica 71 ldap://bellevuenfs.bpt.rocks:389}
570485690047
nsds50ruv: {replica 66 ldap://bpt-nyc1-nfs.bpt.rocks:389}
5733e594000a0042
nsds50ruv: {replica 61 ldap://edinburghnfs.bpt.rocks:389}
57442125003d
nsds50ruv: {replica 1195 ldap://edinburghnfs.bpt.rocks:389}
57a4239004ab00

What have I done wrong?

The problem I am trying to solve is that seattlenfs.bpt.rocks sends
updates to all its children, but their changes don't come back because
of these errors:

[23/Aug/2016:00:02:16 -0700] attrlist_replace - attr_replace
(nsslapd-referral,
ldap://seattlenfs.bpt.rocks:389/dc%3Dbpt%2Cdc%3Drocks) failed.

in effect, the replication agreements are one-way.

Any ideas?

- Ian

-- 
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't get sudo to work.

2016-08-23 Thread Jakub Hrozek 
On Tue, Aug 23, 2016 at 07:11:44AM +, Tony Brian Albers wrote:
> Thanks Simon,
> 
> Is this a known issue?  We're on Centos 7.2 and yes, the sssd version is
> 1.13
> 
> /tony

IIRC Simpson's issue was related to using AD trusts and
default_domain_suffix. I would recommend looking at logs first before
jumping to conclusions.

-- 
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't get sudo to work.

2016-08-23 Thread Jakub Hrozek 
On Tue, Aug 23, 2016 at 06:24:23AM +, Tony Brian Albers wrote:
> Hi guys,
> 
> I've been trying to get sudo to work for our day-to-day admin who have
> their own usergroup in IPA called subadmin.
> 
> For some reason I can't really get sudo to work, I suspect I am missing
> something simple, but I can't really figure out what it is.

This might be helpful:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

-- 
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't get sudo to work.

2016-08-23 Thread Tony Brian Albers 
Thanks Simon,

Is this a known issue?  We're on Centos 7.2 and yes, the sssd version is
1.13

/tony

On Tue, 2016-08-23 at 06:49 +, Simpson Lachlan wrote:
> What version of sssd are you using?
> 
> We found that it wouldn't work w sssd<1.14
> 
> On the IPA server, it would say "yep rule applies", but then on any 
> particular machine it wouldn't (well, it would - but only intermittently).
> 
> There's a COPR repo for Centos7 if you aren't on Fedora/RedHat.
> 
> Cheers
> L.
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Tony Brian Albers
> Sent: Tuesday, 23 August 2016 4:24 PM
> To: freeipa-users@redhat.com
> Subject: [Freeipa-users] can't get sudo to work.
> 
> Hi guys,
> 
> I've been trying to get sudo to work for our day-to-day admin who have their 
> own usergroup in IPA called subadmin.
> 
> For some reason I can't really get sudo to work, I suspect I am missing 
> something simple, but I can't really figure out what it is.
> 
> This is my config:
> 
> # ipa sudorule-find
> ---
> 1 Sudo Rule matched
> ---
>   Rule name: All
>   Enabled: TRUE
>   Host category: all
>   Command category: all
>   User Groups: subadmin
> 
> Number of entries returned 1
> 
> #
> 
> 
> 
> 
> # ipa group-find subadmin
> ---
> 1 group matched
> ---
>   Group name: subadmin
>   Description: For daily administration of users and hosts
>   GID: 10003
>   Member users: abr-sadm, pmd-sadm, tba-sadm, bja-sadm, alberto-ibm
>   Roles: Sub-admins
>   Member of Sudo rule: All
> 
> Number of entries returned 1
> 
> #
> 
> 
> 
> 
> 
> And on a client:
> 
> # cat /etc/sssd/sssd.conf
> [domain/kac.lokalnet]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = kac.sblokalnet
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = kac-man-001.kac.lokalnet
> chpass_provider = ipa
> ipa_server = _srv_, kac-adm-001.kac.lokalnet ldap_tls_cacert = 
> /etc/ipa/ca.crt autofs_provider = ipa ipa_automount_location = default 
> krb5_renewable_lifetime = 50d krb5_renew_interval = 3600 [sssd] services = 
> nss, sudo, pam, autofs, ssh config_file_version = 2
> 
> domains = kac.lokalnet
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> 
> 
> 
> 
> 
> nsswitch.conf:
> 
> passwd: files sss
> shadow: files sss
> group:  files sss
> #initgroups: files
> 
> #hosts: db files nisplus nis dns
> hosts:  files dns myhostname
> 
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:nisplus [NOTFOUND=return] files
> #ethers: nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files 
> 
> bootparams: nisplus [NOTFOUND=return] files
> 
> ethers: files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:files
> services:   files sss
> 
> netgroup:   files sss
> 
> publickey:  nisplus
> 
> automount:  sss files
> aliases:files nisplus
> sudoers:files sss
> 
> 
> 
> 
> And for a subadmin account:
> 
> -sh-4.2$ sudo -l
> [sudo] password for tba-sadm: 
> Your password will expire in 6 day(s).
> User tba-sadm is not allowed to run sudo on kac-man-001.
> -sh-4.2$
> 
> 
> 
> Any suggestions?  Help is much appreciated.
> 
> TIA
> 
> /tony
> 
> --
> Best regards,
> 
> Tony Albers
> Systems administrator, IT-development
> State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
> Tel: +45 8946 2316
> 
> 
> 
> 
> --
> 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
> This email (including any attachments or links) may contain 
> confidential and/or legally privileged information and is 
> intended only to be read or used by the addressee.  If you 
> are not the intended addressee, any use, distribution, 
> disclosure or copying of this email is strictly 
> prohibited.  
> Confidentiality and legal privilege attached to this email 
> (including any attachments) are not waived or lost by 
> reason of its mistaken delivery to you.
> If you have received this email in error, please delete it 
> and notify us immediately by telephone or email.  Peter 
> MacCallum Cancer Centre provides no guarantee that this 
> transmission is free of virus or that it has not been 
> intercepted or altered and will not be liable for any delay 
> in its receipt.
> 

-- 
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




-- 
Manage your subscription for

Re: [Freeipa-users] Possible bug in SSSD/IPA/AD trust

2016-08-23 Thread Jakub Hrozek 
On Tue, Aug 23, 2016 at 08:42:42AM +0200, Troels Hansen wrote:
> 
> 
> - On Aug 11, 2016, at 3:56 PM, Jakub Hrozek jhro...@redhat.com wrote:
> 
> > On Thu, Aug 11, 2016 at 03:11:10PM +0200, Troels Hansen wrote:
> >> Hi, we are curretly workig on a larger IPA test project and I have a 
> >> problems
> >> which have been buggin me for some time now:
> > 
> > Which version?
> 
> Most recent in Red Hat 7.
> 
> SSSD 1.13.0-40.el7_2.12
> IPA 4.2.0-15.el7_2.18
> 
> >> 
> >> On the client we are have set "full_name_format = %1$s" to have users 
> >> presented
> >> without the AD domain part.
> >> However, this seems to make SSSD not lookup a users group membership?
> > 
> > This only works with sssd-1.14+
> > 
> 
> But it actually works?

According to my testing, yes

> The username is presented correctly (without domain part) if set, and the 
> parameter is documented in `man sssd.conf`?

It's been documented in sssd.conf in years, it's the full_name_format.
The "only" issue is that it didn't work prior to 1.14 :-)

> Only group lookup fails.
> 

Shouldn't with 1.14, if it does, it may be a bug.

-- 
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] Update NON-ipa Bind slave server from IPA-DNS edit/update

2016-08-23 Thread Martin Basti 



On 23.08.2016 02:08, Matt . wrote:

Hi Guys,

What is the way to notify or update a Bind slave which is not an IPA server ?

Do I need to manuallu add an also-notify to the /etc/bind.conf on the
IPA master or is there a different way how to accomplish this ?

I hope this is possible and anyone can explain me how.

Thanks!

Matt



Hi,

some info about transfers can be found here:
http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG

Yes you need manually update named.conf with also-notify

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] can't get sudo to work.

2016-08-23 Thread Simpson Lachlan 
What version of sssd are you using?

We found that it wouldn't work w sssd<1.14

On the IPA server, it would say "yep rule applies", but then on any particular 
machine it wouldn't (well, it would - but only intermittently).

There's a COPR repo for Centos7 if you aren't on Fedora/RedHat.

Cheers
L.

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Tony Brian Albers
Sent: Tuesday, 23 August 2016 4:24 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] can't get sudo to work.

Hi guys,

I've been trying to get sudo to work for our day-to-day admin who have their 
own usergroup in IPA called subadmin.

For some reason I can't really get sudo to work, I suspect I am missing 
something simple, but I can't really figure out what it is.

This is my config:

# ipa sudorule-find
---
1 Sudo Rule matched
---
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  User Groups: subadmin

Number of entries returned 1

#




# ipa group-find subadmin
---
1 group matched
---
  Group name: subadmin
  Description: For daily administration of users and hosts
  GID: 10003
  Member users: abr-sadm, pmd-sadm, tba-sadm, bja-sadm, alberto-ibm
  Roles: Sub-admins
  Member of Sudo rule: All

Number of entries returned 1

#





And on a client:

# cat /etc/sssd/sssd.conf
[domain/kac.lokalnet]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = kac.sblokalnet
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = kac-man-001.kac.lokalnet
chpass_provider = ipa
ipa_server = _srv_, kac-adm-001.kac.lokalnet ldap_tls_cacert = /etc/ipa/ca.crt 
autofs_provider = ipa ipa_automount_location = default krb5_renewable_lifetime 
= 50d krb5_renew_interval = 3600 [sssd] services = nss, sudo, pam, autofs, ssh 
config_file_version = 2

domains = kac.lokalnet
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]






nsswitch.conf:

passwd: files sss
shadow: files sss
group:  files sss
#initgroups: files

#hosts: db files nisplus nis dns
hosts:  files dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files 

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  sss files
aliases:files nisplus
sudoers:files sss




And for a subadmin account:

-sh-4.2$ sudo -l
[sudo] password for tba-sadm: 
Your password will expire in 6 day(s).
User tba-sadm is not allowed to run sudo on kac-man-001.
-sh-4.2$



Any suggestions?  Help is much appreciated.

TIA

/tony

--
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




--
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
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Possible bug in SSSD/IPA/AD trust

2016-08-23 Thread Troels Hansen 


- On Aug 11, 2016, at 3:56 PM, Jakub Hrozek jhro...@redhat.com wrote:

> On Thu, Aug 11, 2016 at 03:11:10PM +0200, Troels Hansen wrote:
>> Hi, we are curretly workig on a larger IPA test project and I have a problems
>> which have been buggin me for some time now:
> 
> Which version?

Most recent in Red Hat 7.

SSSD 1.13.0-40.el7_2.12
IPA 4.2.0-15.el7_2.18

>> 
>> On the client we are have set "full_name_format = %1$s" to have users 
>> presented
>> without the AD domain part.
>> However, this seems to make SSSD not lookup a users group membership?
> 
> This only works with sssd-1.14+
> 

But it actually works? The username is presented correctly (without domain 
part) if set, and the parameter is documented in `man sssd.conf`?
Only group lookup fails.

-- 
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] can't get sudo to work.

2016-08-23 Thread Tony Brian Albers 
Hi guys,

I've been trying to get sudo to work for our day-to-day admin who have
their own usergroup in IPA called subadmin.

For some reason I can't really get sudo to work, I suspect I am missing
something simple, but I can't really figure out what it is.

This is my config:

# ipa sudorule-find
---
1 Sudo Rule matched
---
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  User Groups: subadmin

Number of entries returned 1

#




# ipa group-find subadmin
---
1 group matched
---
  Group name: subadmin
  Description: For daily administration of users and hosts
  GID: 10003
  Member users: abr-sadm, pmd-sadm, tba-sadm, bja-sadm, alberto-ibm
  Roles: Sub-admins
  Member of Sudo rule: All

Number of entries returned 1

#





And on a client:

# cat /etc/sssd/sssd.conf 
[domain/kac.lokalnet]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = kac.sblokalnet
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = kac-man-001.kac.lokalnet
chpass_provider = ipa
ipa_server = _srv_, kac-adm-001.kac.lokalnet
ldap_tls_cacert = /etc/ipa/ca.crt
autofs_provider = ipa
ipa_automount_location = default
krb5_renewable_lifetime = 50d
krb5_renew_interval = 3600
[sssd]
services = nss, sudo, pam, autofs, ssh
config_file_version = 2

domains = kac.lokalnet
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]






nsswitch.conf:

passwd: files sss
shadow: files sss
group:  files sss
#initgroups: files

#hosts: db files nisplus nis dns
hosts:  files dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files 

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  sss files
aliases:files nisplus
sudoers:files sss




And for a subadmin account:

-sh-4.2$ sudo -l
[sudo] password for tba-sadm: 
Your password will expire in 6 day(s).
User tba-sadm is not allowed to run sudo on kac-man-001.
-sh-4.2$



Any suggestions?  Help is much appreciated.

TIA

/tony

-- 
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




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