Re: [Freeipa-users] user delete command hangs kdc and ldap stop responding

[Ludwig Krispenz]

On 09/18/2015 12:24 AM, HECTOR LOPEZ wrote:

This is rhel 7.1 with ipa version 4.1.0

user-show shows the user. However, if the user contains 
ipaNTSecurityIdentifier: attribute, user-del hangs with no response.


Meanwhile, the KDC and 389ds stop working. The only way to recover 
functionality is to reboot the machine.  ipactl restart does nothing.

If it hangs again, could you get a pstack of the slapd process ?
If you then kill slapd, does ipactl restart work ?


In the ldap access log I see this when trying to delete user sclown:

[14/Sep/2015:09:28:27 -0700] conn=326 op=18 RESULT err=0 tag=101 
nentries=0 etime=0
[14/Sep/2015:09:28:27 -0700] conn=326 op=19 DEL 
dn="uid=sclown,cn=users,cn=accounts,dc=some,dc=domain,dc=org"
[14/Sep/2015:09:30:03 -0700] conn=12 op=442 MOD 
dn="cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca"
[14/Sep/2015:09:30:03 -0700] conn=12 op=442 RESULT err=1 tag=103 
nentries=0 etime=0
[14/Sep/2015:09:30:06 -0700] conn=20 op=288 SRCH 
base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 
filter="(objectClass=securityDomainSessionEntry)" attrs="cn"
[14/Sep/2015:09:30:06 -0700] conn=20 op=288 RESULT err=32 tag=101 
nentries=0 etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 SRCH 
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 
filter="(certStatus=INVALID)" attrs="objectClass serialno notBefore 
notAfter duration extension subjectName userCertificate version 
algorithmId signingAlgorithmId publicKeyData"

[14/Sep/2015:09:30:08 -0700] conn=12 op=444 SORT notBefore
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 VLV 200:0:20150914093009Z 
1:0 (0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=444 RESULT err=0 tag=101 
nentries=0 etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 SRCH 
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 
filter="(certStatus=VALID)" attrs="objectClass serialno notBefore 
notAfter duration extension subjectName userCertificate version 
algorithmId signingAlgorithmId publicKeyData"

[14/Sep/2015:09:30:08 -0700] conn=12 op=445 SORT notAfter
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 VLV 200:0:20150914093009Z 
1:10 (0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=445 RESULT err=0 tag=101 
nentries=1 etime=0
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 SRCH 
base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 
filter="(certStatus=REVOKED)" attrs="objectClass revokedOn serialno 
revInfo notAfter notBefore duration extension subjectName 
userCertificate version algorithmId signingAlgorithmId publicKeyData"
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 VLV 200:0:20150914093009Z 
0:0 (0)
[14/Sep/2015:09:30:08 -0700] conn=12 op=446 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[14/Sep/2015:09:30:08 -0700] conn=12 op=447 SRCH 
base="ou=certificateRepository,ou=ca,o=ipaca" scope=0 
filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="description"
[14/Sep/2015:09:30:08 -0700] conn=12 op=447 RESULT err=0 tag=101 
nentries=1 etime=0

[14/Sep/2015:09:30:19 -0700] conn=322 op=6 UNBIND

Then in the ldap error log I see this, which makes me think there is a 
problem with the changelog:


[14/Sep/2015:09:30:03 -0700] - dn2entry_ext: Failed to get id for 
changenumber=91314,cn=changelog from entryrdn index (-30993)
[14/Sep/2015:09:30:03 -0700] - Operation error fetching 
changenumber=91314,cn=changelog (null), error -30993.
[14/Sep/2015:09:30:03 -0700] DSRetroclPlugin - replog: an error 
occured while adding change number 91314, dn = 
changenumber=91314,cn=changelog: Operations error.
[14/Sep/2015:09:30:03 -0700] retrocl-plugin - retrocl_postob: 
operation failure [1]


After this both kdc and ldap stop responding. In the krb5kdc.log I see 
server errors after the user-del command is run. The only way to 
resume normal operations is to restart the whole machine. ipactl 
restart doesn't work.


Any help would be highly appreciated!




-- 
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] Add custom script

[Andreas Ladanyi]

Hi,

iam looking for a possibility to add custom script which will be
executed after creating a new user.

Iam using the latest release of FreeIPA 4.2 from COPR in Fedora 22.

I found this post in the archive from 2011:

https://www.redhat.com/archives/freeipa-users/2011-September/msg00076.html

Is this in principle also the way in FreeIPA 4.2 ?

regards,
Andreas

-- 
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] rhel 6.7 upgrade - sssd/sudo

[Jakub Hrozek]

On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> I've narrowed it down a bit doing some testing.  The sudo rules work when I 
> remove the user group restriction from them.  My sudo rules all have my ad 
> groups in the rule
> 
>   Rule name: ad_linux_admins
>   Enabled: TRUE
>   Host category: all
>   Command category: all
>   RunAs User category: all
>   RunAs Group category: all
>   User Groups: ad_linux_admins  <- if I remove this then the rule gets applied

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

What is the exact IPA server version?

-- 
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] Custom scripts

[Andreas Ladanyi]

Hi,

iam looking for a possibility to add custom script which will be
executed after creating a new user.

Iam using the latest release of FreeIPA 4.2 from COPR in Fedora 22.

I found this post in the archive from 2011:

https://www.redhat.com/archives/freeipa-users/2011-September/msg00076.html

Is this in principle also the way in FreeIPA 4.2 ?

regards,
Andreas



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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] Add custom script

[Andreas Ladanyi]

Hi,


Sorry, my last post was with wrong link.


iam looking for a possibility to add custom script which will be
executed after creating a new user.

Iam using the latest release of FreeIPA 4.2 from COPR in Fedora 22.

I found this post in the archive:

http://freeipa-users.redhat.narkive.com/cgjMKenp/user-custom-script

Is this in principle also the way in FreeIPA 4.2 ?

regards,
Andreas

-- 
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] 4.1 -> 4.2

[Martin Kosek]

Good to hear! Feedback is very welcome :-)

On 09/17/2015 09:37 PM, Janelle wrote:
> thank you - just downloaded the beta to check it out.
> 
> ~J
> 
> On 9/17/15 10:20 AM, Alexander Bokovoy wrote:
>> On Thu, 17 Sep 2015, Janelle wrote:
>>> Here is an interesting problem. Currently running 4.1 on RHEL 7.1 -- I would
>>> like to migrate to 4.2, but that seems to only be running on Fedora these
>>> days.  Is there a way to bring up a 4.2.1c and migrate to it from 4.1c using
>>> the ipa migrate tool? Or is theree another way possible??
>> Just wait for RHEL 7.2 release. Beta version is already out and it
>> includes IPA 4.2.
>>
>> http://red.ht/1i65UND
>>
> 

-- 
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] user delete command hangs kdc and ldap stop responding

[HECTOR LOPEZ]

Ludwig Krispenz,

This is the output of gstack on ns-slapd (pstack on rhel), also killing the
ns-slapd proces gave this error "ipa: ERROR: cannot connect to
'ldapi://%2fvar%2frun%2fslapd-GSEIS-UCLA-EDU.socket': " After that I could
use ipactl restart and the command runs successfully.   Thank you for
helping me. Again, here is the pstack output of ns-slapd:


-sh-4.2$ sudo gstack 2197

Thread 45 (Thread 0x7f3ad8144700 (LWP 2651)):

#0  0x7f3ae74028f3 in select () from /lib64/libc.so.6

#1  0x7f3ae997d459 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0

#2  0x7f3adc11e4a7 in deadlock_threadmain () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so

#3  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#4  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#5  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 44 (Thread 0x7f3ad7943700 (LWP 2652)):

#0  0x7f3ae74028f3 in select () from /lib64/libc.so.6

#1  0x7f3ae997d459 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0

#2  0x7f3adc122576 in checkpoint_threadmain () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so

#3  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#4  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#5  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 43 (Thread 0x7f3ad7142700 (LWP 2653)):

#0  0x7f3ae74028f3 in select () from /lib64/libc.so.6

#1  0x7f3ae997d459 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0

#2  0x7f3adc11e71f in trickle_threadmain () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so

#3  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#4  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#5  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 42 (Thread 0x7f3ad6941700 (LWP 2654)):

#0  0x7f3ae74028f3 in select () from /lib64/libc.so.6

#1  0x7f3ae997d459 in DS_Sleep () from /usr/lib64/dirsrv/libslapd.so.0

#2  0x7f3adc119437 in perf_threadmain () from
/usr/lib64/dirsrv/plugins/libback-ldbm.so

#3  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#4  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#5  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 41 (Thread 0x7f3ad6140700 (LWP 2655)):

#0  0x7f3ae76e1705 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0

#1  0x7f3ae7d37050 in PR_WaitCondVar () from /lib64/libnspr4.so

#2  0x7f3ae996d438 in slapi_wait_condvar () from
/usr/lib64/dirsrv/libslapd.so.0

#3  0x7f3ae058164e in cos_cache_wait_on_change () from
/usr/lib64/dirsrv/plugins/libcos-plugin.so

#4  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#5  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#6  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 40 (Thread 0x7f3ad593f700 (LWP 2656)):

#0  0x7f3ae7400b7d in poll () from /lib64/libc.so.6

#1  0x7f3addf0247c in ipa_cldap_worker () from
/usr/lib64/dirsrv/plugins/libipa_cldap.so

#2  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#3  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 39 (Thread 0x7f3ad513e700 (LWP 2657)):

#0  0x7f3ae76e1705 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0

#1  0x7f3ae7d37050 in PR_WaitCondVar () from /lib64/libnspr4.so

#2  0x7f3ae996d438 in slapi_wait_condvar () from
/usr/lib64/dirsrv/libslapd.so.0

#3  0x7f3ada7c0edd in roles_cache_wait_on_change () from
/usr/lib64/dirsrv/plugins/libroles-plugin.so

#4  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#5  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#6  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 38 (Thread 0x7f3ad493d700 (LWP 2658)):

#0  0x7f3ae76e1705 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0

#1  0x7f3ae7d37050 in PR_WaitCondVar () from /lib64/libnspr4.so

#2  0x7f3ae996d438 in slapi_wait_condvar () from
/usr/lib64/dirsrv/libslapd.so.0

#3  0x7f3ada7c0edd in roles_cache_wait_on_change () from
/usr/lib64/dirsrv/plugins/libroles-plugin.so

#4  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#5  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#6  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 37 (Thread 0x7f3ac700 (LWP 2659)):

#0  0x7f3ae76e1705 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0

#1  0x7f3ae7d37050 in PR_WaitCondVar () from /lib64/libnspr4.so

#2  0x7f3ae996d438 in slapi_wait_condvar () from
/usr/lib64/dirsrv/libslapd.so.0

#3  0x7f3ada7c0edd in roles_cache_wait_on_change () from
/usr/lib64/dirsrv/plugins/libroles-plugin.so

#4  0x7f3ae7d3c7bb in _pt_root () from /lib64/libnspr4.so

#5  0x7f3ae76dddf5 in start_thread () from /lib64/libpthread.so.0

#6  0x7f3ae740b1ad in clone () from /lib64/libc.so.6

Thread 36 (Thread 0x7f3acf7fe700 (LWP 2660)):

Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers

[Petr Vobornik]

On 09/17/2015 06:19 PM, Craig White wrote:

-Original Message-
From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: Thursday, September 17, 2015 4:59 AM
To: Martin Kosek; Craig White; freeipa-users@redhat.com; Jan Cholasta
Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) 
servers

On 09/17/2015 01:15 PM, Martin Kosek wrote:

On 09/16/2015 06:54 PM, Craig White wrote:

Virtually completed the steps listed here...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu
x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrat
ing-ipa-proc.html

Managed to get IPA2 deleted and removed from 'ipa-replica-manage list' so now 
it is down to IPA1. No amount of effort will seem to kill that sucker off.

ipa-replica-manage del ipa1.stt.local --force Connection to
'ipa1.stt.local' failed:
Forcing removal of ipa1.stt.local
Skipping calculation to determine if one or more masters would be orphaned.
No RUV records found.

$ ipa-replica-manage del ipa1.stt.local --force -c Connection to
'ipa1.stt.local' failed:
Forcing removal of ipa1.stt.local
Skipping calculation to determine if one or more masters would be orphaned.
No RUV records found.

$ ipa-replica-manage list
ipa1.stt.local: master
ipa3.stt.local: master
ipa4.stt.local: master

Obviously connection to ipa1 failed because in previous step, I had
to shut it down on ipa1 (ipactl stop)

What's the trick to get rid of an old, discontinued 'master' ?

Craig White


Quickly looking at ipa-replica-manage code, the del command will end
if there is no RUV. So it seems that in some of your previous RUV was
deleted, but server record was not.

What does
# ipa-replica-manage list-ruv
show?

Petr or Honza, is the only option here to
1) Use ldapdelete to delete the master record in cn=masters as a
hotfix for this issue


It will fix the replica manage output but replica cleanup does more things than 
just a removal of master entry. It also:
  deletes services of the host


This part could be done in web ui - check for 
/ipa1.stt.local@STT.LOCAL


where  is usually DNS, HTTP and ldap


  removes s4u2proxy configuration
  removes some ACIs

More info:
https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/replication.py#n1185



2) File a ticket to avoid get_ruv function exit the whole "del"
command when --force is in play to fix this long-term


https://fedorahosted.org/freeipa/ticket/5307

OK - I think I see the LDAP entries and just wanting confirmation before I do 
great harm  :-)

Dn: cn=ipa1.stt.local,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local


yes


If by ipa1_ETC you mean (assuming that your realm is STT.LOCAL):

Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute 
memberPrincipal ipa1_ETC


HTTP/ipa1.stt.local@STT.LOCAL


Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local - 
attribute memberPrincipal ipa1_ETC


ldap/ipa1.stt.local@STT.LOCAL





The one DN and the 2 attributes are what I should delete to get rid of this 
dead master?

Rummaging around, I do see other hanging chads (pardon the election season 
humor)...

DN: dnaHostname ipa1.stt.local + 0,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local 
(that is apparently 'dnaPortNum 0 and dnaSecurePortNum 636)
DN: dnaHostname ipa1.stt.local + 389,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local 
(that is apparently 'dnaPortNum 389 and dnaSecurePortNum 636)

And if  were to delete the first one, there wouldn't be any entries pointing to 
port '0' but that just looks strange to me anyway. If I delete both the above, 
then all that is left is just the 2 new RHEL 7 IPA/iDM servers on ports 389/636 
which seems right to me.


Check if the DNA range configuration for the deleted master does contain 
dna RemainingValues other than 0. In that case you might want to check 
DNA configuration of other masters to be sure that other master can 
issue posix numbers.


DNA ranges could be also configured using ipa-replica-manage.



If there are actual ACI's to edit, I am afraid I don't have a tool to do that 
very easily.


Could  be seen e.g., when browsing LDAP structure in Apache Directory 
studio as Directory Manager. It's 'aci' attribute of entry 
cn=masters,cn=ipa,cn=etc,$SUFFIX


There should be two which contain the deleted replica hostname. One has 
name "Read IPA Masters" the other "Modify IPA Masters".





Thanks

Craig




--
Petr Vobornik

--
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] Red Hat 5 and 6 with IPA Client v. 4

[Andrey Ptashnik]

I think I got it working.

Solution in my case was to run following on client nodes:

yum install sssd-1.12.4-47.el6.x86_64

And on IPA server for each Forward and Reverse lookup zone I ran:

ipa dnszone-mod X.COM. --allow-sync-ptr=TRUE --dynamic-update=TRUE
ipa dnszone-mod 44.28.10.in-addr.arpa. --allow-sync-ptr=TRUE 
--dynamic-update=TRUE

Ultimately I think bringing all nodes to SSSD 1.12.4 version solved the problem.

Thank you, IPA team, for your support!

Regards,

Andrey Ptashnik






On 9/17/15, 10:32 AM, "Rob Crittenden"  wrote:

>Andrey Ptashnik wrote:
>> Any ideas on that?
>
>/var/log/ipaclient-install.log probably has more details on the DNS
>update failure.
>
>rob
>
>> 
>> Regards,
>> 
>> Andrey Ptashnik | Network Architect
>> CCC Information Services Inc.
>> 222 Merchandise Mart Plaza, Suite 900 Chicago, IL 60654
>> Office: +1-312-229-2533 | Cell : +1-773-315-0200 | aptash...@cccis.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 9/16/15, 11:30 AM, "freeipa-users-boun...@redhat.com on behalf of Andrey 
>> Ptashnik" > aptash...@cccis.com> wrote:
>> 
>>> Alexander,
>>>
>>> Thank you for your feedback!
>>>
>>> In my environment I noticed that client machines that are on Red Hat 6 have 
>>> version 3.0.0 of IPA client installed.
>>>
>>> [root@ptr-test-6 ~]# yum list installed | grep ipa
>>> ipa-client.x86_64  3.0.0-47.el6
>>> ipa-python.x86_64  3.0.0-47.el6
>>>
>>>
>>> [root@ptr-test-6 ~]# yum list installed | grep sssd
>>> python-sssdconfig.noarch   1.12.4-47.el6
>>> sssd.x86_641.12.4-47.el6
>>> sssd-ad.x86_64 1.12.4-47.el6
>>> sssd-client.x86_64 1.12.4-47.el6
>>> sssd-common.x86_64 1.12.4-47.el6
>>> sssd-common-pac.x86_64 1.12.4-47.el6
>>> sssd-ipa.x86_641.12.4-47.el6
>>> sssd-krb5.x86_64   1.12.4-47.el6
>>> sssd-krb5-common.x86_641.12.4-47.el6
>>> sssd-ldap.x86_64   1.12.4-47.el6
>>> sssd-proxy.x86_64  1.12.4-47.el6
>>> [root@ptr-test-6 ~]# 
>>>
>>>
>>> And I noticed particular behavior with IPA client 3.0.0 and IPA server 4.1 
>>> - when I add machines to the domain using command below:
>>>
>>> # ipa-client-install --enable-dns-updates --ssh-trust-dns —mkhomedir
>>>
>>> DNS record populate in Forward lookup zone, but no PTR records appear in 
>>> Reverse lookup zones. That behavior is not the same with IPA client 4.1 and 
>>> IPA server 4.1 version combination.
>>>
>>> Also during IPA client v. 3.0.0 configuration on version 6 of Red Hat I see 
>>> output below:
>>>
>>> Synchronizing time with KDC...
>>> Enrolled in IPA realm X.COM
>>> Attempting to get host TGT...
>>> Created /etc/ipa/default.conf
>>> New SSSD config will be created
>>> Configured sudoers in /etc/nsswitch.conf
>>> Configured /etc/sssd/sssd.conf
>>> Configured /etc/krb5.conf for IPA realm X.COM
>>> trying https://ipa-idm.X.COM/ipa/xml
>>> Forwarding 'env' to server u'https://ipa-idm.X.COM/ipa/xml'
>>> Failed to update DNS records.
>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>>> Forwarding 'host_mod' to server u'https://ipa-idm.X.COM/ipa/xml'
>>> SSSD enabled
>>> Configuring X.COM as NIS domain
>>> Configured /etc/openldap/ldap.conf
>>> NTP enabled
>>> Configured /etc/ssh/ssh_config
>>> Configured /etc/ssh/sshd_config
>>> Client configuration complete.
>>>
>>>
>>> Regards,
>>>
>>> Andrey Ptashnik
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 9/16/15, 8:43 AM, "Alexander Bokovoy"  wrote:
>>>
 On Wed, 16 Sep 2015, Andrey Ptashnik wrote:
> Dear IPA Team,
>
> We have a situation in our datacenter where we deployed Red Hat 7.1
> with IPA server 4.1 and on the other hand we still have older machines
> with Red Hat 5 and 6. I noticed that repositories associated with
> version 6 have older version of the client software – v.3.0. Therefore
> some functionality is missing from client package 3 vs 4, like
> automatic update of both forward and reverse DNS records.
>
> Is it possible to install IPA client v. 4 on Red Hat 5 and 6 without
> much breaking dependencies in OS?
 You don't need to install IPA python packages on older machines. These
 packages are mostly for administration purposes.

 Automatic update of forward/reverse DNS zones is done by SSSD. RHEL 6
 version of SSSD is on par with RHEL 7 version in the recent updates.
 Additionally, MIT Kerberos backports were done in the recent updates to
 allow OTP functionality in RHEL6 as well. So most of features are there
 already, client-wise.

 RHEL5 version does not have such updates and you can implement most of
 the support with existing SSSD and output of 'ipa-advise' tool on IPA
 

Re: [Freeipa-users] ipaSshPubKey and ldapsearch

[Karl Forner]

Sorry, my mistake.
The following works fine:
% ldapsearch -x -D
'uid=ldap_gitlab,cn=users,cn=accounts,dc=quartzbio,dc=com' -W uid=karl
cn ipaSshPubKey

Karl



On Fri, Sep 18, 2015 at 3:13 PM, Karl Forner  wrote:
> Hello,
>
> I'm trying to integrate the freeIPA SSH public key with gitlab
> Enterprise Edition.
>
> They have a configuration setting **ldap_sync_ssh_keys** that I tried
> to set to 'ipaSshPubKey'
> but it does not work.
>
> While trying to understand the problem, I realized that I don't even
> know how to retrieve this attribute using ldapsearch.
>
> Could you help with the ldapsearch command-line ?
>
> Could it be a permission problem ?
>
> Thanks,
> Karl

-- 
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] ipaSshPubKey and ldapsearch

[Karl Forner]

Hello,

I'm trying to integrate the freeIPA SSH public key with gitlab
Enterprise Edition.

They have a configuration setting **ldap_sync_ssh_keys** that I tried
to set to 'ipaSshPubKey'
but it does not work.

While trying to understand the problem, I realized that I don't even
know how to retrieve this attribute using ldapsearch.

Could you help with the ldapsearch command-line ?

Could it be a permission problem ?

Thanks,
Karl

-- 
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] rhel 6.7 upgrade - sssd/sudo

[Andy Thompson]

> -Original Message-
> From: Jakub Hrozek [mailto:jhro...@redhat.com]
> Sent: Friday, September 18, 2015 4:42 AM
> To: Andy Thompson 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] rhel 6.7 upgrade - sssd/sudo
> 
> On Thu, Sep 17, 2015 at 11:42:54AM +, Andy Thompson wrote:
> > I've narrowed it down a bit doing some testing.  The sudo rules work when
> I remove the user group restriction from them.  My sudo rules all have my ad
> groups in the rule
> >
> >   Rule name: ad_linux_admins
> >   Enabled: TRUE
> >   Host category: all
> >   Command category: all
> >   RunAs User category: all
> >   RunAs Group category: all
> >   User Groups: ad_linux_admins  <- if I remove this then the rule gets
> applied
> 
> Nice catch. Is the group visible after you login and run id?

Ya the groups show up for the users using id

[athompson@mhbenp.local@mdhixuatsmtp01 ~]$ id
uid=1506401106(athompson@mhbenp.local) gid=1506401106(athompson@mhbenp.local) 
groups=1506401106(athompson@mhbenp.local),124910(ad_linux_admins),1506400512(domain
 admins@mhbenp.local),1506400513(domain users@mhbenp.local),1506401124(admin 
vpn users@mhbenp.local),1506401239(linux admins@mhbenp.local)

> 
> What is the exact IPA server version?


Installed Packages
ipa-server.x86_64   
4.1.0-18.el7_1.4  


thanks

-andy


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

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Jakub Hrozek]

On Thu, Sep 17, 2015 at 10:33:41AM -0700, Gustavo Mateus wrote:
> When I use id_provider=ipa I get:
> 
> [sssd[be[default]]] [main] (0x0010): Could not initialize backend [2]

Ah, I think they simply don't package the IPA backend.

Time to file an RFE with Amazon? :-)

> 
> 
> Adding a [ssh] section with just "debug_level = 10"on it, I get:
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [get_client_cred] (0x4000): Client
> creds: euid[174221] egid[174221] pid[6295].
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [accept_fd_handler] (0x0400): Client
> connected!
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Received client version [0].
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
> Offered version [0].
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
> Requested domain []
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_cmd_parse_request] (0x0400):
> Parsing name [admin][]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name] (0x0100): Domain
> not provided!
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name_for_domains]
> (0x0200): name 'admin' matched without domain, user is admin
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_ssh_cmd_get_user_pubkeys]
> (0x0400): Requesting SSH user public keys for [admin] from []
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x40aba0:1:admin@default]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [default][1][1][name=admin]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_add_timeout] (0x2000): 0xd32ba0
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_internal_get_send] (0x0400):
> Entering request [0x40aba0:1:admin@default]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_remove_timeout] (0x2000):
> 0xd32ba0
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn:
> 0xd310f0
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 0 errno: 0 error message: Success
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ssh_user_pubkeys_search_next]
> (0x0400): Requesting SSH user public keys for [admin@default]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_parse_name] (0x0100): Domain
> not provided!
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
> "ltdb_callback": 0xd3f3b0
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Added timed event
> "ltdb_timeout": 0xd3f470
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Running timer event
> 0xd3f3b0 "ltdb_callback"
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Destroying timer
> event 0xd3f470 "ltdb_timeout"
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [ldb] (0x4000): Ending timer event
> 0xd3f3b0 "ltdb_callback"
> 
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x40aba0:1:admin@default]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0xd34eb0][17]
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [client_recv] (0x0200): Client
> disconnected!
> (Thu Sep 17 17:27:12 2015) [sssd[ssh]] [client_destructor] (0x2000):
> Terminated client [0xd34eb0][17]
> 
> 
> 
> 
> ldbsearch shows this (ldbsearch -H /var/lib/sss/db/cache_default.ldb
> name=admin):
> 
> 
> asq: Unable to register control with rootdse!
> # record 1
> dn: name=admin,cn=users,cn=default,cn=sysdb
> createTimestamp: 1442509579
> fullName: Administrator
> gecos: Administrator
> gidNumber: 174220
> homeDirectory: /home/admin
> loginShell: /bin/bash
> name: admin
> objectClass: user
> uidNumber: 174220
> originalDN: uid=admin,cn=users,cn=compat,dc=my,dc=domain,dc=com
> originalModifyTimestamp: 20150829000451Z
> entryUSN: 1428
> lastUpdate: 1442509579
> dataExpireTimestamp: 1442514979
> distinguishedName: name=admin,cn=users,cn=default,cn=sysdb

The communication between the ssh responder and the back end went fine.
I think I should have been more careful the first time around, looks
like the backend cannot find the attribute in LDAP (some ACI problems,
maybe?)

>From your earlier logs:
(Wed Sep 16 18:13:36 2015) [sssd[be[default]]] [sdap_attrs_add_ldap_attr]   

Re: [Freeipa-users] SSSD client (amazon linux) + IPA server (Redhat)

[Gustavo Mateus]

That only shows this:

# extended LDIF
#
# LDAPv3
# base