[Freeipa-users] LDAPcon 2017

[Rich Megginson]

This year's LDAPcon 2017 will be in Bruxelles 19th-20th October, 2017.
Kudos to Paola PENATI and Benoit MORTIER at OpenSides for organizing the 
event.


If you'd like to submit a conference talk then please have a look at the 
CfP:


https://ldapcon.org/2017/call-for-papers/

Submission deadline : 28th May

--
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] Adjusting nsslapd-cachememsize

[Rich Megginson]

On 03/20/2017 03:14 PM, Lachlan Musicman wrote:
Directly editing the lse.ldif didn't work. ipactl start hangs on 
pki-tomcatd. I think I've broken it. I seem to recall ldap not liking 
being edited by hand.


You have to make sure dirsrv is not running before you edit dse.ldif.  
Not sure if ipactl stop will wait until all services are not running.




cheers
L.

--
The most dangerous phrase in the language is, "We've always done it 
this way."


- Grace Hopper

On 17 March 2017 at 19:45, Bob Hinton > wrote:


Hi Lachlan,

This is probably a complete hack, but the way I've changed
nsslapd-cachememsize in the past is -

On each ipa replica in turn -

 1. ipactl stop
 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif- (where DOMAIN is
your server's domain/realm - not sure which) find and change
the value of nsslapd-cachememsize
 3. ipactl start

This seemed to work in that it made the error messages go away and
it made heavily loaded servers more stable. However, I've not
tried this on a recent version of ipa so it may no longer work or
not be needed any more.

Regards

Bob


On 17/03/2017 02:20, Lachlan Musicman wrote:

While going through the logs on the FreeIPA server, I noticed this:


WARNING: changelog: entry cache size 2097152 B is less than db
size 12804096 B; We recommend to increase the entry cache size
nsslapd-cachememsize.


I have found a number of documents:

What it is:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html



How to tune it:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html




etc etc.

I have no idea of what the secret password is for the
"cn=directory manager" and can't find any information about where
I might find it or where or when it might have been set anywhere.
I have found a number of likely candidates, but none have worked.

I found this page:

https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password


but I'd prefer to not change the password if possible.

cheers
L.



--
The most dangerous phrase in the language is, "We've always done
it this way."

- Grace Hopper









--
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] Identification with openLDAP and authorization with FreeIPA

[Rich Megginson]

On 01/31/2017 04:46 PM, Michaël Van de Borne wrote:

That was the feared, but somehow expected, answer.

Any entry point/documentation about how to start such a script?


Do FreeIPA and OpenLDAP still support the syncrepl protocol?



cheers,

m.

--
*Michaël Van de Borne*
Free Bird Computing SPRL - Gérant
104 rue d'Azebois, 6230 Thiméon
*Tel:* +32(0)472 695716
*Skype:* mikemowgli
*TVA:* BE0637.834.386
Linkedin profile 



Le 31-01-17 à 16:42, Alexander Bokovoy a écrit :

On ti, 31 tammi 2017, Michaël Van de Borne wrote:

h, ok, thank you.

But indeed, I would need HBAC and sudo rules in the future.
So I believe the only exit here is to keep openLDAP and FreeIPA in 
sync.

Any clue on how to do this efficiently?

Well, we have 'ipa migrate-ds' functionality but this is not really
designed for continuous synchronisation. Neither is using a replication
mechanism as that was not designed to deal with inconsistent schema on
both sides (OpenLDAP schema is most likely not 1:1 to FreeIPA).

Doing a custom add/modify script looks like the only solution.




Thank you,

Cheers,

m.

Le 31-01-17 à 16:23, Alexander Bokovoy a écrit :

On ti, 31 tammi 2017, Michaël Van de Borne wrote:

Hello list,

Here's my situation:
I'm installing Hadoop for a customer, and the Hadoop cluster is 
secured with Kerberos. I used FreeIPA as a KDC.

The customer uses openLDAP as a directory server.

For now, our solution is to copy the whole openLDAP user base to 
FreeIPA, and then use FreeIPA for the identification and 
authorization (all the keytab stuff).

you mean authentication, not authorization here.

But keeping openLDAP and FreeIPA in sync is a nightmare, and I was 
wondering something:
Would it be possible to configure SSSD to simultaneously target 
the openLDAP server to identify a user, and the FreeIPA server to 
get the tickets?

Here is the thing: yes, you can do that by configuring explicitly
identity and authentication providers in sssd.conf. Set identity
provider to ldap and authentication provider to krb5, add necessary
configuration parameters and that would work. No HBAC, no SUDO rules,
etc, but that's what you want, it seems.

Look at sssd-ldap and sssd-krb5 manual pages.

When you configure identity provider to IPA or AD in sssd.conf, you 
are
just setting defaults for all other providers to the defaults of 
IPA or

AD provider. If you use a different identity provider, you'd need to
define proper authentication.


That way, we can avoid having to keep openLDAP and FreeIPA in sync...

_*OR*_

Is there an efficient way to keep openLDAP and FreeIPA in sync?





--
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] Best and Secure Way for a System Account

[Rich Megginson]

On 10/21/2016 08:05 AM, Günther J. Niederwimmer wrote:

Hello,

Thanks for the answer,

Am Freitag, 21. Oktober 2016, 07:11:58 schrieb Rich Megginson:

On 10/21/2016 06:42 AM, Günther J. Niederwimmer wrote:

Hello Martin and List,

Pardon me, but anything is wrong with the ldif i

ldapmodify -D 'cn=Directory Manager' -W -f alias.ldif
Enter LDAP Password:
ldapmodify: invalid format (line 5) entry:
"cn=users,cn=accounts,dc=4gjn,dc=com"

dn: cn=users,cn=accounts,dc=4gjn,dc=com

this is in the ldif ?

"""
dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci:
(targetattr="mailAlternateAddress")(targetfilter="(objectClass=mailrecipient)")
(version
3.0; acl "Allow system account to read mail address"; allow(read,
search, compare) userdn =
"ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com";;)
""

but what is wrong ?


Sorry, I don't know, I thought it was complaining about the DN line format.


I have search and read now any Days, but this FreeIPA / LDAP Problem have
a to high level for me :-(.

Pleas help again..

Thanks for a answer

Am Montag, 17. Oktober 2016, 14:41:01 schrieb Martin Babinsky:

On 10/17/2016 02:25 PM, Günther J. Niederwimmer wrote:

Hello Martin and List

Thanks for the answer and Help.

I mean my big Problem is to understand the way to configure a ACI :-(.

# ldapmodify -x -D 'cn=Directory Manager' -W

   dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
   changetype: add
   objectclass: account
   objectclass: simplesecurityobject
   uid: system
   userPassword: secret123
   passwordExpirationTime: 20380119031407Z
   nsIdleTimeout: 0
   

^D


https://www.freeipa.org/page/HowTo/LDAP#System_Accounts

The IPA Docs have no time stamp to found out, is this actual or old
:-(.

Thanks for a answer,

Hi Gunther,

that LDIF look ok to me.

Do not forget that you must set up the correct ACIs in order for the
system account to see the 'mailAlternaleAddress' attribute.

See the following document for a step-by-step guide on how to write ACIs:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10
/ht
ml/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.h
tml

To allow the system account read access to your custom attributes, you
can use LDIF like this (untested, hopefully I got it right from the top
of my head):

"""
dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci:
(targetattr="mailAlternateAddress")(targetfilter="(objectClass=mailrecipi
ent )")(version 3.0; acl "Allow system account to read mail address";
allow(read,
search, compare) userdn =
"ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com";;)
"""
save it to file and then call

ldapmodify -D 'cn=Directory Manager' -W -f aci.ldif

to add this ACI to cn=users subtree. The ACI then applies to all entries
in the subtree.



--
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] Best and Secure Way for a System Account

[Rich Megginson]

On 10/21/2016 06:42 AM, Günther J. Niederwimmer wrote:

Hello Martin and List,

Pardon me, but anything is wrong with the ldif i

ldapmodify -D 'cn=Directory Manager' -W -f alias.ldif
Enter LDAP Password:
ldapmodify: invalid format (line 5) entry:
"cn=users,cn=accounts,dc=4gjn,dc=com"


dn: cn=users,cn=accounts,dc=4gjn,dc=com



I have search and read now any Days, but this FreeIPA / LDAP Problem have a to
high level for me :-(.

Pleas help again..

Thanks for a answer

Am Montag, 17. Oktober 2016, 14:41:01 schrieb Martin Babinsky:

On 10/17/2016 02:25 PM, Günther J. Niederwimmer wrote:

Hello Martin and List

Thanks for the answer and Help.

I mean my big Problem is to understand the way to configure a ACI :-(.

# ldapmodify -x -D 'cn=Directory Manager' -W
  dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
  changetype: add
  objectclass: account
  objectclass: simplesecurityobject
  uid: system
  userPassword: secret123
  passwordExpirationTime: 20380119031407Z
  nsIdleTimeout: 0
  
^D


https://www.freeipa.org/page/HowTo/LDAP#System_Accounts

The IPA Docs have no time stamp to found out, is this actual or old :-(.

Thanks for a answer,

Hi Gunther,

that LDIF look ok to me.

Do not forget that you must set up the correct ACIs in order for the
system account to see the 'mailAlternaleAddress' attribute.

See the following document for a step-by-step guide on how to write ACIs:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/ht
ml/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html

To allow the system account read access to your custom attributes, you
can use LDIF like this (untested, hopefully I got it right from the top
of my head):

"""
dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci:
(targetattr="mailAlternateAddress")(targetfilter="(objectClass=mailrecipient
)")(version 3.0; acl "Allow system account to read mail address";
allow(read,
search, compare) userdn =
"ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com";;)
"""
save it to file and then call

ldapmodify -D 'cn=Directory Manager' -W -f aci.ldif

to add this ACI to cn=users subtree. The ACI then applies to all entries
in the subtree.



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

[Rich Megginson]

On 08/29/2016 10:53 AM, Rakesh Rajasekharan wrote:

Hi Thierry,

My machine has 30GB RAM ..and  389-ds version is 1.3.4

ldapsearch shows the values for nsslapd-cachememsize updated to 200MB.

ldapsearch -LLL -o ldif-wrap=no -D "cn=directory manager" -w 
'mypassword' -b 'cn=userRoot,cn=ldbm 
database,cn=plugins,cn=config'|grep nsslapd-cachememsize

nsslapd-cachememsize: 209715200


So, it seems to have updated though seeing that warning(WARNING: 
ipaca: entry cache size 10485760B is less than db size 11599872B) in 
the log confuses me a bit.


Thers one more entry that I found from the ldapsearch to be bit low

nsslapd-dncachememsize: 10485760
maxdncachesize: 10485760

Should I update these as well to a higher value

At the time when the issue happened, the memory usage as well as the 
overall load of the system was very low .
I will try reproducing the issue atleast in my QA env..probably by 
trying to mock  simultaneous parallel logins to a large number of hosts


To monitor your cache sizes, please use the dbmon.sh tool provided with 
your distro.  If that is not available with your particular distro, see 
https://github.com/richm/scripts/wiki/dbmon.sh





thanks
Rakesh




On Mon, Aug 29, 2016 at 8:16 PM, thierry bordaz > wrote:


Hi Rakesh,

Those tuning may depend on the memory available on your machine.
nsslapd-cachememsize allows the entry cache to consume up to 200Mb
but its memory footprint is known to go above.
200Mb both looks pretty good to me. How large is your machine ?
What is your version of 389-ds ?

Those warnings do not change your settings. It just raise that
entry cache of 'ipaca' and 'retrocl' are small but it is fine. The
size of the entry cache is important mostly in userRoot.
You may double check the actual values, after restart, with
ldapsearch on 'cn=userRoot,cn=ldbm database,cn=plugins,cn=config'
and 'cn=config,cn=ldbm database,cn=plugins,cn=config'.

A step is to know what will be response time of DS to know if it
is responsible of the hang or not.
The logs and possibly pstack during those intermittent hangs will
help to determine that.

regards
thierry





On 08/29/2016 04:25 PM, Rakesh Rajasekharan wrote:

I tried increasing the nsslapd-dbcachesize and
nsslapd-cachememsize in my QA envs to 200MB.

However, in my log files, I still see this message
[29/Aug/2016:04:34:37 +] - WARNING: ipaca: entry cache size
10485760B is less than db size 11599872B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[29/Aug/2016:04:34:37 +] - WARNING: changelog: entry cache
size 2097152B is less than db size 441647104B; We recommend to
increase the entry cache size nsslapd-cachememsize.

these are my ldif files that i used to modify the values
modify entry cache size
cat modify-cache-mem-size.ldif
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-cachememsize
nsslapd-cachememsize: 209715200

modify db cache size
cat modfy-db-cache-size.ldif
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-dbcachesize
nsslapd-dbcachesize: 209715200

After modifying , i restarted IPA services

Is there anything else that  I need to take care of as the logs
suggest its still not getting the updated values

Thanks
Rakesh

On Mon, Aug 29, 2016 at 6:07 PM, Rakesh Rajasekharan
mailto:rakesh.rajasekha...@gmail.com>> wrote:

Hi Thierry,

Coz of the issues we had to revert back to earlier running
openldap in production.

I have now done a few TCP related changes in sysctl.conf and
have also increased the nsslapd-dbcachesize and
nsslapd-cachememsize to 200MB

I will again start migrating hosts back to IPA and see if I
face the earlier issue.

I will update back once I have something


Thanks,
Rakesh



On Thu, Aug 25, 2016 at 2:17 PM, thierry bordaz
mailto:tbor...@redhat.com>> wrote:



On 08/25/2016 10:15 AM, Rakesh Rajasekharan wrote:

All of the troubleshooting seems fine.


However, Running libconv.pl  gives me
this output

- Recommendations -

 1.  You have unindexed components, this can be caused
from a search on an unindexed attribute, or your
returned results exceeded the allidsthreshold. Unindexed
components are not recommended. To refuse unindexed
searches, switch 'nsslapd-require-index' to 'on' under
your database entry (e.g. cn=UserRoot,cn=ldbm
database,cn=plugins,cn=config).

 2.  You have a significant difference between binds and
unbinds.  You may want to investigate this difference.


   

Re: [Freeipa-users] Active Directory password sync fails with RC 34

[Rich Megginson]

Great!  Glad you got that working.

Next step is to use AD trust instead of sync . . .

On 06/21/2016 12:58 AM, Toby Gale wrote:

Thanks for the help Rich.

Looking at the log I noticed some extra characters in the DN that 
corresponds to "Search Base".  I got the Windows admin to share his 
RDP session to the DC and had a look at the registry in 
"HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync". I noticed the same 
characters in the "Search Base" key.  I think the extra characters 
were accidentally copy-pasted from the documentation I sent them.


Removing them and restarting the service has resolved the problem.


On Mon, Jun 20, 2016 at 3:49 PM, Rich Megginson <mailto:rmegg...@redhat.com>> wrote:


On 06/18/2016 05:47 AM, Toby Gale wrote:


Hello,

After successfully adding a 'winsync' agreement and loading AD
data into FreeIPA I am trying to configure the password sync
software on the domain controllers.

I have installed the certificates and can successfully bind from
the domain controller using ldp.exe and the
'uid=passsync,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com' user.

I have edited the registry to increase logging, by setting
'HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync\Log Level' to '1' and I
am seeing the error:

06/17/16 08:47:32: Backoff time expired.  Attempting sync
06/17/16 08:47:32: Password list has 1 entries
06/17/16 08:47:32: Attempting to sync password for some.user
06/17/16 08:47:32: Searching for (ntuserdomainid=some.user)
06/17/16 08:47:32: Ldap error in QueryUsername
34: Invalid DN syntax



Take a look at the 389/dirsrv access log on your linux host at
/var/log/dirsrv/slapd-HOSTNAME/access - see if you can find the
error corresponding to this - it should be at the same approximate
date/time (make sure you check your time zones) and the RESULT
line should have err=34


06/17/16 08:47:32: Deferring password change for some.user
06/17/16 08:47:32: Backing off for 1024000ms

When I run the query from the CLI, it is successful:

$ ldapsearch -x -h ldaps://localhost -p 636 -D
'uid=passsync,cn=sysaccounts,cn=etc,dc=dc,my=domain,dc=com' -w
'password'  -b 'cn=users,cn=accounts,dc=my,dc=domain,dc=com'
'(ntuserdomainid=some.user)'

Can anyone help me resolve this?

Thanks.






--
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] Active Directory password sync fails with RC 34

[Rich Megginson]

On 06/18/2016 05:47 AM, Toby Gale wrote:


Hello,

After successfully adding a 'winsync' agreement and loading AD data 
into FreeIPA I am trying to configure the password sync software on 
the domain controllers.


I have installed the certificates and can successfully bind from the 
domain controller using ldp.exe and the 
'uid=passsync,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com' user.


I have edited the registry to increase logging, by setting 
'HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync\Log Level' to '1' and I am 
seeing the error:


06/17/16 08:47:32: Backoff time expired.  Attempting sync
06/17/16 08:47:32: Password list has 1 entries
06/17/16 08:47:32: Attempting to sync password for some.user
06/17/16 08:47:32: Searching for (ntuserdomainid=some.user)
06/17/16 08:47:32: Ldap error in QueryUsername
34: Invalid DN syntax



Take a look at the 389/dirsrv access log on your linux host at 
/var/log/dirsrv/slapd-HOSTNAME/access - see if you can find the error 
corresponding to this - it should be at the same approximate date/time 
(make sure you check your time zones) and the RESULT line should have err=34



06/17/16 08:47:32: Deferring password change for some.user
06/17/16 08:47:32: Backing off for 1024000ms

When I run the query from the CLI, it is successful:

$ ldapsearch -x -h ldaps://localhost -p 636 -D 
'uid=passsync,cn=sysaccounts,cn=etc,dc=dc,my=domain,dc=com' -w 
'password'  -b 'cn=users,cn=accounts,dc=my,dc=domain,dc=com' 
'(ntuserdomainid=some.user)'


Can anyone help me resolve this?

Thanks.





-- 
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] ns-slapd hangs for 2-3 minutes, then resumes.

[Rich Megginson]

On 06/13/2016 01:13 PM, Guillermo Fuentes wrote:

Hi Rich,

After I started running the stack traces, the problem hasn't happen as
frequently as it use to but today I was able to get the stack traces.
As they aren't similar I'll send them over to you in a separate email.

This is what I did to start the stack traces (CentOS 7):
# yum install -y --enablerepo=base-debuginfo 389-ds-base-debuginfo
ipa-debuginfo slapi-nis-debuginfo nspr-debuginfo
# yum install -y gdb
# systemctl stop ipa.service ; sleep 10; systemctl start ipa.service
# mkdir -p /var/log/stacktraces

Setup crontab to run the following every minute:
gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply
all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` >
/var/log/stacktraces/stacktrace.`date +%s`.txt 2>&1


It looks similar to https://fedorahosted.org/389/ticket/48341 but you 
already have that fix.


One of the problems is that ids_sasl_check_bind acquires the connection 
lock and holds it for a very long time, which causes the main loop to 
block on that connection, which is similar to the above problem, and 
also similar to https://fedorahosted.org/389/ticket/48882.  Basically, 
anything which holds the connection c_mutex lock too long can hang the 
server.  In your case, this stack trace:


poll sss_cli_make_request_nochecks sss_cli_check_socket 
sss_pac_make_request sssdpac_verify krb5int_authdata_verify 
rd_req_decoded_opt krb5_rd_req_decoded kg_accept_krb5 
krb5_gss_accept_sec_context_ext krb5_gss_accept_sec_context 
gss_accept_sec_context gssapi_server_mech_step sasl_server_step 
sasl_server_start ids_sasl_check_bind do_bind 
connection_dispatch_operation _pt_root start_thread clone


I'm not sure if this particular situation is known/fixed.  Perhaps there 
is a way to make the poll() called by sss_cli_make_request_nochecks() 
have a smaller timeout?


Does this look familiar to any ipa/sssd developer?



Thank you so much for your help,

Guillermo






On Wed, Jun 1, 2016 at 6:52 PM, Guillermo Fuentes
 wrote:

I'm now taking stack traces every minute and waiting for it to hang
again to check it. It happens usually under load but it's
unpredictable. Must likely tomorrow.
GUILLERMO FUENTES
SR. SYSTEMS ADMINISTRATOR

561-880-2998 x1337

guillermo.fuen...@modmed.com






On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson  wrote:

On 06/01/2016 10:37 AM, Guillermo Fuentes wrote:

Hi all,

We are experiencing a similar issue like the one discussed in the
following thread but we are running FreeIPA 4.2 on CentOS 7.2:
https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html


Are your stack traces similar?



LDAP service stops responding to queries (hangs). LDAP connections on
the server climb sometimes up to 10 times the normal amount and load
goes to 0. Then, the connections start to drop until they get to a
normal level and the LDAP service starts to respond to queries again.
This happens in between 3-5 minutes:

Time,LDAP conn, Opened files(ns-slapd), File
Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15
8:54:03,101,353,216,142,0.43,0.20,0.16
8:55:02,108,359,221,142,0.19,0.18,0.15
8:56:03,110,361,224,142,0.07,0.15,0.14
8:57:14,117,383,246,142,0.15,0.16,0.15
8:58:04,276,371,234,142,0.05,0.13,0.14
8:59:05,469,371,234,142,0.02,0.11,0.13
9:00:08,719,371,234,142,0.01,0.09,0.12
9:01:18,1060,371,234,142,0.00,0.07,0.12
9:02:10,742,371,233,142,0.10,0.09,0.12
9:03:06,365,372,235,142,0.13,0.10,0.13
9:04:04,262,379,242,142,0.87,0.29,0.19
9:05:02,129,371,233,142,0.51,0.31,0.20
9:06:03,126,377,240,142,0.42,0.33,0.22
9:07:03,125,377,238,142,0.17,0.27,0.21

Nothing is logged in the errors log file of the server having the
problem (ipa1 as an example).
In the replicas this is logged:
8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Timed out). Will retry later.
9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Timed out). Will retry later.

Nothing is logged in the access log file until after ns-slapd starts
responding again:
...
8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12"
name="replication-multimaster-extop"
8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0
8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12"
name="replication-multimaster-extop"
8:57:0

Re: [Freeipa-users] ns-slapd hangs for 2-3 minutes, then resumes.

[Rich Megginson]

On 06/01/2016 10:37 AM, Guillermo Fuentes wrote:

Hi all,

We are experiencing a similar issue like the one discussed in the
following thread but we are running FreeIPA 4.2 on CentOS 7.2:
https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html


Are your stack traces similar?



LDAP service stops responding to queries (hangs). LDAP connections on
the server climb sometimes up to 10 times the normal amount and load
goes to 0. Then, the connections start to drop until they get to a
normal level and the LDAP service starts to respond to queries again.
This happens in between 3-5 minutes:

Time,LDAP conn, Opened files(ns-slapd), File
Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15
8:54:03,101,353,216,142,0.43,0.20,0.16
8:55:02,108,359,221,142,0.19,0.18,0.15
8:56:03,110,361,224,142,0.07,0.15,0.14
8:57:14,117,383,246,142,0.15,0.16,0.15
8:58:04,276,371,234,142,0.05,0.13,0.14
8:59:05,469,371,234,142,0.02,0.11,0.13
9:00:08,719,371,234,142,0.01,0.09,0.12
9:01:18,1060,371,234,142,0.00,0.07,0.12
9:02:10,742,371,233,142,0.10,0.09,0.12
9:03:06,365,372,235,142,0.13,0.10,0.13
9:04:04,262,379,242,142,0.87,0.29,0.19
9:05:02,129,371,233,142,0.51,0.31,0.20
9:06:03,126,377,240,142,0.42,0.33,0.22
9:07:03,125,377,238,142,0.17,0.27,0.21

Nothing is logged in the errors log file of the server having the
problem (ipa1 as an example).
In the replicas this is logged:
8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Timed out). Will retry later.
9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Timed out). Will retry later.

Nothing is logged in the access log file until after ns-slapd starts
responding again:
...
8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1
to 172.20.2.45
8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12"
name="replication-multimaster-extop"
8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0
8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12"
name="replication-multimaster-extop"
8:57:00 -0400] conn=8838 op=2545 RESULT err=0 tag=120 nentries=0 etime=0
8:57:00 -0400] conn=10384 op=1227 RESULT err=0 tag=120 nentries=0 etime=0
8:57:00 -0400] conn=12382 op=-1 fd=170 closed - B1
8:57:00 -0400] conn=12383 op=0 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedSASLMechanisms
defaultnamingcontext namingContexts schemanamingcontext saslrealm"
8:57:00 -0400] conn=12384 op=-1 fd=234 closed - B1
8:57:00 -0400] conn=12385 op=0 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedSASLMechanisms
defaultnamingcontext namingContexts schemanamingcontext saslrealm"
8:57:00 -0400] conn=12383 op=0 RESULT err=0 tag=101 nentries=1 etime=0
8:57:00 -0400] conn=12386 op=-1 fd=236 closed - B1
8:57:00 -0400] conn=12385 op=0 RESULT err=0 tag=101 nentries=1 etime=0
8:57:00 -0400] conn=12387 op=0 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedSASLMechanisms
defaultnamingcontext namingContexts schemanamingcontext saslrealm"
8:57:00 -0400] conn=12387 op=0 RESULT err=0 tag=101 nentries=1 etime=0
8:57:00 -0400] conn=12385 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
8:57:00 -0400] conn=12387 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
8:57:00 -0400] conn=12385 op=1 RESULT err=14 tag=97 nentries=0
etime=0, SASL bind in progress
8:57:00 -0400] conn=12383 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
8:57:00 -0400] conn=10384 op=1228 EXT oid="2.16.840.1.113730.3.5.5"
name="Netscape Replication End Session"
8:57:00 -0400] conn=10384 op=1228 RESULT err=0 tag=120 nentries=0 etime=0
8:57:00 -0400] conn=12383 op=1 RESULT err=14 tag=97 nentries=0
etime=0, SASL bind in progress
9:02:00 -0400] conn=12388 fd=170 slot=170 connection from 172.20.0.1
to 172.20.2.45
9:02:00 -0400] conn=12389 fd=234 slot=234 SSL connection from
172.20.0.24 to 172.20.2.45
9:02:00 -0400] conn=12390 fd=236 slot=236 connection from local to
/var/run/slapd-EXAMPLE-COM.socket
9:02:00 -0400] conn=12391 fd=238 slot=238 connection from 172.20.0.1
to 172.20.2.45
9:02:00 -0400] conn=12392 fd=239 slot=239 SSL connection from
172.20.0.24 to 172.20.2.45
9:02:00 -0400] conn=12393 fd=240 slot=240 connection from local to
/var/run/slapd-EXAMPLE-COM.socket
9:02:00 -0400] conn=12394 fd=241 slot=241 connection from 172.20.0.1
to 172.20.2.45
9:02:00 -0400] conn=12395 fd=242 slot=242 SSL connection from
172.20.0.24 to 172.20.2.45
9:02:00 -0400] conn=12396 fd=243 slot=243 connection from 172.20.0.1
to 172.20.2.45
9:02:00 -0400] conn=12397 fd=244 slot=244 SSL connection from
172.

Re: [Freeipa-users] How to determine cause/source of user lockout?

[Rich Megginson]

On 05/17/2016 08:18 AM, Rob Crittenden wrote:

John Duino wrote:

Is there a (relatively easy) way to determine what is causing a user
account to be locked out? The admin account on our 'primary' ipa host is
locked out frequently, but somewhat randomly; sometimes it will be less
than 5 minutes it is available, and other times several hours.

ipa user-status admin will show something like:
Failed logins: 6
Last successful authentication: 20160516214142Z
Last failed authentication: 20160516224718Z
Time now: 2016-05-16T22:52:00Z

ipa user-unlock admin  does unlock it.

But parsing through the various logs on the affected host doesn't give
me what I need to know, primarily, which host(s) are trying to access
admin and causing it to lock.

FreeIPA 4.2.0 on CentOS 7.2.1511


I think you'd need to poke around in the KDC and 389-ds access log to 
find the auth attempts. I guess I'd look for PREAUTH_FAILED in 
/var/log/krb5kdc.log and look for err=49 in the 389-ds logs and then 
correlate the conn value with a BIND to see who was authenticating.


For 389 you can use the logconv.pl tool



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] oneWaySync affecting Password sync?

[Rich Megginson]

On 04/29/2016 09:44 AM, Rob Crittenden wrote:

Andreas Calminder wrote:

Hello,

I'm running ipa 4.2.0-15.el7 with winsync and wondering if setting
oneWaySync to fromWindows will affect password synchronization from IPA
to AD, I.E password changes from IPA will not be replicated to Windows?



Hmm, interesting question, I'm not sure. What is your goal here? Do 
you want to disallow attribute changes in IPA to be replicated but you 
DO want passwords, or you don't want anything?


ccing Rich to see what he thinks.


AFAIK, there is no way to sync only passwords from IPA to AD.  So if you 
set oneWaySync: fromWindows, you will not sync password changes from IPA 
to AD.




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] FREAK Vulnerability

[Rich Megginson]

On 01/26/2016 10:00 AM, Martin Basti wrote:



On 26.01.2016 17:39, Terry John wrote:

Thanks for this. I've had a look today
We are running:

ipa-server.x86_64 3.0.0-47.el6.centos

and some of the directives did not work, namely  allowWeakCipher, sslVersionMin 
 and sslVersionMax . So I commented them out
The ldapupdater then seems happy but when I went to restart IPA. The ldap 
server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not 
start.

Now I can't change anything and it doesn't work. Reaching for my backup.
IMO you can manually change dse.ldif, remove cipher from there and 
start DS

the file should be in /etc/dirsrv/slapd-/|instance_name|/


Make sure slapd is completely shutdown before you edit dse.ldif, or your 
changes will be wiped out.



Terry

-Original Message-
From: Christian Heimes [mailto:chei...@redhat.com]
Sent: 22 January 2016 10:03
To: Terry John; Martin Kosek;freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FREAK Vulnerability

On 2016-01-21 17:54, Terry John wrote:

Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
that ticket but none so far has eliminated the FREAK report.
Christian thanks for the heads up on the syntax, I wasn't sure of what
I was doing

Each time I've made a change I've run an sslscan from the OpenVAS scanner and I 
do get a different result each time but the errors still remains in OpenVAS.
Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.

Back to the drawing board :-)

Hi Terry,

you can give the attached file a try. It's a ldif file for ipa-ldap-updater. 
You need to run the command on the machine as root and restart 389-DS.

The hardened TLS configuration is highly experimental and comes with no 
warranty whatsoever. The configuration works on my tests systems with Python's 
ldap client and Apache Directory Studio. It may not work with other clients, 
especially older clients or clients in FIPS mode.

Christian



The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC









-- 
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.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

Replic
a)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationA
greement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: R
ead Replication Agreements";allow (compare,read,search) groupdn = "ldap:///cn
=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=myproddomain,dc
=net";)

# SNMP, config
dn: cn=SNMP,cn=config
aci: (target="ldap:///cn=SNMP,cn=config";)(targetattr !="aci")(version 3.0;acl
"snmp";allow (read, search, compare)(userdn = "ldap:///anyone";);)

# tasks, config
dn: cn=tasks,cn=config
aci: (targetattr=*)(version 3.0; acl "Run tasks after replica re-initializatio
n"; allow (add) groupdn = "ldap:///cn=Modify Replication Agreements,cn=permis
sions,cn=pbac,dc=myproddomain,dc=net";)
aci: (targetattr=*)(version 3.0; acl "cert manager: Run tasks after replica re
-initialization"; allow (add) userdn = "ldap:///uid=pkidbuser,ou= people,o=ip
aca";)
aci: (targetattr="*")(version 3.0; acl "Admin can read all tasks"; allow (read
, compare, search) groupdn = 
"ldap:///cn=admins,cn=groups,cn=accounts,dc=myproddomain,dc=net";;)
aci: (targetattr = "*")(target = "ldap:///cn=*,cn=automember rebuild membershi
p,cn=tasks,cn=config")(version 3.0;acl "permission:System: Read Automember Ta
sks";allow (compare,read,search) groupdn = "ldap:///cn=System: Read Automembe
r Tasks,cn=permissions,cn=pbac,dc=myproddomain,dc=net";)

# csusers, config
dn: ou=csusers,cn=config
aci: (targetattr != aci)(version 3.0; aci "cert manager manage replication use
rs"; allow (all) userdn = "ldap:///uid=pkidbuser,ou= people,o=ipaca";)

# 1.3.6.1.4.1.4203.1.9.1.1, features, config
dn: oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config
aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( rea
d, search ) userdn = "ldap:///all";;)

# 2.16.840.1.113730.3.4.9, features, config
dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config
aci: (targetattr !="aci")(version 3.0; acl "VLV Request Control"; allow (read,
   search, compare, proxy) userdn = "ldap:///anyone";; )

# dc\3Dmyproddomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dmyproddomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al
low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=
pbac,dc=myproddomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme
nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag
reements,cn=permissions,cn=pbac,dc=myproddomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob
jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "permission:Rem
ove Replication Agreements";allow (delete) groupdn = "ldap:///cn=Remove Repli
cation Agreements,cn=permissions,cn=pbac,dc=myproddomain,dc=net";)

# o\3Dipaca, mapping tree, config
dn: cn=o\3Dipaca,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "cert manager: Add Replication Agreements"
;allow (add) userdn = "ldap:///uid=pkidbuser,ou= people,o=ipaca";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre
ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou= peop
le,o=ipaca";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob
jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager:
Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser
,ou= people,o=ipaca";)

# ldbm database, plugins, config
dn: cn=ldbm database,cn=plugins,cn=config
aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a
llow (read) userdn="ldap:///uid=pkidbuser,ou= people,o=ipaca";)

# Posix IDs, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl
"permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA
Range,cn=permissions,cn=pbac,dc=myproddomain,dc=net";)
aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue  || dnaThre
shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

ttr=*)(version 3.0;acl "cert manager: Add Replication Agreements"
  ;allow (add) userdn = "ldap:///uid=pkidbuser,ou=people,o=ipaca";;)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
  s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
  ass=nsMappingTree))")(version 3.0; acl "cert manager: Modify Replication Agre
  ements"; allow (read, write, search) userdn = "ldap:///uid=pkidbuser,ou=peopl
  e,o=ipaca";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)(ob
  jectclass=nsDSWindowsReplicationAgreement))")(version 3.0;acl "cert manager:
  Remove Replication Agreements";allow (delete) userdn = "ldap:///uid=pkidbuser
  ,ou=people,o=ipaca";)

# ldbm database, plugins, config
dn: cn=ldbm database,cn=plugins,cn=config
aci: (targetattr=*)(version 3.0; acl "Cert Manager access for VLV searches"; a
  llow (read) userdn="ldap:///uid=pkidbuser,ou=people,o=ipaca";;)

# Posix IDs, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
aci: (targetattr=dnaNextRange || dnaNextValue || dnaMaxValue)(version 3.0;acl
  "permission:Modify DNA Range";allow (write) groupdn = "ldap:///cn=Modify DNA
  Range,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";)
aci: (targetattr=cn || dnaMaxValue || dnaNextRange || dnaNextValue  || dnaThre
  shold || dnaType || objectclass)(version 3.0;acl "permission:Read DNA Range";
  allow (read, search, compare) groupdn = "ldap:///cn=Read DNA Range,cn=permiss
  ions,cn=pbac,dc=dev-mydomain,dc=net";)

# userRoot, ldbm database, plugins, config
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
aci: (targetattr=nsslapd-readonly)(version 3.0; acl "Allow marking the databas
  e readonly"; allow (write) groupdn = "ldap:///cn=Remove Replication Agreement
  s,cn=permissions,cn=pbac,dc=dev-mydomain,dc=net";)

# search result
search: 2
result: 0 Success

# numResponses: 13
# numEntries: 12



-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: January-22-16 6:26 AM
To: Nathan Peters; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

On 01/21/2016 08:48 PM, Nathan Peters wrote:

Here are the results for that aci search using a non gssapi bind by directory 
manager on the old master that we are attempting to join agains.  I don't see 
anything in this list that would indicate that some users should or should not 
have access through a certain method.  Unless one of those sasl config settings 
is doing it ?

[root@dc2-ipa-dev-nvan ~]# ldapsearch -D "cn=directory manager" -W -b "cn=config" 
"(aci=*)"

You almost got it.  You left out the most important part, at the end of the command, 
specifying the "aci" attribute:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html

# ldapsearch -D "cn=directory manager" -W -b "cn=config" "(aci=*)" aci



--
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.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

:389/dc%3Ddev-mydomain%2Cdc%3Dnet
nsslapd-state: backend
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree

# o\3Dipaca, mapping tree, config
dn: cn=o\3Dipaca,cn=mapping tree,cn=config
cn: o=ipaca
nsslapd-backend: ipaca
nsslapd-referral: ldap://dc1-ipa-dev-nvan.dev-mydomain.net:389/o%3Dipaca
nsslapd-referral: ldap://dc1-ipa-dev-van.dev-mydomain.net:389/o%3Dipaca
nsslapd-state: Backend
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree

# ldbm database, plugins, config
dn: cn=ldbm database,cn=plugins,cn=config
cn: ldbm database
nsslapd-plugin-depends-on-type: Syntax
nsslapd-plugin-depends-on-type: matchingRule
nsslapd-pluginDescription: high-performance LDAP backend database plugin
nsslapd-pluginEnabled: on
nsslapd-pluginId: ldbm-backend
nsslapd-pluginInitfunc: ldbm_back_init
nsslapd-pluginPath: libback-ldbm
nsslapd-pluginType: database
nsslapd-pluginVendor: 389 Project
nsslapd-pluginVersion: 1.3.4.5
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject

# Posix IDs, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
cn: Posix IDs
dnaExcludeScope: cn=provisioning,dc=dev-mydomain,dc=net
dnaFilter: 
(|(objectClass=posixAccount)(objectClass=posixGroup)(objectClass=ipaIDobject))
dnaMagicRegen: -1
dnaMaxValue: 1100
dnaNextValue: 1101
dnaScope: dc=dev-mydomain,dc=net
dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=dev-mydomain,dc=net
dnaThreshold: 500
dnaType: uidNumber
dnaType: gidNumber
objectClass: top
objectClass: extensibleObject

# userRoot, ldbm database, plugins, config
dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: userRoot
objectClass: top
objectClass: extensibleObject
objectClass: nsBackendInstance
nsslapd-suffix: dc=dev-mydomain,dc=net
nsslapd-cachesize: -1
nsslapd-cachememsize: 10485760
nsslapd-readonly: off
nsslapd-require-index: off
nsslapd-directory: /var/lib/dirsrv/slapd-DEV-mydomain-NET/db/userRoot
nsslapd-dncachememsize: 10485760

# search result
search: 2
result: 0 Success

# numResponses: 13
# numEntries: 12


-Original Message-
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: January-21-16 7:29 AM
To: Nathan Peters; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

On 01/21/2016 12:50 AM, Nathan Peters wrote:

I don't know if this makes a difference too, but I performed the same checks on 
a different completely working and joined FreeIPA master, against other 
masters, and even against itself directly.

It seems that no account, no keytab, and no host can see that mapping tree 
branch no matter who they search from or against if GSSAPI is used.


-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters
Sent: January-20-16 11:41 PM
To: Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails
with DuplicateEntry: This entry already exists

All checks below were performed from the host we are trying to turn
into a replica and they were performed against the master who logs I
also show

The first check was to kinit admin and try the search.  Surprisingly, the 
GSSAPI bind returns no results when we search that.  In my previous email you 
can see that the standard bind gets a result as admin for that search.

Next, I tried as the host by kinit with its keytab.  Same result, nothing back.

Finally I tried as my own personal admin user.  Same result, nothing back.

For good measure, I tried a broad search against the base "cn=mydomain,cn=net" 
as each user as well and I'll spare you the ten thousand lines of screenshot but the 
results were as expected, several thousand entries in that tree.
Although the output differed slightly.  This is the total as admin or
my personal user # numResponses: 3372 # numEntries: 3371

and this is the total as the host keytab account

# numResponses: 3371
# numEntries: 3370

To be even more thorough, I did searches farther and farther up the config tree 
using GSSAPI until I found something.  The only thing that is visible through 
GSSAPI searches is the base of the config tree.  Even the mapping tree branch 
doesn't seem to be visible.

At the very bottom of this email is the results of the search against cn=config 
directly as the attempted new replica and as admin.  Admin gets about 50 
results and the host only gets about 30 for some reason.  I get the same 
results as admin on my personal account so I've excluded those.

So if I got all that right I was able to determine that only the base of the 
config tree is available using GSSAPI for any account, users for some reason 
get slightly more results than hosts, and all accounts can see the 
dc=mydomain,dc=net tree just fine using GSSAPI.

So does that help shed some light on what the cause of this

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

On 01/21/2016 12:50 AM, Nathan Peters wrote:

I don't know if this makes a difference too, but I performed the same checks on 
a different completely working and joined FreeIPA master, against other 
masters, and even against itself directly.

It seems that no account, no keytab, and no host can see that mapping tree 
branch no matter who they search from or against if GSSAPI is used.


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters
Sent: January-20-16 11:41 PM
To: Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

All checks below were performed from the host we are trying to turn into a 
replica and they were performed against the master who logs I also show

The first check was to kinit admin and try the search.  Surprisingly, the 
GSSAPI bind returns no results when we search that.  In my previous email you 
can see that the standard bind gets a result as admin for that search.

Next, I tried as the host by kinit with its keytab.  Same result, nothing back.

Finally I tried as my own personal admin user.  Same result, nothing back.

For good measure, I tried a broad search against the base "cn=mydomain,cn=net" 
as each user as well and I'll spare you the ten thousand lines of screenshot but the 
results were as expected, several thousand entries in that tree.
Although the output differed slightly.  This is the total as admin or my 
personal user # numResponses: 3372 # numEntries: 3371

and this is the total as the host keytab account

# numResponses: 3371
# numEntries: 3370

To be even more thorough, I did searches farther and farther up the config tree 
using GSSAPI until I found something.  The only thing that is visible through 
GSSAPI searches is the base of the config tree.  Even the mapping tree branch 
doesn't seem to be visible.

At the very bottom of this email is the results of the search against cn=config 
directly as the attempted new replica and as admin.  Admin gets about 50 
results and the host only gets about 30 for some reason.  I get the same 
results as admin on my personal account so I've excluded those.

So if I got all that right I was able to determine that only the base of the 
config tree is available using GSSAPI for any account, users for some reason 
get slightly more results than hosts, and all accounts can see the 
dc=mydomain,dc=net tree just fine using GSSAPI.

So does that help shed some light on what the cause of this might be or why the 
server is not answering as expected?

Is there some way I can adjust this so everyone can see the results they do 
using regular binds as they do using GSSAPI binds ?

Is there some way I can check ACLS on stuff ?


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Access_Control-Viewing_the_ACIs_for_an_Entry.html

Note: There is a bug in the docs.  You have to also specify the suffix 
e.g. "-b cn=config", and make sure the search filter is quoted e.g. 
'(aci=*)'


If it is not aci related, I have no idea why you would get different 
results depending on if you did a simple bind vs. a gssapi bind with the 
same user that mapped to the same bind DN.




===
search as admin
===
[nathan.peters@dc2-ipa-dev-van ~]$ klist Ticket cache: 
KEYRING:persistent:756600344:756600344
Default principal: ad...@mydomain.net

Valid starting ExpiresService principal
20/01/16 22:53:18  21/01/16 22:53:08  krbtgt/mydomain@mydomain.net 
[nathan.peters@dc2-ipa-dev-van ~]$ ldapsearch -Y GSSAPI -H 
ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config"
SASL/GSSAPI authentication started
SASL username: ad...@mydomain.net
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base  with 
scope subtree # filter: (objectclass=*) # requesting: ALL #

# search result
search: 4
result: 0 Success

# numResponses: 1


check host keytab


[root@dc2-ipa-dev-van ipa]# klist -kt /etc/krb5.keytab Keytab name: 
FILE:/etc/krb5.keytab
KVNO Timestamp Principal
 - 
5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net
5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net
5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net
5 19/01/16 12:07:12 host/dc2-ipa-dev-van.mydomain@mydomain.net


kinit host keytab


[root@dc2-ipa-dev-van ipa]# kinit -t /etc/krb5.keytab keytab specified, forcing -k [root@dc2-ipa-dev-van ipa]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_uwO1f2L

Default principal: host/dc2-ipa-dev-van.mydomain@mydomain.net

Valid starting E

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Rich Megginson]

On 01/20/2016 12:24 PM, Nathan Peters wrote:

Now we are starting to get somewhere (although a resolution still is not 
visible) :)

First, thank you Petr and Rob for your help on this issue.  I apologize for our 
hard to parse server names.  I'm not a fan of them myself and in earlier 
reports I had been reformatting everything nicely with dc1, dc2, dc3 etc.  
After having to submit so many reports I started to get lazy an thought it may 
be more helpful to see data closer to what we are actually using.

Petr hit the nail on the head with the "does everyone who binds get the same 
result" question, which although it has not revealed a resolution, has revealed a 
bunch of really interesting facts about the process.

Going back to the original logs that were running on the remote master during 
the replica installation attempt I see the following :

[18/Jan/2016:09:28:32 -0800] conn=18732 fd=77 slot=77 connection from 
10.21.0.98 to 10.178.0.98

[18/Jan/2016:09:28:32 -0800] conn=18732 op=0 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=0 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[18/Jan/2016:09:28:32 -0800] conn=18732 op=1 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[18/Jan/2016:09:28:32 -0800] conn=18732 op=2 BIND dn="" method=sasl version=3 
mech=GSSAPI
[18/Jan/2016:09:28:32 -0800] conn=18732 op=2 RESULT err=0 tag=97 nentries=0 etime=0 
dn="fqdn=dc2-ipa-dev-van.mydomain.net,cn=computers,cn=accounts,dc=mydomain,dc=net"
[18/Jan/2016:09:28:32 -0800] conn=18732 op=3 SRCH 
base="cn=replication,cn=etc,dc=mydomain,dc=net" scope=0 
filter="(objectClass=*)" attrs=ALL
[18/Jan/2016:09:28:32 -0800] conn=18732 op=3 RESULT err=0 tag=101 nentries=1 
etime=0
[18/Jan/2016:09:28:32 -0800] conn=18732 op=4 SRCH base="cn=schema" scope=0 
filter="(objectClass=*)" attrs="attributeTypes objectClasses"
[18/Jan/2016:09:28:32 -0800] conn=18732 op=4 RESULT err=0 tag=101 nentries=1 
etime=0

So, conn18732 was opened with a bind dn of "" ?  Is this supposed to happen?


Yes.  GSSAPI/SASL binds are multi-stage binds.  You'll notice that the 
last stage is op=2, and the result has the full bind DN to which the 
kerberos principals mapped to.  The dn="" until the last stage at which 
time the mapped DN is known and logged.




Here is what I see when I search that base using the same empty bind dn :


nack - you have to first use "kinit myusername@MYDOMAIN", then use 
ldapsearch -Y GSSAPI , to do the bind in the same way to use GSSAPI.




---snip---
[root@dc2-ipa-dev-van ~]# ldapsearch -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D ""
# extended LDIF
#
# LDAPv3
# base  with 
scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
---snip---

Here is a similar empty looking result when I bind as the admin user

---snip---
[root@dc2-ipa-dev-van ~]# ldapsearch -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D 
"uid=admin,cn=users,cn=accounts,dc=mydomain,dc=net" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with 
scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
---snip---

So we know that for whatever reason, this particular DN cannot be searched from 
anyone other than directory manager.

So I now have a few new questions...

1. What user is the ipa-replica-install command supposed to bind as ?  directory manager, 
admin, or "" ?

2/3. Should the ACL on that replica DN allow "" to get results?  Isn't that 
essentially an anonymous bind ? What should the ACL be ?

For reference, here is the result when I search from the new replica against 
the existing master using directory manager (I get a good result):

[root@dc2-ipa-dev-van ~]# ldapsearch -H ldaps://dc2-ipa-dev-nvan.mydomain.net -b 
"cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config" -D "cn=directory 
manager" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with 
scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# replica, dc\3Dmydomain\2Cdc\3Dnet, mapping tree, config
dn: cn=replica,cn=dc\3Dmydomain\2Cdc\3Dnet,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN: krbprincipalname=ldap/dc1-ipa-dev-nvan.mydomain.net
  @mydomain.NET,cn=services,cn=accounts,dc=mydomain,dc=net
nsDS5ReplicaBindDN: krbprincipalname=ldap/dc1-ipa-dev-van.mydomain.net@
  mydomain.NET,cn=services,cn=accounts,dc=mydomain,dc=net
nsDS5ReplicaId: 15
nsDS5ReplicaName: 74d8b993-bcb911e5-ba5283c7-2a40cd64
nsDS5ReplicaRoot: dc=mydomain,dc=net
nsDS5ReplicaType: 3
nsState:: DwCJ2p9WbAEFAA==
nsds5ReplicaLegacyConsumer

Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

[Rich Megginson]

On 12/04/2015 07:37 AM, Andy Thompson wrote:



-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Rich Megginson
Sent: Thursday, December 3, 2015 4:44 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

On 12/03/2015 08:33 AM, Andy Thompson wrote:





-Original Message-
From: freeipa-users-boun...@redhat.com <mailto:freeipa-
users-boun...@redhat.com>  [mailto:freeipa-users-
boun...@redhat.com <mailto:boun...@redhat.com> ] On
Behalf Of Petr Spacek
Sent: Thursday, December 3, 2015 3:04 AM
To: freeipa-users@redhat.com <mailto:freeipa-
us...@redhat.com>
Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd
hanging system

On 2.12.2015 22:02, Alexander Bokovoy wrote:

On Wed, 02 Dec 2015, Andy Thompson wrote:

Since updating to RHEL 7.2 I've got issues with
ns-slapd hanging the
system up after a period of time.  The
directory becomes unresponsive
to searches or any connections.  After a
restart I see

[02/Dec/2015:15:27:41 -0500] - slapd started.
Listening on All
Interfaces port 389 for LDAP requests
[02/Dec/2015:15:27:41 -0500] - Listening on
All Interfaces port 636
for LDAPS requests
[02/Dec/2015:15:27:41 -0500] - Listening on
/var/run/slapd-MHBENP-LIN.socket for
LDAPI requests
[02/Dec/2015:15:27:44 -0500]
NSMMReplicationPlugin -
agmt="cn=meTomdhixnpipa02.mhbenp.lin"
(mdhixnpipa02:389):

Replication

bind with GSSAPI auth resumed
[02/Dec/2015:15:27:47 -0500]
NSMMReplicationPlugin - replication keep
alive entry  already exists

In the logs and occasionally the keepalive
entry message is seen a
few times and then eventually the ns-slapd
taps the system.  100%
util, system load crawls up between 30 and 40
and eventually I have
to restart the service to get it to respond
again.  Memory usage is
normal, db and entry cache is sufficient..
possibly a little on the
high side but resource is sitting there asking
to be used :)

Running 389-ds-base-1.3.4.0-19.el7.x86_64
after the update yesterday.

What additional information can I provide?

install debuginfo for 389-ds-base and slapi-nis, and
take a pstack
output for ns-slapd pid.


For detailed instructions please see

http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug
_hangs



Here is the resulting stacktrace during the last hang.


The server is idle at this point.  None of the threads are doing any work, or
are blocked/deadlocked.  It does not appear hung at all.

When the server is in the "hung" state again, use ldapsearch (e.g. -s base -b
"") to "ping" the server to see if it is entirely unresponsive.




No ldapsearch does not respond, it just hangs and doesn't ever return.


Try doing an strace of ldapsearch to see in what system call it is stuck 
in (or you can just do an strace/pstack on the running, hung ldapsearch 
process).




-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] RHEL 7.2 update - ns-slapd hanging system

[Rich Megginson]

On 12/03/2015 08:33 AM, Andy Thompson wrote:



-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Petr Spacek
Sent: Thursday, December 3, 2015 3:04 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] RHEL 7.2 update - ns-slapd hanging system

On 2.12.2015 22:02, Alexander Bokovoy wrote:

On Wed, 02 Dec 2015, Andy Thompson wrote:

Since updating to RHEL 7.2 I've got issues with ns-slapd hanging the
system up after a period of time.  The directory becomes unresponsive
to searches or any connections.  After a restart I see

[02/Dec/2015:15:27:41 -0500] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[02/Dec/2015:15:27:41 -0500] - Listening on All Interfaces port 636
for LDAPS requests
[02/Dec/2015:15:27:41 -0500] - Listening on
/var/run/slapd-MHBENP-LIN.socket for LDAPI requests
[02/Dec/2015:15:27:44 -0500] NSMMReplicationPlugin -
agmt="cn=meTomdhixnpipa02.mhbenp.lin" (mdhixnpipa02:389):

Replication

bind with GSSAPI auth resumed
[02/Dec/2015:15:27:47 -0500] NSMMReplicationPlugin - replication keep
alive entry  already exists

In the logs and occasionally the keepalive entry message is seen a
few times and then eventually the ns-slapd taps the system.  100%
util, system load crawls up between 30 and 40 and eventually I have
to restart the service to get it to respond again.  Memory usage is
normal, db and entry cache is sufficient.. possibly a little on the
high side but resource is sitting there asking to be used :)

Running 389-ds-base-1.3.4.0-19.el7.x86_64 after the update yesterday.

What additional information can I provide?

install debuginfo for 389-ds-base and slapi-nis, and take a pstack
output for ns-slapd pid.

For detailed instructions please see
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_hangs


Here is the resulting stacktrace during the last hang.


The server is idle at this point.  None of the threads are doing any 
work, or are blocked/deadlocked.  It does not appear hung at all.


When the server is in the "hung" state again, use ldapsearch (e.g. -s 
base -b "") to "ping" the server to see if it is entirely unresponsive.



-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] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 10:50 AM, Gronde, Christopher (Contractor) wrote:

Is it possible to delete the mapping and try it and if it doesn't work or 
breaks something else add it back?  How would I go about deleting this mapping? 
 Or adding the mapping for principal name in the right order?


http://www.port389.org/docs/389ds/design/sasl-mapping-improvements-1-dot-3-1.html

However, looking at your version: 
https://www.redhat.com/archives/freeipa-users/2015-November/msg00124.html


You are using EL6 389-ds-base 1.2.11.x, which does not support the above 
sasl mapping improvements.


I have no idea how IPA is supposed to handle this situation with 
389-ds-base 1.2.11.




-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson
Sent: Tuesday, November 10, 2015 12:26 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:

On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)

Looks like this mapping rule causes the issues with incorrectly
mapped service principals.

Any idea what I need to do to fix it?

I don't know where this mapping comes from and if it is needed, so one
try would be to delete it.
Another attempt would be to change the order of the mappings, but this
would mean to rename them

In the older code, the SASL mappings were applied in reverse alphabetical 
order, which is why cn=uid mapping,cn=mapping,cn=sasl,cn=config is being 
applied first.  I thought there had been changes to this, so that you could 
explicitly define the order in which the mappings were applied.


-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ;
Rob Crittenden ; Ludwig Krispenz
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree # filter:
(objectclass=*) # requesting: ALL #

# mapping, sasl, config
dn: cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: mapping

# Full Principal, mapping, sasl, config
dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: \(.*\)@\(.*\)
cn: Full Principal
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2)

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)

Looks like this mapping rule causes the issues with incorrectly
mapped service principals.


# Name Only, mapping, sasl, config
dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: ^[^:@]+$
cn: Name Only
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV)

# rfc 2829 dn syntax, mapping, sasl, config
dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: rfc 2829 dn syntax
nsSaslMapRegexString: ^dn:\(.*\)
nsSaslMapBaseDNTemplate: \1
nsSaslMapFilterTemplate: (objectclass=*)

# rfc 2829 u syntax, mapping, sasl, config
dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: rfc 2829 u syntax
nsSaslMapRegexString: ^u:\(.*\)
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (uid=\1)

# uid mapping, mapping, sasl, config
dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: uid mapping
nsSaslMapRegexString: ^[^:@]+$
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (uid=&)

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7
[root@comipa02 ~]#

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, November 10, 2015 11:52 AM
To: Gronde, Christopher (Contractor)
; Ludwig Krispenz
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:

This gave me a huge return!  Appears to be a long list of all the
servers and applications whose users authenticate to the IPA servers.

ldapse

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 10:25 AM, Ludwig Krispenz wrote:


On 11/10/2015 06:08 PM, Gronde, Christopher (Contractor) wrote:

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)
Looks like this mapping rule causes the issues with incorrectly 
mapped service principals.

Any idea what I need to do to fix it?
I don't know where this mapping comes from and if it is needed, so one 
try would be to delete it.
Another attempt would be to change the order of the mappings, but this 
would mean to rename them


In the older code, the SASL mappings were applied in reverse 
alphabetical order, which is why cn=uid 
mapping,cn=mapping,cn=sasl,cn=config is being applied first.  I thought 
there had been changes to this, so that you could explicitly define the 
order in which the mappings were applied.




-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 12:03 PM
To: Gronde, Christopher (Contractor) ; 
Rob Crittenden ; Ludwig Krispenz 
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
authentication error)


On 11/10/2015 05:54 PM, Gronde, Christopher (Contractor) wrote:

# ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree # filter:
(objectclass=*) # requesting: ALL #

# mapping, sasl, config
dn: cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: mapping

# Full Principal, mapping, sasl, config
dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: \(.*\)@\(.*\)
cn: Full Principal
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2)

# Kerberos uid mapping, mapping, sasl, config
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapBaseDNTemplate: dc=\2,dc=\3
nsSaslMapFilterTemplate: (uid=\1)
Looks like this mapping rule causes the issues with incorrectly 
mapped service principals.



# Name Only, mapping, sasl, config
dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
nsSaslMapRegexString: ^[^:@]+$
cn: Name Only
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (krbPrincipalName=&@ITMODEV.GOV)

# rfc 2829 dn syntax, mapping, sasl, config
dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: rfc 2829 dn syntax
nsSaslMapRegexString: ^dn:\(.*\)
nsSaslMapBaseDNTemplate: \1
nsSaslMapFilterTemplate: (objectclass=*)

# rfc 2829 u syntax, mapping, sasl, config
dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: rfc 2829 u syntax
nsSaslMapRegexString: ^u:\(.*\)
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (uid=\1)

# uid mapping, mapping, sasl, config
dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: uid mapping
nsSaslMapRegexString: ^[^:@]+$
nsSaslMapBaseDNTemplate: dc=itmodev,dc=gov
nsSaslMapFilterTemplate: (uid=&)

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7
[root@comipa02 ~]#

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, November 10, 2015 11:52 AM
To: Gronde, Christopher (Contractor) ;
Ludwig Krispenz ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

Gronde, Christopher (Contractor) wrote:
This gave me a huge return!  Appears to be a long list of all the 
servers and applications whose users authenticate to the IPA servers.


ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(objectclass=krbprincipal)'



# search result
search: 2
result: 0 Success

# numResponses: 142
# numEntries: 141

Right, we need to see the sasl mapping:

$ ldapsearch -x -D 'cn=Directory Manager' -W -b
cn=mapping,cn=sasl,cn=config

rob


-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig
Krispenz
Sent: Tuesday, November 10, 2015 11:37 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

what do you get if you search for "objectclass=krbprincipal" ?

On 11/10/2015 05:27 PM, Rich Megginson wrote:

On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b
"d

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 09:49 AM, Gronde, Christopher (Contractor) wrote:

Note comipa01 is the master and comipa02 is the replica that is having the KDC 
issue

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa01.itmodev.gov*)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (krbprincipalname=ldap/comipa01.itmodev.gov*)
# requesting: ALL
#

# ldap/comipa01.itmodev@itmodev.gov, services, accounts, itmodev.gov
dn: krbprincipalname=ldap/comipa01.itmodev@itmodev.gov,cn=services,cn=acco
  unts,dc=itmodev,dc=gov
krbLastSuccessfulAuth: 20151015230212Z
ipaKrbPrincipalAlias: ldap/comipa01.itmodev@itmodev.gov
krbExtraData:: AAL6CaBOYWRtaW4vYWRtaW5ASVRNT0RFVi5HT1YA
krbExtraData:: AAgBAA==
userCertificate:: X
XX
XREDACTEDX
XX
X
krbPasswordExpiration: 1970010100Z
ipaUniqueID: 15a897e8-fb11-11e0-b8e5-001a4a106404
krbLastPwdChange: 20111020114602Z
krbPrincipalName: ldap/comipa01.itmodev@itmodev.gov
krbLoginFailedCount: 0
managedBy: fqdn=comipa01.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go
  v
objectClass: ipaobject
objectClass: top
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipal
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
objectClass: ipakrbprincipal
krbPrincipalKey:: X
X
XXX
REDACTED

X
XXX

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@comipa02 ~]#

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(krbprincipalname=ldap/comipa02.itmodev.gov*)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (krbprincipalname=ldap/comipa02.itmodev.gov*)
# requesting: ALL
#

# ldap/comipa02.itmodev@itmodev.gov, services, accounts, itmodev.gov
dn: krbprincipalname=ldap/comipa02.itmodev@itmodev.gov,cn=services,cn=acco
  unts,dc=itmodev,dc=gov
krbLastSuccessfulAuth: 20150921160115Z
ipaKrbPrincipalAlias: ldap/comipa02.itmodev@itmodev.gov
userCertificate:: XXX

REDACTED

X
krbExtraData:: AAgBAA==
krbLastPwdChange: 20111020180803Z
krbPasswordExpiration: 1970010100Z
krbPrincipalKey:: XX
XX
XXREDACTEDXX


XX
krbLoginFailedCount: 0
objectClass: ipaobject
objectClass: top
objectClass: ipaservice
objectClass: pkiuser
objectClass: krbprincipal
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
objectClass: ipakrbprincipal
managedBy: fqdn=comipa02.itmodev.gov,cn=computers,cn=accounts,dc=itmodev,dc=go
  v
krbPrincipalName: ldap/comipa02.itmodev@itmodev.gov
ipaUniqueID: 739e600a-fb46-11e0-a4b9-5254004d91a8

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@comipa02 ~]#


Ok.  This sure looks like a SASL mapping issue - the map should be using 
krbPrincipalName instead of uid.





-Original Message-
From: Martin Babinsky [mailto:mbabi...@redhat.com]
Sent: Tuesday, November 10, 2015 11:39 AM
To: Gronde, Christopher (Contractor) ; Rich Megginson 
; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree # filter:
(uid=ldap/comipa01.itmodev.gov) # requesting: ALL #

# search result
search: 2
result: 0 Success

# numResponses: 1
[root@comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory
manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope su

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 09:39 AM, Martin Babinsky wrote:

On 11/10/2015 05:16 PM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'

Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=ldap/comipa01.itmodev.gov)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
[root@comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory 
manager" -W -b "dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid

Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=ldap/*.gov)
# requesting: uid
#

# search result
search: 2
result: 0 Success

# numResponses: 1

I think that you should search for 'krbprincipalname' attribute when 
you want to find out whether you have the proper Kerberos principal 
present, like so:


ldapsearch -Y GSSAPI -b 'dc=ipa,dc=test' 
'(krbprincipalname=ldap/master1.ipa.test*)'


That means there is a bug in the SASL mappings - why is the SASL mapping 
searching for uid=ldap/... instead of krbprincipalname=ldap/... 





-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson

Sent: Tuesday, November 10, 2015 11:04 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos 
authentication error)


On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote:

Thank you!  I should have caught that...

I changed the log level and then restarted dirsrv and attempted to 
start krb5kdc and got the following...



[10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from
172.16.100.208 to 172.16.100.161
[10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 
nentries=0 etime=1, SASL bind in progress

[10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 
nentries=0 etime=0, SASL bind in progress

[10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH 
base="dc=itmodev,dc=gov" scope=2 
filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL

[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48
nentries=0 etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0
etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1



This is the SASL bind.  It thinks the principal in the Kerberos 
credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the 
code to look for something with uid=ldap/comipa01.itmodev.gov under 
dc=itmodev,dc=gov.  However, this entry is not found: RESULT err=0
tag=48 nentries=0.  nentries=0 means no entries matched the search 
criteria.


You can do the search yourself with ldapsearch:

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'


If you want to find out if there is some other ldap principal, do a 
search like this:


ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid



Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
   additional info: Unknown attribute nsslapd-acesslog-level
will be ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP
Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:
How do I change that log setting? Is that done in LDAP?  Using 
ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig
Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gron

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 09:16 AM, Gronde, Christopher (Contractor) wrote:

Neither came back with anything

# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=ldap/comipa01.itmodev.gov)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
[root@comipa02 ~]# ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (uid=ldap/*.gov)
# requesting: uid
#

# search result
search: 2
result: 0 Success

# numResponses: 1


That means this server has no LDAP service principals?  I'm not sure how 
to recover IPA from this scenario.




-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rich Megginson
Sent: Tuesday, November 10, 2015 11:04 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos authentication 
error)

On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote:

Thank you!  I should have caught that...

I changed the log level and then restarted dirsrv and attempted to start 
krb5kdc and got the following...



[10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from
172.16.100.208 to 172.16.100.161
[10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 
etime=1, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH base="dc=itmodev,dc=gov" scope=2 
filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48
nentries=0 etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0
etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1



This is the SASL bind.  It thinks the principal in the Kerberos credential is 
"ldap/comipa01.itmodev.gov", and the SASL map tells the code to look for 
something with uid=ldap/comipa01.itmodev.gov under dc=itmodev,dc=gov.  However, this 
entry is not found: RESULT err=0
tag=48 nentries=0.  nentries=0 means no entries matched the search criteria.

You can do the search yourself with ldapsearch:

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'

If you want to find out if there is some other ldap principal, do a search like 
this:

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid


Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
   additional info: Unknown attribute nsslapd-acesslog-level
will be ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP
Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig
Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?
Is it my LDAP password?

No, according to your logs, it is your LDAP master trying to
replicate (push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn=""

Re: [Freeipa-users] krb5kdc will not start (kerberos authentication error)

[Rich Megginson]

On 11/10/2015 08:18 AM, Gronde, Christopher (Contractor) wrote:

Thank you!  I should have caught that...

I changed the log level and then restarted dirsrv and attempted to start 
krb5kdc and got the following...



[10/Nov/2015:10:12:02 -0500] conn=5 fd=64 slot=64 connection from 
172.16.100.208 to 172.16.100.161
[10/Nov/2015:10:12:02 -0500] conn=5 op=0 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=0 RESULT err=14 tag=97 nentries=0 
etime=1, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=5 op=1 RESULT err=14 tag=97 nentries=0 
etime=0, SASL bind in progress
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 BIND dn="" method=sasl 
version=3 mech=GSSAPI
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 SRCH 
base="dc=itmodev,dc=gov" scope=2 
filter="(uid=ldap/comipa01.itmodev.gov)" attrs=ALL
[10/Nov/2015:10:12:03 -0500] conn=Internal op=-1 RESULT err=0 tag=48 
nentries=0 etime=0
[10/Nov/2015:10:12:03 -0500] conn=5 op=2 RESULT err=49 tag=97 nentries=0 
etime=0

[10/Nov/2015:10:12:03 -0500] conn=5 op=3 UNBIND
[10/Nov/2015:10:12:03 -0500] conn=5 op=3 fd=64 closed - U1



This is the SASL bind.  It thinks the principal in the Kerberos 
credential is "ldap/comipa01.itmodev.gov", and the SASL map tells the 
code to look for something with uid=ldap/comipa01.itmodev.gov under 
dc=itmodev,dc=gov.  However, this entry is not found: RESULT err=0 
tag=48 nentries=0.  nentries=0 means no entries matched the search criteria.


You can do the search yourself with ldapsearch:

ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/comipa01.itmodev.gov)'


If you want to find out if there is some other ldap principal, do a 
search like this:


ldapsearch -x -h 172.16.100.161 -D "cn=directory manager" -W -b 
"dc=itmodev,dc=gov" '(uid=ldap/*.gov)' uid



Ran into an error trying to set that

# ldapmodify -a -D "cn=directory manager" -W Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
: 260

modifying entry "cn=config"
ldap_modify: Server is unwilling to perform (53)
  additional info: Unknown attribute nsslapd-acesslog-level
will be ignored

[root@comipa02 ~]# ldapmodify -a -D "cn=config" -W Enter LDAP
Password:
ldap_bind: Inappropriate authentication (48)

-Original Message-
From: Ludwig Krispenz [mailto:lkris...@redhat.com]
Sent: Tuesday, November 10, 2015 9:48 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 03:32 PM, Gronde, Christopher (Contractor) wrote:

How do I change that log setting?  Is that done in LDAP?  Using ldapmodify?

yes,
ldapmodify ...
dn: cn=config
changetype: modify
replace: nsslapd-acesslog-level
nsslapd-acesslog-level: 260

-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ludwig
Krispenz
Sent: Tuesday, November 10, 2015 9:03 AM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)


On 11/10/2015 02:40 PM, Alexander Bokovoy wrote:

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

Where can I verify or change the credentials it is trying to use?
Is it my LDAP password?

No, according to your logs, it is your LDAP master trying to
replicate (push changes) to your LDAP replica:

[09/Nov/2015:15:02:01 -0500] conn=2 fd=64 slot=64 connection from
 to 
[09/Nov/2015:15:02:01 -0500] conn=2 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI

err=49 could also be a result if the entry which is mapped from the principal 
is not found in the directory. A bit more info could be gained by enabling 
logging of internal searches.
Set nsslapd-acesslog-level: 260

and then look what internal searches are done during the gssapi
authentication

If that is true, it would be ldap/ Kerberos principal
talking to ldap/ Kerberos principal. If that fails, it
means master and replica KDCs have different understanding of both
ldap/ and ldap/ keys which most likely means keys
were rotated on master and weren't propagated to replica.

How to solve it? One possibility is to set master's hostname as KDC
address in krb5.conf on replica, forcing LDAP server on replica to
use master's KDC. I'm absolutely not sure this will actually work
but at least it allows to see if we are indeed dealing with
inconsistent state of service principals' keys.


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, November 10, 2015 8:18 AM
To: Gronde, Christopher (Contractor)

Cc: Rob Crittenden ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] krb5kdc will not start (kerberos
authentication error)

On Tue, 10 Nov 2015, Gronde, Christopher (Contractor) wrote:

When I tried to start the service again I got no response from
tail of th

Re: [Freeipa-users] Sync with SUN DS 5.2

[Rich Megginson]

On 11/10/2015 08:39 AM, Rob Crittenden wrote:

Seike neg wrote:

Hello,
Is there a way to import users and password from SUN DS automatically (script, 
sync, etc...).
I have a SUN DS LDAP in the office and I want to do a read only sync from him 
to a brand new freeipa server.
The freeipa server is suppose to act as a kerberos, ldap slave and ntp server.



It's a little unclear what you want to do. Do you want a periodic sync
or a one-time migration?

You can use ipa migrate-ds to migrate over LDAP. See
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Migrating_from_a_Directory_Server_to_IPA.html


You can also configure SunDS 5.2 to replicate to IPA, and vice versa.



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 user-add slows down as more users are added

[Rich Megginson]

On 11/04/2015 04:07 PM, Rob Crittenden wrote:

Daryl Fonseca-Holt wrote:

Hi All,

I am testing migration from NIS with a custom MySQL backend to IPA. In
our testing ipa user-add starts out at around 12 seconds per user but
slows down as more users are add. By 5000+ users it is taking 90+
seconds. We have 120,000+ users. I'm looking at 155 days to load all the
users :(

Per some performance tuning documentation I've increased
nsslapd-cachememsize to 35,651,584 and am currently getting pretty high
hit ratios (see below).


Use dbmon.sh instead of db_stat - it will give you the entry cache 
information as well as a summary of the db cache information (instead of 
the quite verbose db_stat output).



However, one thread of ns-slapd pegs out core at
100% and I can't get get it to add users any faster. I'm not seeing any
I/O or memory swapping.

The problem is most likely the default IPA users group. As it gets
humongous adding new members slows it down.


So could he disable the automember and memberof plugins?  Then have 
those work offline, after the users are added?





Suggestions would be appreciated. Multi-master will probably help but
with that many accounts it would take a lot of masters to get additions
done to a resonable (45 seconds or less?) time. Is there any guideline
for number of users per master?

IPA is multi-master. All users are on all masters.

If anything I'd expect that running imports on different masters would
slow things down as changes on multiple masters would need to get merged
together, particularly the default group.


Right.



Certainly bumping up the caches to match what the final expected sizes
is probably a good idea but I don't see it influencing import speed all
that much.


Right.



One idea I've had is to add the users in batches of 1000. What you'd do
is create 120 non-POSIX user groups, ipausers1..ipausers120, and add
them as members of ipausers.

Then for each batch change the default ipausers group with:

  $ ipa config-mod --defaultgroup=

This should keep the user-add command fairly peppy and keep the ipausers
group somewhat in check via the nesting.

I imagine that the UI would blow up if you tried to view the ipausers
group as it tried to dereference 120k users.

You'll probably also want to disable the compat module for the import.

I assume you've already done some amount of testing with a smaller batch
of users to ensure they migrate ok, passwords work, etc?

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] nsslapd-dbcachesize and database size

[Rich Megginson]

On 10/14/2015 08:35 AM, Andrew E. Bruno wrote:

On Wed, Oct 14, 2015 at 07:59:23AM -0600, Rich Megginson wrote:

On 10/14/2015 07:09 AM, Andrew E. Bruno wrote:

The load average on our freeipa replicas started to spike over the
last few days and we narrowed it down to a dbcache issue. Following the
guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh

We saw that the dbcachefree was 2.0% which indicates a lot of page
churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of
our database and index files was 3.1G:

$ du -sh /var/lib/dirsrv/slapd-[domain]/db/
3.1G

Once we increased nsslapd-dbcachesize to 6G load average went back to
normal and query response times improved. Interestingly, when we
restarted the dirsrv process the database size went down to 1.7G

$ du -sh /var/lib/dirsrv/slapd-[domain]/db/
1.7G

When we initially deployed freeipa, the size of our database and indexes
was about 400M which is why we set nsslapd-dbcachesize to 2G.

What about your cachememsize?

We have nsslapd-cachememsize set at 2G for the cn=userRoot. According to
dbmon.sh it looked OK and we didn't think it needed to be increased:

dbcachefree 6123847680 free% 95.055 roevicts 0 hit% 99 pagein 34260 pageout 
308661

dbname  count  free  free%size
changelog:ent 84158342   30.9  4210.2
changelog:dn   29716580.074.0
  userroot:ent   84462091021433   97.4  6685.1
  userroot:dn8446 523272268   99.8   120.3
 ipaca:ent100673516   47.9  7338.6
 ipaca:dn 100   1399359   99.480.1


Yes, looks good.




The changelog:dn seems to vary so much not sure how to tune that one. Any
suggestions? It's almost always 0% free.


I wouldn't worry about it, for now.




A few questions:

1. What causes the increase in size of
/var/lib/dirsrv/slapd-[domain]/db/*  and should we periodically clean up?

Replication metadata accounts for some of this.  Fragmentation accounts for
some of this.  You can periodically clean up, but you shouldn't have to.
The growth should eventually hit a plateau.


2. How do you tune nsslapd-dbcachesize to account for this growth? The
dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem
to grow much larger?

12% is sort of a starting point.  There isn't a good way to tell how to
account for replication metadata, fragmentation, etc.  Just monitor
periodically and adjust as needed.

Great, Thanks Rich!


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

Re: [Freeipa-users] How to install freeIPA client to many VMs?

[Rich Megginson]

On 10/14/2015 09:58 AM, zhiyong xue wrote:
Yes, that's my problem. These VMs were created by openstack and 
generated host name without domain at all.  Anyway can let the new 
created VM can join domain automatically?


I am working on such a feature: 
https://github.com/richm/rdo-vm-factory/tree/master/rdo-ipa-nova


This is not a product yet, just a PoC.

This allows you to:
* automatically register VMs created by Nova with IPA
* automatically assign DNS A records in IPA when you assign a floating 
IP address to a VM




Thanks Martin.

2015-10-14 22:40 GMT+08:00 Martin Kosek >:


On 10/14/2015 03:43 PM, zhiyong xue wrote:
>   There are lots of VMs created from Openstack in our
envrioment. And we
> need to install IPA client on them.  I want to create a base
image which
> have installed IPA client, and generate VM from this image.
>
>   When the VM first boot will auto register to IPA server. But
the VM's
> host name has no domain(not a FQDN) and failed to register.

How does the client get the domain then? It is currently needed
for the FreeIPA
clients, so you need to either postpone Client registration until
domain is
set, or override the hostname in ipa-client-install with static
domain, like

# ipa-client-install --hostname `hostname`.mydomain.test

>What's the right approach to install IPA client for VMs which
cloned
> from base image?
>
> Thanks,
> -- Brave
>
>
>






-- 
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] nsslapd-dbcachesize and database size

[Rich Megginson]

On 10/14/2015 07:09 AM, Andrew E. Bruno wrote:

The load average on our freeipa replicas started to spike over the
last few days and we narrowed it down to a dbcache issue. Following the
guidelines here: https://github.com/richm/scripts/wiki/dbmon.sh

We saw that the dbcachefree was 2.0% which indicates a lot of page
churn. Sure enough our nsslapd-dbcachesize was set to 2G and the size of
our database and index files was 3.1G:

$ du -sh /var/lib/dirsrv/slapd-[domain]/db/
3.1G

Once we increased nsslapd-dbcachesize to 6G load average went back to
normal and query response times improved. Interestingly, when we
restarted the dirsrv process the database size went down to 1.7G

$ du -sh /var/lib/dirsrv/slapd-[domain]/db/
1.7G

When we initially deployed freeipa, the size of our database and indexes
was about 400M which is why we set nsslapd-dbcachesize to 2G.


What about your cachememsize?



A few questions:

1. What causes the increase in size of
/var/lib/dirsrv/slapd-[domain]/db/*  and should we periodically clean up?


Replication metadata accounts for some of this.  Fragmentation accounts 
for some of this.  You can periodically clean up, but you shouldn't have 
to.  The growth should eventually hit a plateau.




2. How do you tune nsslapd-dbcachesize to account for this growth? The
dbmon.sh wiki suggests a 12% overhead but our db files and indexes seem
to grow much larger?


12% is sort of a starting point.  There isn't a good way to tell how to 
account for replication metadata, fragmentation, etc.  Just monitor 
periodically and adjust as needed.




We're running:
- ipa-server-4.1.0-18.el7.centos.4.x86_64 and
- 389-ds-base-1.3.3.1-20.el7_1.x86_64

Thanks,

--Andrew



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

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

[Rich Megginson]

On 10/01/2015 01:52 PM, Rob Crittenden wrote:

Dominik Korittki wrote:

Hello folks,

I am running two FreeIPA Servers with around 100 users and around 15.000
hosts, which are used by users to login via ssh. The FreeIPA servers
(which are Centos 7.0) ran good for a while, but as more and more hosts
got migrated to serve as FreeIPA hosts, it started to get slow and
unstable.

For example, its hard to maintain hostgroups, which have more than 1.000
hosts. The ipa host-* commands are getting slower as the hostgroup
grows. Is this normal?

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


We also experience random dirsrv segfaults. Here's a dmesg line from the
latest:

[690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]

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


and
debuginfo-install ipa-server slapi-nis
in addition to the other packages

Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
problem.
I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
solve my problems?

FreeIPA server version is 3.3.3-28.el7.centos
389-ds-base.x86_64 is 1.3.1.6-26.el7_0



Kind regards,
Dominik Korittki



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

Re: [Freeipa-users] DNS Replication Validation

[Rich Megginson]

On 09/24/2015 09:24 AM, Aric Wilisch wrote:

Is there a way of exporting the DNS information out of Freeipa? Then I could 
just do a diff on the export from master and replica.


That's what Martin was suggesting you use dnspython to do.




On Sep 24, 2015, at 11:13 AM, Martin Basti  wrote:



On 09/24/2015 05:02 PM, Rich Megginson wrote:

On 09/24/2015 08:53 AM, Martin Basti wrote:


On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:

I need a way to validate that both the primary and the redundant FreeIPA 
server’s DNS zones are in sync. What’s the simplest way for me to do this?

Do a DNS query to confirm that the SOA record for the primary is identical to 
the SOA for the secondary.

SOA serials are not replicated.

So with IPA you can have a master DNS and a replica DNS that have different SOA?

Just SOA serial, other records are replicated.


Then the records are replicated using the standard IPA dirsrv replication 
protocol?

In that case, doesn't ipa-replica-manage have a way to ask if the replicas are 
in sync?

I don't think that ipa-replica-manage is capable to detect if replicas are in 
sync.
AFAIK this feature is planned for future IPA versions.
Inspecting DS error log may help to find replication issues if any.

Martin


You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html

That seems pretty heavyweight if there are a lot records.


HTH
Martin

My boss won’t let me continue with an upgrade until he’s sure the primary and 
redundant servers have the same DNS records and are in sync. I’ve tried finding 
documentation on this but keep coming up blank.

Thanks in advance.


--
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] DNS Replication Validation

[Rich Megginson]

On 09/24/2015 08:53 AM, Martin Basti wrote:



On 09/24/2015 04:43 PM, Rich Megginson wrote:

On 09/24/2015 08:32 AM, Aric Wilisch wrote:
I need a way to validate that both the primary and the redundant 
FreeIPA server’s DNS zones are in sync. What’s the simplest way for 
me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.


SOA serials are not replicated.


So with IPA you can have a master DNS and a replica DNS that have 
different SOA?


Then the records are replicated using the standard IPA dirsrv 
replication protocol?


In that case, doesn't ipa-replica-manage have a way to ask if the 
replicas are in sync?




You can get all  records via AXFR, and compare them per zone.

Maybe you can use python-dns to do comparation

http://www.dnspython.org/examples.html


That seems pretty heavyweight if there are a lot records.



HTH
Martin




My boss won’t let me continue with an upgrade until he’s sure the 
primary and redundant servers have the same DNS records and are in 
sync. I’ve tried finding documentation on this but keep coming up 
blank.


Thanks in advance.







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

Re: [Freeipa-users] DNS Replication Validation

[Rich Megginson]

On 09/24/2015 08:32 AM, Aric Wilisch wrote:

I need a way to validate that both the primary and the redundant FreeIPA 
server’s DNS zones are in sync. What’s the simplest way for me to do this?


Do a DNS query to confirm that the SOA record for the primary is 
identical to the SOA for the secondary.




My boss won’t let me continue with an upgrade until he’s sure the primary and 
redundant servers have the same DNS records and are in sync. I’ve tried finding 
documentation on this but keep coming up blank.

Thanks in advance.



--
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] replicas unresponsive with increasing file descriptors

[Rich Megginson]

On 09/01/2015 09:20 AM, Andrew E. Bruno wrote:

On Tue, Sep 01, 2015 at 05:03:10PM +0200, Ludwig Krispenz wrote:

On 09/01/2015 04:39 PM, Andrew E. Bruno wrote:

A few months ago we had a replica failure where the system ran out of file
descriptors and the slapd database was corrupted:

https://www.redhat.com/archives/freeipa-users/2015-June/msg00389.html

We now monitor file descriptor counts on our replicas and last night we
had 2 of our 3 replicas fail and become completely unresponsive. Trying
to kinit on the replica resulted in:

[user@ipa-master]$ kinit
kinit: Generic error (see e-text) while getting initial credentials


Snippet from the /var/log/dirsrv/slapd-[domain]/errors:

[31/Aug/2015:17:14:39 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Warning: 
Attempting to release replica, but unable to receive endReplication extended operation 
response from the replica. Error -5 (Timed out)
[31/Aug/2015:17:16:39 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:18:42 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:20:42 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:22:47 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:24:47 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:24:47 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Incremental 
protocol: event backoff_timer_expired should not occur in state start_backoff
[31/Aug/2015:17:26:50 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.
[31/Aug/2015:17:28:50 -0400] NSMMReplicationPlugin - 
agmt="cn=meTosrv-m14-30.cbls.ccr.buffalo.edu" (srv-m14-30:389): Unable to 
receive the response for a startReplication extended operation to consumer (Timed out). 
Will retry later.

The access logs were filling up with:

[31/Aug/2015:17:13:17 -0400] conn=1385990 fd=449 slot=449 connection from 
10.106.14.29 to 10.113.14.30
[31/Aug/2015:17:13:18 -0400] conn=1385991 fd=450 slot=450 connection from 
10.104.9.137 to 10.113.14.30
[31/Aug/2015:17:13:18 -0400] conn=1385992 fd=451 slot=451 connection from 
10.104.16.19 to 10.113.14.30
[31/Aug/2015:17:13:21 -0400] conn=1385993 fd=452 slot=452 connection from 
10.111.11.30 to 10.113.14.30
[31/Aug/2015:17:13:24 -0400] conn=1385994 fd=453 slot=453 connection from 
10.113.27.115 to 10.113.14.30
[31/Aug/2015:17:13:27 -0400] conn=1385995 fd=454 slot=454 connection from 
10.111.8.116 to 10.113.14.30
[31/Aug/2015:17:13:27 -0400] conn=1385996 fd=514 slot=514 connection from 
10.113.25.40 to 10.113.14.30
[31/Aug/2015:17:13:29 -0400] conn=1385997 fd=515 slot=515 connection from 
10.106.14.27 to 10.113.14.30
[31/Aug/2015:17:13:29 -0400] conn=1385998 fd=516 slot=516 connection from 
10.111.10.141 to 10.113.14.30
[31/Aug/2015:17:13:30 -0400] conn=1385999 fd=528 slot=528 connection from 
10.104.14.27 to 10.113.14.30
[31/Aug/2015:17:13:31 -0400] conn=1386000 fd=529 slot=529 connection from 
10.106.13.132 to 10.113.14.30
[31/Aug/2015:17:13:31 -0400] conn=1386001 fd=530 slot=530 connection from 
10.113.25.11 to 10.113.14.30
[31/Aug/2015:17:13:31 -0400] conn=1386002 fd=531 slot=531 connection from 
10.104.15.11 to 10.113.14.30
[31/Aug/2015:17:13:32 -0400] conn=1386003 fd=533 slot=533 connection from 
10.104.7.136 to 10.113.14.30
[31/Aug/2015:17:13:33 -0400] conn=1386004 fd=534 slot=534 connection from 
10.113.24.23 to 10.113.14.30
[31/Aug/2015:17:13:33 -0400] conn=1386005 fd=535 slot=535 connection from 
10.106.12.105 to 10.113.14.30
[31/Aug/2015:17:13:33 -0400] conn=1386006 fd=536 slot=536 connection from 
10.104.16.41 to 10.113.14.30
[31/Aug/2015:17:13:34 -0400] conn=1386007 fd=537 slot=537 connection from 
10.104.16.4 to 10.113.14.30
[31/Aug/2015:17:13:35 -0400] conn=1386008 fd=538 slot=538 connection from 
10.111.8.12 to 10.113.14.30
[31/Aug/2015:17:13:36 -0400] conn=1386009 fd=539 slot=539 connection from 
10.111.8.17 to 10.113.14.30



Seems like clients were connecting to the replicas b

Re: [Freeipa-users] GSSAPI authentication for libvirt VNC

[Rich Megginson]

On 09/01/2015 07:30 AM, Brendan Kearney wrote:

On 08/30/2015 12:49 PM, Marin Bernard wrote:

Hi,

I followed the instructions from freeipa.org (
https://www.freeipa.org/page/Libvirt_with_VNC_Consoles) to make libvirt
and VNC use GSSAPI authentication with FreeIPA. The libvirt part works
fine: I'm able to SSO the KVM host using TCP + SASL. However, I'm
unable to get a VNC connection to any guest: both virt-manager and virt
-viewer fail. The former speaks about a "closed or refused connection",
and the latter just closes.


On the KVM host, each VNC login attempt adds the following record to
the systemd journal:

qemu-kvm[3202]: GSSAPI server step 1


On the host, libvirt starts qemu-kvm with a SASL VNC, which seems
correct to me:

# ps -aux | grep qemu-kvm

 -vnc 0.0.0.0:0,sasl 


QEMU may read the VNC keytab

$ ls -l /etc/qemu/
total 4
-rw---. 1 qemu root 458 30 août  15:48 krb5.tab


Contents of /etc/sasl2/qemu-kvm.conf (comments removed)

mech_list: gssapi
keytab: /etc/qemu/krb5.tab


The client seems to grab correct tickets:

$ klist
Ticket cache: KEYRING:persistent:121541:krb_ccache_jjD9A46
Default principal: ma...@cloud.olivarim.com

Valid starting   Expires  Service principal
30/08/2015 16:11:22  31/08/2015 15:34:53 vnc/nice-hkvm-ctrl-01
.core.nice.cloud.olivarim@cloud.olivarim.com
30/08/2015 16:08:12  31/08/2015 15:34:53 libvirt/nice-hkvm-ctr
l-01.core.nice.cloud.olivarim@cloud.olivarim.com

KVM Host is Centos 7.2, up to date.

FreeIPA server is Centos 7.2, up to date, with FreeIPA 4.1.0 rev.
18.el7.centos.4

Client is Fedora 22, up to date.

I tried to disable both the firewall and SELinux but it did not change
anything.

Do you have any clues ?

Thanks!

Marin.


my /etc/sasl2/qemu.conf (note the different file name, may be relevant*):

mech_list: gssapi
keytab: /etc/qemu/qemu.keytab
sasldb_path: /etc/qemu/passwd.db
auxprop_plugin: sasldb

my /etc/sasl2/libvirt.conf:

mech_list: gssapi
keytab: /etc/libvirt/libvirt.keytab

my /etc/qemu/qemu.keytab file has the principal used/needed for VNC 
(vnc/host.domain.tld@REALM).  you can check yours with "klist -Kket 
/path/to/qemu.keytab"


my /etc/libvirt/libvirt.keytab file has the principal used/needed for 
virt-manager or virsh console (libvirt/host.domain.tld@REALM). you can 
check your with "klist -Kket /path/to/libvirt.keytab"


* the name of the file in /etc/sasl2/ is tied to the name of the 
application.  find the sysadmin.html page for Cyrus-SASL-libs, which 
states:


By default, the Cyrus SASL library reads it's options from 
/usr/lib/sasl2/App.conf (where "App" is the application defined name 
of the application). For instance, Sendmail reads it's configuration 
from "/usr/lib/sasl2/Sendmail.conf" and the sample server application 
included with the library looks in "/usr/lib/sasl2/sample.conf".


It is the appname argument of sasl_server_init(3):

sasl_server_init(3) SASL man pages sasl_server_init(3)

NAME
   sasl_server_init - SASL server authentication initialization

SYNOPSIS
   #include 

   int sasl_server_init(const sasl_callback_t *callbacks,
const char *appname);

DESCRIPTION
   sasl_server_init() initializes SASL. It must be called before 
any calls
   to sasl_server_start, and only once per process.  This call 
initializes
   all  SASL mechanism drivers (e.g. authentication mechanisms). 
These are
   usually found in the /usr/lib/sasl2 directory but the directory 
may  be
   overridden  with  the  SASL_PATH  environment  variable  (or at 
compile

   time).

   callbacks specifies the base callbacks for all client 
connections.  See

   the sasl_callbacks man page for more information.

   appname  is  the  name of the application. It is used for where 
to find

   the default configuration file.


--
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] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/24/2015 01:20 AM, Torsten Harenberg wrote:

Dear Rich and all,

thanks to everbody! Really thankful for your support.

The situation really approved.

We:

- enlarged the caches for 389ds until the WARNING messages disappeared
in the log files,
- (just to be sure) re-sync'ed firewalld rules between primary and
secondary server.

Now the server was stable, Kerberos and 389ds are still alive and all
clients can still resolve all users. There is only one issue left (see
bottom).


First let us answer that:

Am 23.07.15 um 18:28 schrieb Rich Megginson:


# ldapsearch -xLLL -D "cn=directory manager" -W -s base -b
"dc=uni-wuppertal,dc=de"

This search should return immediately.  If it hangs, then the problem is
in slapd, and get a stack trace as before.


[root@ipa httpd]# time ldapsearch -xLLL -D "cn=directory manager" -W -s
base -b "dc=pleiades,dc=uni-wuppertal,dc=de"
Enter LDAP Password:
dn: dc=pleiades,dc=uni-wuppertal,dc=de
objectClass: top
objectClass: domain
objectClass: pilotObject
objectClass: domainRelatedObject
objectClass: nisDomainObject
dc: pleiades
info: IPA V2.0
nisDomain: pleiades.uni-wuppertal.de
associatedDomain: pleiades.uni-wuppertal.de


real0m4.559s
user0m0.403s
sys 0m0.057s
[root@ipa httpd]#

Looks okay to us, or?


4 seconds?  That seems way too long.

What does the dirsrv access log look like for this sequence of 
operations?  There will be a connection, a BIND, a SRCH, and an UNBIND.




So.. here is the problem which is left over. When logging in as admin
now through th web page or locally:

[Thu Jul 23 21:43:47.340133 2015] [wsgi:error] [pid 1134] ipa: INFO:
[jsonserver_session] wens...@pleiades.uni-wuppertal.de:
radiusproxy_find(None, version=u'2.114'): SUCCESS
[Thu Jul 23 21:43:48.758849 2015] [wsgi:error] [pid 1133] ipa: INFO:
[jsonserver_session] wens...@pleiades.uni-wuppertal.de: user_find(None,
version=u'2.114'): SUCCESS
[Fri Jul 24 07:20:10.198903 2015] [wsgi:error] [pid 1134] ipa: INFO: 401
Unauthorized: kinit: Clients credentials have been revoked while getting
initial credentials
[Fri Jul 24 07:20:10.198977 2015] [wsgi:error] [pid 1134]
[Fri Jul 24 07:20:18.181715 2015] [wsgi:error] [pid 1133] ipa: INFO: 401
Unauthorized: kinit: Clients credentials have been revoked while getting
initial credentials
[Fri Jul 24 07:20:18.181809 2015] [wsgi:error] [pid 1133]
[Fri Jul 24 07:21:12.919751 2015] [wsgi:error] [pid 1134] ipa: INFO: 401
Unauthorized: kinit: Clients credentials have been revoked while getting
initial credentials
[Fri Jul 24 07:21:12.919878 2015] [wsgi:error] [pid 1134]
[root@ipa httpd]# kinit admin
kinit: Clients credentials have been revoked while getting initial
credentials
[root@ipa httpd]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@pleiades.uni-wuppertal.de

Valid starting   Expires  Service principal
07/23/2015 11:44:13  07/24/2015 11:44:08
HTTP/ipa.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de
07/23/2015 11:44:11  07/24/2015 11:44:08
krbtgt/pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de
[root@ipa httpd]#


Hope you have an idea about that one as well :).


I do not, sorry.  Maybe one of our kerberos experts will know.



Thanks

  Marisa and Torsten




--
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] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 11:47 PM, Torsten Harenberg wrote:

Good morning,

Am 22.07.15 um 19:25 schrieb Rich Megginson:

On 07/22/2015 11:03 AM, Torsten Harenberg wrote:

Dear Rich,

Am 22.07.2015 um 17:03 schrieb Rich Megginson:

It might be helpful to do a # debuginfo-install 389-ds-base ipa-server
slapi-nis
and follow the directions at
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
to get a full stack trace

thanks for the hint. Did that. But assume I need to wait until it hangs
again, right?

Right.

problem happend again, this time with slightly different symtoms:


[root@wn108 ~]# id atlasprd020
id: atlasprd020: No such user


after restarting dirserv:


[root@wn108 ~]# id atlasprd020
uid=18970(atlasprd020) gid=1407(atlasprd) groups=1407(atlasprd)
[root@wn108 ~]#

So of course the whole site was down.

the dirserv log file has not much:

[22/Jul/2015:11:03:35 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=pleiades,dc=uni-wuppertal,dc=de--no CoS Templates
found, which should be add
ed before the CoS Definition.
[22/Jul/2015:11:03:38 +0200] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: disordely shutdown for replica
dc=pleiades,dc=uni-wuppertal,dc=de. Check
  if DB RUV needs to be updated
[22/Jul/2015:11:03:38 +0200] NSMMReplicationPlugin - Force update of
database RUV (from CL RUV) ->  55af7af3000e0004
[22/Jul/2015:11:03:39 +0200] set_krb5_creds - Could not get initial
credentials for principal
[ldap/ipa.pleiades.uni-wuppertal...@pleiades.uni-wuppertal.de] in keyta
b [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[22/Jul/2015:11:03:39 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=pleiades,dc=uni-wuppertal,dc=de--no CoS Templates
found, which should be add
ed before the CoS Definition.
[22/Jul/2015:11:03:39 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(
-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code
may provide more information (No Kerberos credentials available)) errno
0 (Success)
[22/Jul/2015:11:03:39 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[22/Jul/2015:11:03:39 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa2.pleiades.uni-wuppertal.de" (ipa2:389): Replication
bind with GSSAPI auth failed: LDAP error -2
  (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (No Kerberos
credentials available))
[22/Jul/2015:11:03:39 +0200] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[22/Jul/2015:11:03:39 +0200] - Listening on All Interfaces port 636 for
LDAPS requests
[22/Jul/2015:11:03:39 +0200] - Listening on
/var/run/slapd-PLEIADES-UNI-WUPPERTAL-DE.socket for LDAPI requests
[22/Jul/2015:11:03:43 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa2.pleiades.uni-wuppertal.de" (ipa2:389): Replication
bind with GSSAPI auth resumed
[22/Jul/2015:15:15:41 +0200] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [51351] into an
unused SID.
[22/Jul/2015:15:15:41 +0200] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, line 149]: Cannot add SID to new entry.
[23/Jul/2015:07:33:05 +0200] - slapd shutting down - signaling operation
threads - op stack size 48 max work q size 22 max work q stack size 22
[23/Jul/2015:07:33:05 +0200] - slapd shutting down - waiting for 1
thread to terminate
[23/Jul/2015:07:33:05 +0200] - slapd shutting down - closing down
internal subsystems and plugins
[23/Jul/2015:07:33:05 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa2.pleiades.uni-wuppertal.de" (ipa2:389): Warning:
Attempting to release replica, but unable to r
eceive endReplication extended operation response from the replica.
Error -5 (Timed out)
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - timeout registering with
portmap service
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - timeout registering with
portmap service
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - error sending request to
portmap or rpcbind on 9: Connection refused
[23/Jul/2015:07:33:06 +0200] nis-plugin - timeout registering with
portmap service
[23/Ju

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 02:09 PM, Torsten Harenberg wrote:

Am 22.07.2015 um 21:49 schrieb Rich Megginson:

but strage: there is no bind binary:

Then I'm not sure what's going on.

currently there is a java process on ldaps:

[root@ipa ~]# netstat -p -n | grep 636
tcp6   0  0 132.195.124.12:636  132.195.124.12:36546
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:636  132.195.124.12:36553
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:36546132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:36549132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:36551132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:36553132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:636  132.195.124.12:36549
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:36548132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:36550132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:636  132.195.124.12:36554
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:36554132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:636  132.195.124.12:36548
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:636  132.195.124.12:36547
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:36552132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:36547132.195.124.12:636
VERBUNDEN   1331/java
tcp6   0  0 132.195.124.12:636  132.195.124.12:36550
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:636  132.195.124.12:36552
VERBUNDEN   800/ns-slapd
tcp6   0  0 132.195.124.12:636  132.195.124.12:36551
VERBUNDEN   800/ns-slapd

[root@ipa ~]# ps ax | grep 1331
  1331 ?Ssl2:19 /usr/lib/jvm/jre/bin/java
-DRESTEASY_LIB=/usr/share/java/resteasy -classpath
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar
-Dcatalina.base=/var/lib/pki/pki-tomcat
-Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs=
-Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp
-Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.security.manager
-Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy
org.apache.catalina.startup.Bootstrap start
  8411 pts/1S+ 0:00 grep --color=auto 1331
[root@ipa ~]#

Could that cause these requests?


Possibly, but I didn't think DogTag used persistent search.



Best regards,

   Torsten




--
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] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 01:47 PM, Torsten Harenberg wrote:

Am 22.07.2015 um 21:32 schrieb Rich Megginson:

On 07/22/2015 01:17 PM, Jakub Hrozek wrote:

On Wed, Jul 22, 2015 at 11:25:12AM -0600, Rich Megginson wrote:

/lib64/libpthread.so.0
#1  0x7fb8544f5440 in PR_WaitCondVar () from /lib64/libnspr4.so
#2  0x7fb8565f19a5 in ps_send_results ()
#3  0x7fb8544facab in _pt_root () from /lib64/libnspr4.so
#4  0x7fb853e9b52a in start_thread () from /lib64/libpthread.so.0
#5  0x7fb853bd722d in clone () from /lib64/libc.so.6

What is the client here that is doing a persistent search or syncrepl?
Is it BIND?

To be honest, I have no idea. Bind ist installed (with ipa) but I
haven't configured DNS services.

My first guess would be the secondary IPA?

No, probably not.  I think it is either BIND or sssd.

Rich, if you're certain that the lient is doing a syncrepl, then it's
bind. SSSD doesn't do syncrepl..(yet)


I'm not sure how else 389 would be in ps_send_results without a client
doing a persistent search.  So BIND it is.



but strage: there is no bind binary:


Then I'm not sure what's going on.



[root@ipa ~]# rpm -qa | grep bind
bind-libs-9.9.6-9.P1.fc21.x86_64
bind-utils-9.9.6-9.P1.fc21.x86_64
samba-winbind-modules-4.1.17-1.fc21.x86_64
bind-license-9.9.6-9.P1.fc21.noarch
jackson-databind-2.4.1.3-1.fc21.noarch
invokebinder-1.1-8.fc21.noarch
samba-winbind-4.1.17-1.fc21.x86_64
cmpi-bindings-pywbem-0.9.5-8.fc21.x86_64
bind-libs-lite-9.9.6-9.P1.fc21.x86_64
rpcbind-0.2.2-2.1.fc21.x86_64
[root@ipa ~]#

[root@ipa ~]# rpm -qi bind
Das Paket bind ist nicht installiert
[root@ipa ~]#


[root@ipa ~]# ps ax | grep bind
  1449 ?Ss 0:00 /usr/sbin/winbindd
  1450 ?S  0:01 /usr/sbin/winbindd
  8094 pts/1S+ 0:00 grep --color=auto bind
[root@ipa ~]#

Cheers

   Torsten




--
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] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 01:17 PM, Jakub Hrozek wrote:

On Wed, Jul 22, 2015 at 11:25:12AM -0600, Rich Megginson wrote:

/lib64/libpthread.so.0
#1  0x7fb8544f5440 in PR_WaitCondVar () from /lib64/libnspr4.so
#2  0x7fb8565f19a5 in ps_send_results ()
#3  0x7fb8544facab in _pt_root () from /lib64/libnspr4.so
#4  0x7fb853e9b52a in start_thread () from /lib64/libpthread.so.0
#5  0x7fb853bd722d in clone () from /lib64/libc.so.6

What is the client here that is doing a persistent search or syncrepl?
Is it BIND?

To be honest, I have no idea. Bind ist installed (with ipa) but I
haven't configured DNS services.

My first guess would be the secondary IPA?

No, probably not.  I think it is either BIND or sssd.

Rich, if you're certain that the lient is doing a syncrepl, then it's
bind. SSSD doesn't do syncrepl..(yet)



I'm not sure how else 389 would be in ps_send_results without a client 
doing a persistent search.  So BIND it is.


--
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] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 11:03 AM, Torsten Harenberg wrote:

Dear Rich,

Am 22.07.2015 um 17:03 schrieb Rich Megginson:

It might be helpful to do a # debuginfo-install 389-ds-base ipa-server
slapi-nis
and follow the directions at
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
to get a full stack trace

thanks for the hint. Did that. But assume I need to wait until it hangs
again, right?


Right.



Or is the trace now useful as well?



/lib64/libpthread.so.0
#1  0x7fb8544f5440 in PR_WaitCondVar () from /lib64/libnspr4.so
#2  0x7fb8565f19a5 in ps_send_results ()
#3  0x7fb8544facab in _pt_root () from /lib64/libnspr4.so
#4  0x7fb853e9b52a in start_thread () from /lib64/libpthread.so.0
#5  0x7fb853bd722d in clone () from /lib64/libc.so.6

What is the client here that is doing a persistent search or syncrepl?
Is it BIND?

To be honest, I have no idea. Bind ist installed (with ipa) but I
haven't configured DNS services.

My first guess would be the secondary IPA?


No, probably not.  I think it is either BIND or sssd.


But I do see a connection in
the connection list:

[root@ipa ~]# netstat -n | grep 389
tcp0  0 132.195.124.12:54165132.195.124.12:389
VERBUNDEN
tcp0  0 132.195.124.12:38147132.195.124.13:389
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.87:53329
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.82:40318
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.175:38594
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.103:49170
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.149:56597
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.140:54072
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.78:40696
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.84:48177
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.96:49207
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.171:42650
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.130:50921
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.76:50983
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.211:52241
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.156:58316
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.89:53923
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.41:52193
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.55:49024
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.47:43523
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.115:57328
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.105:41527
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.165:59116
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.69:37154
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.112:35861
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.34:35281
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.66:38854
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.62:41879
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.71:38302
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.108:45796
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.36:59637
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.80:54565
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.102:49728
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.97:36546
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.155:45730
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.75:53949
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.33:46382
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.98:53164
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.213:45945
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.160:48080
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.29:56264
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.180:58558
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.74:58274
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.52:42197
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.158:44226
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.151:46135
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.25:50124
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.181:54617
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.99:52665
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.125.126:40899
VERBUNDEN
tcp6   0  0 132.195.124.12:389  132.195.124.24:36240
VERBUNDEN

Re: [Freeipa-users] Kerberos hanging approx. once a day

[Rich Megginson]

On 07/22/2015 03:39 AM, Torsten Harenberg wrote:

Dear Alexander, dear Sumit,

thank you very much indeed for the quick replies.

Am 22.07.15 um 11:21 schrieb Sumit Bose:

Looks like there are issues getting the needed data from the local LDAP
server. The message below about the master key points into the same
direction. Can you check the 389ds logs?

I have attached the
/var/log/dirsrv/slapd-PLEIADES-UNI-WUPPERTAL-DE/errors file to the end
of the mail, it's a bit larger.

There are some "ticket expired" messages, could that point to the source
of the problem?


Am 22.07.15 um 11:22 schrieb Alexander Bokovoy:

Do you have 389-ds actually operating? If you would install debuginfo
packages, what does 'pstack ' print?

here is the output:



It might be helpful to do a # debuginfo-install 389-ds-base ipa-server 
slapi-nis
and follow the directions at 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

to get a full stack trace


/lib64/libpthread.so.0
#1  0x7fb8544f5440 in PR_WaitCondVar () from /lib64/libnspr4.so
#2  0x7fb8565f19a5 in ps_send_results ()
#3  0x7fb8544facab in _pt_root () from /lib64/libnspr4.so
#4  0x7fb853e9b52a in start_thread () from /lib64/libpthread.so.0
#5  0x7fb853bd722d in clone () from /lib64/libc.so.6


What is the client here that is doing a persistent search or syncrepl?  
Is it BIND?



Thread 1 (Thread 0x7fb856808800 (LWP 800)):
#0  0x7fb853bcbc8d in poll () from /lib64/libc.so.6
#1  0x7fb8544f6da8 in _pr_poll_with_poll () from /lib64/libnspr4.so
#2  0x7fb8565e9b11 in slapd_daemon ()
#3  0x7fb8565dc4f4 in main ()
[root@ipa log]#

Best regards and thanks again

   Torsten


/var/log/dirsrv/slapd-PLEIADES-UNI-WUPPERTAL-DE/errors:

[root@ipa slapd-PLEIADES-UNI-WUPPERTAL-DE]# cat errors
389-Directory/1.3.3.8 B2015.036.047
ipa.pleiades.uni-wuppertal.de:636
(/etc/dirsrv/slapd-PLEIADES-UNI-WUPPERTAL-DE)

[20/Jul/2015:16:48:26 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:26 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:26 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[20/Jul/2015:16:48:26 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa2.pleiades.uni-wuppertal.de" (ipa2:389): Replication
bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1):
generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may
provide more information (Ticket expired))
[20/Jul/2015:16:48:30 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:30 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:30 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[20/Jul/2015:16:48:36 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:36 +0200] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Ticket expired))
errno 2 (No such file or directory)
[20/Jul/2015:16:48:36 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[20/Jul/2015:16:48:48 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa2.pleiades.uni-wuppertal.de" (ipa2:389): Replication
bind with GSSAPI auth resumed
[21/Jul/2015:14:41:05 +0200] find_sid_for_ldap_entry - [file
ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [50088] into an
unused SID.
[21/Jul/2015:14:41:05 +0200] ipa_sidgen_add_post_op - [file
ipa_sidgen.c, li

Re: [Freeipa-users] Sync useradd from IPA to AD

[Rich Megginson]

On 07/20/2015 07:02 AM, Email wrote:
Hi Rich, thanks for the reply.  Here is the link I  working with 
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/active-directory-trust.html 



I'm looking at both options, the cross forest trust and winsync.  For 
my project FreeIPA needs to be authoritative wherever possible.  Users 
need one domain account that works on Linux and Windows.  Why would 
trusts be a better solution that winsync?  Thanks for your help.


Please keep replies on-list.

In general, any time you don't have to copy information around, and 
ensure that it is in sync, and remains in sync, that is a better 
solution.  Trusts does not copy/sync information, so in general it is 
preferred.


In your case, it seems that you want FreeIPA to be the authoritative 
source of information?  And you want to create new users/groups in 
FreeIPA, and use that information in the AD/Windows environment?  Is 
that correct?




Tony

On Wednesday, July 15, 2015, Rich Megginson <mailto:rmegg...@redhat.com>> wrote:


On 07/15/2015 09:42 AM, Email wrote:

Hi everyone, my name is Tony and this is my first post, so it's
nice to meet all of you. I've been tasked with creating an AD and
FreeIPA environment, and I'm looking into the sync between the
two.  It looks like creating a user in AD causes that user to be
created in IPA, but not the other way around.  But if I create
them in IPA they will not be auto created in AD.  I'm wondering
why this is.


This is intentional.  If you are using FreeIPA and windows sync,
it is assumed you want AD to be the provisioning system for new
users, and not FreeIPA.

I would seriously consider using trusts instead of windows sync.

See section 8.1 of the fedora documentation as a reference. 


Link please?  We may need to clarify the language.


Thanks in advance!

~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] FreeIPA and sambaPwdLastSet

[Rich Megginson]

On 07/20/2015 07:56 AM, Christopher Lamb wrote:

Hi Rob

The users do have the sambaSamAccount ObjectClass.

Or to be more precise, some have sambasamaccount (all lower case), and some
have sambaSAMAccount (mixed case)

Are objectclasses case sensitive?


No, unless there is a bug in the objectclass matching/comparison code.



Chris



From:   Rob Crittenden 
To: Christopher Lamb/Switzerland/IBM@IBMCH, Alexander Bokovoy
 
Cc: freeipa-users@redhat.com
Date:   20.07.2015 15:47
Subject:Re: [Freeipa-users] FreeIPA and sambaPwdLastSet



Christopher Lamb wrote:

Hi Alexander

This issue got overtaken by others, and slipped off my radar for a bit...

While the solution suggested earlier in this thread at


http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA

sounds interesting (and we are running the correct versions of OEL 7.1

and

SSSD), it seems to require the Windows clients to be members of an Active
Diretory trusted by IPA.

Unfortunately there is no AD in our architecture - our Windows and OSX
clients are effectively islands. That would seem to leave us stuck with
sambaPwdLastSet.

After a user has had his password reset via the IPA WebUi to a temporary
value, the user then logs on using the temporary password, and is asked

to

enter a new password. At his point sambaPwdLastSet should be set to a
positive value. However our testing indicates that it is not. We have

tried

3 techniques:

1) User connects to LDAP server via remote ssh.

2) kinit 

3) su -  over an existing ssh session with another user (e.g. mine)

In all three cases the user is able to set their password, but
sambaPwdLastSet remains set to 0.

As a workaround we use Apache Directory Studio to manually set
sambaPwdLastSet once the user has changed his password.

Chris

AFAICT the user needs the sambaSamAccount objectclass in order for this
to work. Is that the case?

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] Windows sync agreement becomes uninitialized and crashes directory server

[Rich Megginson]

On 07/13/2015 07:07 PM, nat...@nathanpeters.com wrote:

2 FreeIPA 4.1.4 servers running on CentOS 7.
dc1 has a sync agreement to a windows server.


It has been running fine since June 5 when I re-initialized a sync
agreement that had somehow uninitialized itself.  Original issue report
here :
https://www.redhat.com/archives/freeipa-users/2015-June/msg00147.html
Bug report here : https://fedorahosted.org/freeipa/ticket/5054

It appears the same thing may have happened again, one month later, but
this time randomly, as we have not made any changes to our sync agreement
since the initial change in June.  it appears to have unitialized itself
without us changing it and managed to crash the directory server in doing
so.


Crash? http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
# debuginfo-install 389-ds-base ipa-server slapi-nis


  Note that during the last week I could still login to the web ui, but
around the time the log entries change, I became unable to.

I tried to login to the web server today and it would not let me login, so
I went to the shell on the server and noticed that ipactl command would
freeze up again.  I looked at the logs (which I will paste below) and
restarted the directory server service.

I then found that my sync agreement had become uninitialized.

--- output ---
[root@dc1 slapd-IPADOMAIN-NET]# ldapsearch -xLLL -D "cn=directory manager"
-W -b cn=config objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
  \2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
  RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
  0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ2k0N0NxRGZFd2JIdm
  I0MFVFZVI3MA==}gWI9NIB8lbt9tmNszzbBFCAe4Vs/e0sMyn5+NZPJg9E=
nsds7DirsyncCookie::
TVNEUwMAAABoJPGME7jQAQAAYAEAAPc1qQAAA
  AD3NakAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
  13PwAADGzFNzznrESIxHzA74fbsz4HUgAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
  PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+/FcJAAA4qTQaC46/Ua4KXgP
  /ixNcbK4dgAAWowbgYD1akibZ+sCul5C4VNsMQAAxSO4iapVmEGQ6R23bgLQi/c1qQAAA
  AAAogC6jFcyFUmhBp4B7FkaBcRHwwEAyhKMxsP0uUKGEnG2lsyA8eTUwgYA4n8Xx1bAlU
  mBUl3zhlZ9WBngDAAA71vM2ebFEkCJkBaLjB4CGU+4CQMAGfO+4ndZCkaVKnwZNlNsf90
  NDAAAgD6n+M2bcUGkOwo5gPLx7IOjAwAA
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 4 ldap://dc1.ipadomain.net:389} 553fe9c9
  0004 557f49fb00020004
nsds50ruv: {replica 3 ldap://dc2.ipadomain.net:389} 553fe9c
  40003 557f3e4a00020003
nsruvReplicaLastModified: {replica 4 ldap://dc1.ipadomain.ne
  t:389} 557f494a
nsruvReplicaLastModified: {replica 3 ldap://dc2.ipadomain.n
  et:389} 557f3d95
oneWaySync: fromWindows
nsds5ReplicaEnabled: on
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: -1  - LDAP error: Can't contact LDAP server
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
--- output ---

Here are the error logs for the last month for the directory server.  They
are totally empty until July 2.

---output---
 389-Directory/1.3.3.8 B2015.040.128
 dc1.ipadomain.net:636 (/etc/dirsrv/slapd-IPADOMAIN-NET)

[02/Jul/2015:03:19:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[02/Jul/2015:06:10:29 +] - Entry
"uid=jenkinsdev,cn=users,cn=accounts,dc=ipadomain,dc=net" missing
attribute "sn" required by object class "person"
[03/Jul/2015:02:04:02 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:05:39:01 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:17:09:00 +] NSMMReplicationPlugin - windows sync - failed
to send dirsync search request: 2
[03/Jul/2015:22:41:32 +] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind

Re: [Freeipa-users] Migrating from custom auth system

[Rich Megginson]

On 07/09/2015 08:36 AM, Nicola Canepa wrote:
If I enable the PAM plugin of 389-ds, I'm able to let users be 
authenticated by PAM, even if the user is not present il LDAP, hence 
the plain-text password is passed to PAM.
The only missing step is: if PAM correctly authenticates a 
non-existing user, it should be created (using the just supplied 
password).


The 389-ds PAM passthrough auth plugin can't add users.  You would have 
to add some additional functionality to either PAM, or another 389-ds 
plugin.




Nicola

Il 09/07/15 15:20, Alexander Bokovoy ha scritto:

On Thu, 09 Jul 2015, Nicola Canepa wrote:

Thank you Alexander.
If the previous password is not used, I could set an impossible-hash 
password (such as "{crypt}*") and let users login authenticating 
trhough PAM?

How would you authenticate then? Remember that it is the hash in
userPassword attribute that is used for actual authentication. If
password-handling plugin cannot calculate to the same hash based on the
plain-text password it was supplied via LDAP bind, how would user
successfully authenticate?

If you migrate this way, you need password hashes, at least.
If you are going to issue users with new passwords, just create all of
them in IPA with these new passwords and ask them to login, at least
once, to IPA self-service.

Or I could put the "user-add" in the pam_exec script (but only if 
the user does not already exists).

I don't think is is sufficiently good, at least I wouldn't do it this
way.





--
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] Multiple CA certificates (for PassSync)

[Rich Megginson]

On 07/09/2015 07:23 AM, Rob Crittenden wrote:

Joseph, Matthew (EXP) wrote:

Hello,

We are currently in the process of replacing our IdM 3.x server with 
4.x.


There are going to be some major directory changes during the upgrade so
I need to keep both the old and new IdM servers up and running 
separately.


Part of our configuration is using the password sync between IdM and
Active Directory.

I can’t find any information on this so I figured I’d ask you guys to
see if anyone has done this before.

Can I have two CA certificates from 2 IdM servers installed on the
Active Directory server? And will this cause any issues with our
password sync?


I'm not sure if you can do this. The CA is probably the least of your 
problems. I don't believe the AD passsync service can be aware of 
multiple consumers like this.


Right.  passsync can talk to only 1 IdM server.

To use multiple CA certs, just use the certutil tool to install an 
additional CA cert as per the docs.




Rich may know.

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] Trace / Debug LDAP queries from 3rd Party Tools against FreeIPA Server

[Rich Megginson]

On 07/07/2015 10:09 AM, Martin Basti wrote:

On 07/07/15 17:39, Christopher Lamb wrote:

Hi All

Is there any way on the FreeIPA side to log / debug / trace the LDAP
queries made by 3rd Party Tools against a FreeIPA Server?

In another thread we are trying to solve some problems with 
integration of
JIRA to FreeIPA. I think if I can see the exact LDAP queries JIRA is 
making

against FreeIPA, then we will be well on the road to finding out what is
going wrong / needs to be changed.

I will be asking a similar question to Atlassian support for LDAP 
logging
on the JIRA side (there I already have partial success, but am not 
seeing

everything I want to see).

Cheers

Chris


Hello,

all LDAP queries are logged in this log
/var/log/dirsrv/slapd-*/access



If by "query" you mean "search request", then all of the search request 
data is logged in the dirsrv access log.
If you need details about other operations, you'll want to enable the 
audit log.


--
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] nsslapd-maxbersize and cachememsize

[Rich Megginson]

On 07/06/2015 11:49 AM, Andy Thompson wrote:

I've got a couple warnings in different IPA installs that I'm not sure how to 
find what values I should increase each config setting to.

In one install I'm seeing the following

[03/Jul/2015:22:03:02 -0400] connection - conn=16143 fd=122 Incoming BER 
Element was too long, max allowable is 209715200 bytes. Change the 
nsslapd-maxbersize attribute in cn=config to increase.


Second installation I'm seeing this on startup

WARNING: changelog: entry cache size 858992B is less than db size 2293760B; We 
recommend to increase the entry cache size nsslapd-cachememsize.

How can I determine what to increase each config setting to?


What version of 389?  rpm -q 389-ds-base



Thanks

-andy


*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***




--
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] what error log i should check

[Rich Megginson]

On 07/06/2015 09:54 AM, Rob Crittenden wrote:

barry...@gmail.com wrote:

server 1

ipa-replica-manage list
Segmentation fault (core dumped)

server 2
ipa-replica-manage list
Can't contact LDAP server


but it seem still syn as i add new ac then server 2 have

i delete server2 's anme server 1 still delte.


I'd start with the seg fault. Check dmesg and/or /var/log/messages to 
see what is dropping core and debug from there.


If it is ns-slapd that is crashing, see 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes


You will need to do

# debuginfo-install ipa-server slapi-nis



The can't contact LDAP server may be another representation of the 
same problem.


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] Unfamiliar message and crashes

[Rich Megginson]

On 06/29/2015 10:08 PM, Alexander Frolushkin wrote:


Hello.

What does message

NSMMReplicationPlugin - 
agmt="cn=cloneAgreement1-host1.domain.com-pki-tomcat" (host2:389): 
Unable to acquire replica: the replica instructed us to go into 
backoff mode. Will retry later.


mean?

A lot of these message appeared in error dirsrv log yesterday, and 
several crashes


ns-slapd[31026]: segfault at 25 ip 7f7aa499c800 sp 
7f7a4b7e14f0 error 4 in libslapd.so.0.0.0[7f7aa4948000+11c000]


also noticed…

Any thoughts, what to do?



Please provide the versions you are using:
# rpm -q 389-ds-base ipa-server slapi-nis

Debugging crashes:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

in addition:
# debuginfo-install ipa-server slapi-nis

We need to see some stack traces


WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764




Информация в этом сообщении предназначена исключительно для конкретных 
лиц, которым она адресована. В сообщении может содержаться 
конфиденциальная информация, которая не может быть раскрыта или 
использована кем-либо, кроме адресатов. Если вы не адресат этого 
сообщения, то использование, переадресация, копирование или 
распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, 
незамедлительно сообщите отправителю об этом и удалите со всем 
содержимым само сообщение и любые возможные его копии и приложения.


The information contained in this communication is intended solely for 
the use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally 
privileged information. The contents may not be disclosed or used by 
anyone other than the addressee. If you are not the intended 
recipient(s), any use, disclosure, copying, distribution or any action 
taken or omitted to be taken in reliance on it is prohibited and may 
be unlawful. If you have received this communication in error please 
notify us immediately by responding to this email and then delete the 
e-mail and all attachments and any copies thereof.


(c)20mf50




-- 
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] dirsrv access logs flooded from single connection id

[Rich Megginson]

On 06/29/2015 10:13 AM, Andrew E. Bruno wrote:

Our dirsrv access logs on our freeipa master server are getting flooded
with this:

[29/Jun/2015:12:02:09 -0400] conn=215758 op=1355326784 SRCH
base="cn=u2,cn=groups,cn=accounts,dc=ccr,dc=buffalo,dc=edu" scope=0
filter="(objectClass=*)" attrs="objectClass posixgroup cn userPassword
gidNumber member ipaNTSecurityIdentifier modifyTimestamp entryusn uid"

[29/Jun/2015:12:08:08 -0400] conn=215758 op=1356545457 RESULT err=0
tag=101 nentries=0 etime=0 notes=P

All from the same conn=215758. Logs get rotated every minute.

logconv.pl is showing

Searches: 265803(3322.54/sec) (199352.25/min)


How can I figure out which ip address this query is coming from? Is
there a way to fetch the ip using the connection id? conn=215758?


grep "conn=215758 fd=" /var/log/dirsrv/slapd-INST/access*

Unfortunately, if it has been rotated away, you won't be able to get the 
information from the access log.




Thanks in advance.

--Andrew



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

Re: [Freeipa-users] hesitate to deploy freeipa

[Rich Megginson]

On 06/25/2015 12:12 PM, Thomas Sailer wrote:

Am 25.06.2015 um 17:47 schrieb Simo Sorce:


Yes, the whole project is complex, but not because we like complexity,
it is complex because the problem space is complex and we are bound to
use existing protocols, which sometimes add in complexity, and we want
to offer useful features to admins, so they can think about managing
stuff and not about the plumbing all the time.


Sure, the problem space is a lot more complex than say ls.

But I think there is room for improvement, by making the individual 
tools somewhat more resilient to unexpected behaviour in other 
components.


+1 - just look at the bug lists for freeipa, 389, sssd, dogtag, etc.



For example, if there's any nsuniqueid group present in a users entry, 
login authentication via sssd breaks with a cryptic error message. It 
would be nice, IMO, if it didn't break or if it at least issued a 
better error message.


Sure.  For starters, there's https://fedorahosted.org/389/ticket/48161



Furthermore, a good graphical generic LDAP editor would make the 
admin's life significantly easier, IMO. I so far haven't found one. 
There's gq, which works, mostly, but crashes relatively frequently. 
I'm mostly using ldapvi now, which works quite well but only after 
studying its manual.


Have you tried Apache Directory Studio?



Thomas



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

[Rich Megginson]

On 06/19/2015 12:22 PM, Andrew E. Bruno wrote:

Hello,

First time trouble shooting an ipa server failure and looking for some
guidance on how best to proceed.

First some background on our setup:

Servers are running freeipa v4.1.0 on CentOS 7.1.1503:

- ipa-server-4.1.0-18.el7.centos.3.x86_64
- 389-ds-base-1.3.3.1-16.el7_1.x86_64

3 ipa-servers, 1 first master (rep1) and 2 (rep2, rep3) replicates. The
replicates were setup to be ca's (i.e. ipa-replica-install --setup-ca...)

We have ~3000 user accounts (~1000 active the rest disabled). We have
~700 hosts enrolled (all installed using ipa-client-install and running
sssd). Hosts clients are a mix of centos 7 and centos 6.5.


We recently discovered one of our replica servers (rep2) was not
responding. A quick check of the dirsrv logs
/var/log/dirsrv/slapd-/errors (sanitized):

 PR_Accept() failed, Netscape Portable Runtime error (Process open
 FD table is full.)
 ...

The server was rebooted and after coming back up had these errors in the logs:

 389-Directory/1.3.3.1 B2015.118.1941
 replica2:636 (/etc/dirsrv/slapd-)

[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to trickle, err=-30973 
(BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery)
[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - Serious Error---Failed in deadlock detect 
(aborted at 0x0), err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database 
recovery)
[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - Serious Error---Failed in deadlock detect 
(aborted at 0x0), err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database 
recovery)
[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to checkpoint database, 
err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery)
[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to checkpoint database, 
err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery)
[16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error 
detected; run recovery
[16/Jun/2015:10:12:33 -0400] - checkpoint_threadmain: log archive failed - 
BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery (-30973)

[16/Jun/2015:16:24:04 -0400] - 389-Directory/1.3.3.1 B2015.118.1941 starting up
[16/Jun/2015:16:24:04 -0400] - Detected Disorderly Shutdown last time Directory 
Server was running, recovering database.
...
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - 
replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX. 
Check if DB RUV needs to be updated
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV 
(from CL RUV) ->  5577006800030003
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV 
(from CL RUV) ->  556f463200140004
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV 
(from CL RUV) ->  556f4631004d0005
[16/Jun/2015:16:24:15 -0400] slapi_ldap_bind - Error: could not send startTLS 
request: error -1 (Can't contact LDAP server) errno 111 (Connection refused)
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - 
agmt="cn=cloneAgreement1-rep2 (rep1:389): Replication bind with SIMPLE auth 
failed: LDAP error -1 (Can't contact LDAP server) ()
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - 
replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. 
Check if DB RUV needs to be updated
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV 
(from CL RUV) ->  556f46290005005b
[16/Jun/2015:16:24:15 -0400] set_krb5_creds - Could not get initial credentials 
for principal [ldap/rep2] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 
(Cannot contact any KDC for requested realm)
[16/Jun/2015:16:24:15 -0400] slapd_ldap_sasl_interactive_bind - Error: could 
not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't 
contact LDAP server) ((null)) errno 111 (Connection refused)
[16/Jun/2015:16:24:15 -0400] slapi_ldap_bind - Error: could not perform 
interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't 
contact LDAP server)
[16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - agmt="cn=meTorep1" 
(rep1:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP 
server) ()
[16/Jun/2015:16:24:15 -0400] - Skipping CoS Definition cn=Password 
Policy,cn=accounts,dc=xxx--no CoS Templates found, which should be added before 
the CoS Definition.
[16/Jun/2015:16:24:15 -0400] DSRetroclPlugin - delete_changerecord: co

Re: [Freeipa-users] Migration error?

[Rich Megginson]

On 06/16/2015 06:18 AM, Ludwig Krispenz wrote:


On 06/16/2015 02:08 PM, Janelle wrote:

On Jun 16, 2015, at 01:56, thierry bordaz  wrote:

On 06/16/2015 09:02 AM, Ludwig Krispenz wrote:


On 06/16/2015 05:07 AM, Janelle wrote:

On 6/15/15 1:12 PM, Rob Crittenden wrote:
Janelle wrote:

On 6/15/15 6:36 AM, Rob Crittenden wrote:

Usually means there is a replication conflict entry. You may be 
able
to get more details on what failed by looking at the LDAP 
access log
of both LDAP servers, though I guess I'd expect this happened 
locally

on the IPA box.

Hi again,

I have been trying to follow this procedure for replication 
conflicts regarding "nsds5ReplConflict", where I had the two 
account duplicates, but no matter what, I still get:


modifying rdn of entry 
"nsuniqueid=ffc68a41-86e71c6-71714816-fcf248a0+uid=janelle,cn=users,cn=accounts,dc=example,dc=com"

ldap_rename: Constraint violation
additional info: Another entry with the same attribute value 
already exists (attribute: "uid")


When I am trying to run the modrdn (ldapmodify) command? Which 
simply refuses to work. I have been at it for over a week now with 
no luck.  I think this is the last of my issues causing my 
replication problems. What caused this is that I do have multiple 
helpdesk personnel that had been updating user accounts. This 
process has been resolved, but we can't seem to remove the last 
few duplicates.


Any suggestions? Is there a missing step in conflict resolution 
perhaps?
these entries are already a result of conflict resolution, If you 
add the same entry simultaneously on two servers (meaning add it on 
A and add it on B (before B has received the replicated add from 
A), there exist two entries with the same dn, which is not 
possible. So conflict resolution does not arbitrarily throw one 
away, but renames it and leaves it to the admin, which on to keep. 
So you should have one entry

uid=janelle,... and one nsuniqueid=+uid=janelle,
The error you get is coming from 'uid uniqueness'. Like ludwig 
mention,  it exists duplicated entries  with both of them 
'uid=janelle'.
'uid uniqueness' plugin prevents you to do a direct MODRDN on one of 
them because, it finds duplicated 'uid=janelle'.

you can delete the nsuniqeid= entry to get rid of it.

+1

thierry
There is a request to hide these nsuniqueid+uid entries from 
regular searches, it will be in a next release of 389


Ludwig

~J

--
But everything I try to delete fails.  Is there a procedure in 389-DS 
I can read for this? Maybe I am missing an option in ldapmodify? I am 
happy to delete, if only it would let me.

hm, it should be straightforwrd:
ldpapmodify -D  ..
dn: 
nsuniqueid=ffc68a41-86e71c6-71714816-fcf248a0+uid=janelle,cn=users,cn=accounts,dc=example,dc=com

changetype: delete

if it fails, what is the error you get ?


This is probably https://fedorahosted.org/389/ticket/48133
which is fixed in 389-ds-base-1.2.11.15-53.el6



~J




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

[Rich Megginson]

On 06/12/2015 03:25 PM, William Graboyes wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Ken,

I ran this command back to back, I am snipping some of the results.

First time I ran the command:

time ldapsearch -x -h 127.0.0.1 "(uid=admin)"
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: (uid=admin)
# requesting: ALL
#

- --snip--

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

real0m0.056s
user0m0.003s
sys 0m0.004s


Run on the same server not 5 seconds after the previous command:

time ldapsearch -x -h 127.0.0.1 "(uid=admin)"
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: (uid=admin)
# requesting: ALL
#

- -- snip --

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

real0m31.756s
user0m0.003s
sys 0m0.005s


Ok.  First, see 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes


You'll also have to do
# debuginfo-install ipa-server slapi-nis
to get all of the ipa packages.

Next, see http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

Reproduce the problem, and during the 30 seconds the directory server is 
processing the search request, run the gdb command several times to get 
stack traces during the search request.





I am starting to see this error in the dirserv logs:

[12/Jun/2015:14:06:51 -0700] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107
(Transport endpoint is not connected)
[12/Jun/2015:14:11:51 -0700] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107
(Transport endpoint is not connected)
[12/Jun/2015:14:16:51 -0700] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107
(Transport endpoint is not connected)
[12/Jun/2015:14:21:51 -0700] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107
(Transport endpoint is not connected)


I doubt this is related to the performance.  This looks like the server 
is attempting to contact a replica which is down, and has backed off for 
the full 5 minute max backoff.




Thanks,
Bill Graboyes


On 6/12/15 1:36 PM, Rich Megginson wrote:

On 06/12/2015 02:10 PM, Martin Kosek wrote:

On 06/12/2015 09:15 PM, William Graboyes wrote:

Hi Martin,

Here are the outputs of the various commands, cleaned of course:

time ldapsearch SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:

real0m32.464s user0m0.385s sys0m0.052s

This is quite long time. We should check respective dirsrv
errors and access logs snippets.

Also, the command above did not exit successfully, I would
recommend doing at least

# ldapsearch -x -h `hostname` "(uid=admin)"

To eliminate DNS from the equation, use
# time ldapsearch -x -h 127.0.0.1 "(uid=admin)"

time host ipa-server-2.foo.org <-- server with issues
ipa-server-2.foo.org has address 10.0.0.2

real0m0.070s user0m0.010s sys0m0.006s

time host ipa-server-1.foo.org <-- replicant with no issues
ipa-server-1.foo.org has address 10.0.0.3

real0m0.073s user0m0.012s sys0m0.006s

time kinit kinit: Cannot contact any KDC for realm 'FOO.ORG' while
getting initial credentials

real0m27.049s user0m0.013s sys0m0.004s

^^^ has been something I have been seeing intermittently



On 6/12/15 12:11 AM, Martin Kosek wrote:

Hi List,

This is a problem that has surfaced after a reboot of
this system in particular. It is being really, really
slow.  In terms of hardware usage issues, there are none.
It is taking 3-5 minutes to list users in the gui.
Running commands like ipa-replica-manage list is taking
between 30seconds and 3 minutes.  Memory usage is low,
cpu usage is low, iops are low.  I really have no idea
where to start here, there is noting really damning in
the logs.  I have tried restarting IPA (ipactl restart)
stopping and starting IPA (ipactl stop wait... ipactl
start), and rebooting the entire server.

The oddest thing is that there have been some krb errors
saying that they cannot contact the krb server.. logging
into the gui saying your session has timed out..

It is just general strangeness.

ipa-server-4.1.0-18.el7.centos.3.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
krb5-server-1.12.2-14.el7.x86_64

Any help would be greatly appreciated.

Thanks, Bill

I would recommend starting with simple things, seeing the
performance and then following with more complex stuff:

- Try bare "ldapsearch" against the FreeIPA LDAP server,
see the response rate. If it is also slow, we have the root
cause. Before ringing on DS people doors, see if for
example DNS is not slow and there are no DNS timeouts in
play - "host ipa.server.test&q

Re: [Freeipa-users] IPA very very slow

[Rich Megginson]

On 06/12/2015 02:10 PM, Martin Kosek wrote:

On 06/12/2015 09:15 PM, William Graboyes wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Martin,

Here are the outputs of the various commands, cleaned of course:

time ldapsearch
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:

real0m32.464s
user0m0.385s
sys0m0.052s


This is quite long time. We should check respective dirsrv errors and 
access logs snippets.


Also, the command above did not exit successfully, I would recommend 
doing at least


# ldapsearch -x -h `hostname` "(uid=admin)"


To eliminate DNS from the equation, use

# time ldapsearch -x -h 127.0.0.1 "(uid=admin)"





time host ipa-server-2.foo.org <-- server with issues
ipa-server-2.foo.org has address 10.0.0.2

real0m0.070s
user0m0.010s
sys0m0.006s

time host ipa-server-1.foo.org <-- replicant with no issues
ipa-server-1.foo.org has address 10.0.0.3

real0m0.073s
user0m0.012s
sys0m0.006s

time kinit
kinit: Cannot contact any KDC for realm 'FOO.ORG' while getting
initial credentials

real0m27.049s
user0m0.013s
sys0m0.004s

^^^ has been something I have been seeing intermittently



On 6/12/15 12:11 AM, Martin Kosek wrote:

Hi List,

This is a problem that has surfaced after a reboot of this system
in particular. It is being really, really slow.  In terms of
hardware usage issues, there are none.  It is taking 3-5 minutes
to list users in the gui. Running commands like
ipa-replica-manage list is taking between 30seconds and 3
minutes.  Memory usage is low, cpu usage is low, iops are low.  I
really have no idea where to start here, there is noting really
damning in the logs.  I have tried restarting IPA (ipactl
restart) stopping and starting IPA (ipactl stop wait... ipactl
start), and rebooting the entire server.

The oddest thing is that there have been some krb errors saying
that they cannot contact the krb server.. logging into the gui
saying your session has timed out..

It is just general strangeness.

ipa-server-4.1.0-18.el7.centos.3.x86_64
sssd-ipa-1.12.2-58.el7_1.6.x86_64
krb5-server-1.12.2-14.el7.x86_64

Any help would be greatly appreciated.

Thanks, Bill


I would recommend starting with simple things, seeing the
performance and then following with more complex stuff:

- Try bare "ldapsearch" against the FreeIPA LDAP server, see the
response rate. If it is also slow, we have the root cause. Before
ringing on DS people doors, see if for example DNS is not slow and
there are no DNS timeouts in play - "host ipa.server.test" will
tell you that

- If DS is OK, try Kerberos - kinit, kvno commands

- If Kerberos is also OK and "ipa-replica-manage list" is still
slow, maybe we should just "strace" it to see what it waits on.

HTH, Martin


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVey+3AAoJEJFMz73A1+zruo8P/13JTUKxgSKUchH/2UQWH94N
EAPj3hhgNeMjY1TCgjAhceavidXTj5oCbt3D2wSiZwxAodurXy1PkCmQUs9NpZ+N
3uKPD01tSnIl/eocP8aNHNrPfn5W7xijffbpaQsnNCgn5DMvLG0b8sEDKA2A9TQi
qhluvjMrWM4yOITc4A2+IWCASy1UfG0fRBuK+hHp+F72at6Q6luEiaxC4TymSF7L
f7XomuQmaEnvYl44hlqnyh/9FaERGyFs5crKTrLpFeLPrk149HYHwFqCbd28SY3p
QLSQxraLnSvT/7y2d9kc7vmJFvxEFC/q4Q05xL81u/Sg691lb0qX0SVuHfFST87I
xSypfQ3110wUzk7X4+oXpPX/ziomsXkjELhi81iurdU/iA9bAqtuEYf8HtvcrF7b
QlqZA0t1D78QDTbaNOIE6LVAY2Zxkpdhu/qwCMvtS8TlPGt9U8Kt4U6eoFfTFn8C
GFx61vNfBFmqOQX7w0Q36jqUCQG0VRipsC0oeqGVEeUvIDW/G9TG4m8O+vmZ60Lj
DgpIoxwXaO4TT5aZcDDpIlgs67ZxaW+9VAmJh+G3w664rQ3jnE6JMwzyxDmqFhZ5
cto0910Y5GqWL9wShmpTBy1/nVAJivdXK4D6eykOgKq80vXKbZOWPqIT2oEqXSA0
rYUBJPLWtHHVLigc6lW7
=R7vN
-END PGP 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

Re: [Freeipa-users] FreeIPA web UI Freezing up

[Rich Megginson]

On 06/08/2015 01:19 PM, nat...@nathanpeters.com wrote:

==
um WTF?  making it a one way only agreement invalidates the
lastinitstart
value?
==

Looks like a bug.

Ok, this is a pretty serious bug if making it one way can knock it offline
permanently.  Where should I file this bug report?


https://fedorahosted.org/freeipa/newticket




ipa-replica-manage re-initialize?




That seemed to work.  I would have tried that already but the command does
not indicate that is a valid option.  Running ipa-replica-manage --help
does not even list re-initialize as a valid option.  See output below.


That looks like a bug too.   However, the man page gives much more 
information, including the re-initialize command.




[root@dc1 slapd-IPADOMAIN-NET]# ipa-replica-manage re-initialize
Directory Manager password:

re-initialize requires the option --from 
[root@dc1 slapd-IPADOMAIN-NET]# ipa-replica-manage --help
Usage: ipa-replica-manage [options]

Options:
   --version show program's version number and exit
   -h, --helpshow this help message and exit
   -H HOST, --host=HOST  starting host
   -p DIRMAN_PASSWD, --password=DIRMAN_PASSWD
 Directory Manager password
   -v, --verbose provide additional information
   -f, --force   ignore some types of errors
   -c, --cleanup DANGER: clean up references to a ghost master
   --binddn=BINDDN   Bind DN to use with remote server
   --bindpw=BINDPW   Password for Bind DN to use with remote server
   --winsync This is a Windows Sync Agreement
   --cacert=CACERT   Full path and filename of CA certificate to use with
 TLS/SSL to the remote server
   --win-subtree=WIN_SUBTREE
 DN of Windows subtree containing the users you
want to
 sync (default cn=Users,ldap://dc1.ipadomain.net:389} 553fe9c9
  0004 5575e79e0004
nsds50ruv: {replica 3 ldap://dc2.ipadomain.net:389} 553fe9c
  40003 557244db00170003
nsruvReplicaLastModified: {replica 4 ldap://dc1.ipadomain.ne
  t:389} 5575e704
nsruvReplicaLastModified: {replica 3 ldap://dc2.ipadomain.n
  et:389} 
oneWaySync: fromWindows
nsds5ReplicaEnabled: on
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20150608191201Z
nsds5replicaLastUpdateEnd: 20150608191201Z
nsds5replicaChangesSentSinceStartup:: NDo0My8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
upd
  ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20150608191038Z
nsds5replicaLastInitEnd: 20150608191109Z
nsds5replicaLastInitStatus: 0 Total update succeeded




--
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 web UI Freezing up

[Rich Megginson]

On 06/08/2015 01:09 PM, nat...@nathanpeters.com wrote:

[root@dc1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config
objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
  \2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
  RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
  0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ2k0N0NxRGZFd2JIdm
  I0MFVFZVI3MA==}gWI9NIB8lbt9tmNszzbBFCAe4Vs/e0sMyn5+NZPJg9E=
nsds7DirsyncCookie::
TVNEUwMAAAC1t/mKGaLQAQAAYAEAAKlEoQAAA
  ACpRKEAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
  13PwAADGzFNzznrESIxHzA74fbs9WwMAAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
  PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+zVCIgAA4qTQaC46/Ua4KXgP
  /ixNcRvjVAAAWowbgYD1akibZ+sCul5C4ZxlLQAAxSO4iapVmEGQ6R23bgLQi6lEoQAAA
  AAAogC6jFcyFUmhBp4B7FkaBRklnQEAyhKMxsP0uUKGEnG2lsyA8eTUwgYA4n8Xx1bAlU
  mBUl3zhlZ9WBngDAAA71vM2ebFEkCJkBaLjB4CGU+4CQMAGfO+4ndZCkaVKnwZNlNsf90
  NDAAAgD6n+M2bcUGkOwo5gPLx7IOjAwAA
nsds50ruv: {replicageneration} 553fe9bb0004
nsds50ruv: {replica 4 ldap://dc1.ipadomain.net:389} 553fe9c9
  0004 5575dff80004
nsds50ruv: {replica 3 ldap://dc2.ipadomain.net:389} 553fe9c
  40003 557244db00170003
nsruvReplicaLastModified: {replica 4 ldap://dc1.ipadomain.ne
  t:389} 5575df5e
nsruvReplicaLastModified: {replica 3 ldap://dc1.ipadomain.n
  et:389} 
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20150608183216Z
nsds5replicaLastUpdateEnd: 20150608183216Z
nsds5replicaChangesSentSinceStartup:: NDozMC8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
upd
  ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0

=
hmmm, problem still exists and not sure how to fix it
=



This is also really strange, when I run an ipactl restart I get the
following weird stuff in my log.  messages about ACL targets not existing


Not sure about this.


and a strange kerberos error where the host can't find it's own keytab or
ldap service record?


See below.



[08/Jun/2015:19:04:06 +] - 389-Directory/1.3.3.8 B2015.040.128
starting up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING -- Minimum cache size is 512000 --
rounding up
[08/Jun/2015:19:04:06 +] - WARNING: userRoot: entry cache size 512000B
is less than db size 12500992B; We recommend to increase the entry cache
size nsslapd-cachememsize.
[08/Jun/2015:19:04:06 +] - WARNING: ipaca: entry cache size 512000B is
less than db size 1343488B; We recommend to increase the entry cache size
nsslapd-cachememsize.
[08/Jun/2015:19:04:06 +] - WARNING: changelog: entry cache size
512000B is less than db size 45654016B; We recommend to increase the entry
cache size nsslapd-cachememsize.
[08/Jun/2015:19:04:06 +] - resizing db cache size: 40 -> 32
[08/Jun/2015:19:04:06 +] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=ipadomain,dc=net
[08/Jun/2015:19:04:08 +] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=ipadomain,dc=net does not exist
[08/Jun/2015:19:04:08 +] NSACLPlugin - The ACL target
cn=computers,cn=compat,dc=ipadomain,dc=net does not exist
[08/Jun/2015:19:04:08 +] NSACLPlugin - The ACL target
cn=ng,cn=compat,dc=ipadomain,dc=net does not exist
[08/Jun/2015:19:04:08 +] NSACLPlugin - The ACL target
ou=sudoers,dc=ipadomain,dc=net does not exist
[08/Jun/

Re: [Freeipa-users] FreeIPA web UI Freezing up

[Rich Megginson]

On 06/08/2015 12:49 PM, nat...@nathanpeters.com wrote:

On 06/08/2015 10:18 AM, nat...@nathanpeters.com wrote:
This looks like incremental update is successful . . .


nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0

. . . but this indicates that the sync agreement has never been
initialized, which would also correspond to the errors below.  I'm
really puzzled as to how sync could possibly work if it has never been
initialized.  And I'm also not sure how you could have created the sync
agreement using the IPA command line tools without initializing the
agreement.  AFAIK, the only way to get rid of the errors is to
reinitialize http://linux.die.net/man/1/ipa-replica-manage

OK, more troubleshooting and I think I discovered the problem.  Making the
sync agreement into a one way sync from windows to ipa seems to break the
agreement by uninitializing it?  Not sure how to fix this, but here is the
logs to prove that is the step that is breaking it.


try to create sync agreement


[root@dc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=freeipa
syncuser,ou=Service Account,dc=office,dc=addomain,dc=net" --bindpw
 --passsync  --cacert /etc/openldap/cacerts/addomain.cer
officedc2.office.addomain.net --win-subtree
"OU=Staff,DC=office,DC=addomain,DC=net" -v
Directory Manager password:

winsync agreement already exists on subtree
OU=Staff,DC=office,DC=addomain,DC=net

=
failed because it already existed so disconnect
=

[root@dc1 ~]# ipa-replica-manage disconnect officedc2.office.addomain.net
Directory Manager password:

Deleted replication agreement from 'dc1.ipadomain.net' to
'officedc2.office.addomain.net'


try to create sync agreement


[root@dc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=freeipa
syncuser,ou=Service Account,dc=office,dc=addomain,dc=net" --bindpw
a5Ryj2N4EAvjFLJelWOQ --passsync MVQXHEturhjqoFXGvUcH --cacert
/etc/openldap/cacerts/addomain.cer officedc2.office.addomain.net
--win-subtree "OU=Staff,DC=office,DC=addomain,DC=net" -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addomain.cer to certificate
database for dc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=office,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update started: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
Update in progress, 57 seconds elapsed
Update succeeded

Connected 'dc1.ipadomain.net' to 'officedc2.office.addomain.net'

=
confirm that init values are non zero
=

[root@dc1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
[root@dc1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config
objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
  \2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
  RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
  0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ2k0N0NxRGZFd2JIdm
  I0MFVFZVI3MA==}gWI9NIB8lbt9tmNszzbBFCAe4Vs/e0sMyn5+NZPJg9E=
nsds7DirsyncCookie::
TVNEUwMAAADdp7tcGKLQAQAAYAEAAAVEoQAAA
  AAFRKEAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
  13PwAADGzFNzznrESIxHzA74fbs72tMAAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
  PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+9xBIgAA4qTQaC46/Ua4KXgP
  /ixNcdrfVAAAWowbgYD1akibZ+sCul5C4e9kLQAAxSO4ia

Re: [Freeipa-users] FreeIPA web UI Freezing up

[Rich Megginson]

On 06/08/2015 10:18 AM, nat...@nathanpeters.com wrote:

Is it possible this is an old winsync agreement that is no longer
valid?

I have only ever made a single winsync agreement on this server that I
know of.  How would I tell if an agreement is no longer valid?



ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config
objectclass=nsDSWindowsReplicationAgreement



The output of that command seems to indicate that the replication
agreement is valid and active?

[root@dc1 sbin]# ldapsearch -xLLL -D "cn=directory manager" -W -b
cn=config objectclass=nsDSWindowsReplicationAgreement
Enter LDAP Password:
dn: cn=meToofficedc2.office.addomain.net,cn=replica,cn=dc\3Dipadomain
  \2Cdc\3Dnet,cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: OU=Staff,DC=office,DC=addomain,DC=net
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=ipadomain,dc=net
cn: meToofficedc2.office.addomain.net
nsds7NewWinGroupSyncEnabled: false
objectClass: nsDSWindowsReplicationAgreement
objectClass: top
nsDS5ReplicaTransportInfo: TLS
description: me to officedc2.office.addomain.net
nsDS5ReplicaRoot: dc=ipadomain,dc=net
nsDS5ReplicaHost: officedc2.office.addomain.net
nsds5replicaTimeout: 120
nsDS5ReplicaBindDN: cn=freeipa syncuser,ou=Service
Account,dc=office,dc=addomain,dc=net
nsds7NewWinUserSyncEnabled: true
nsDS5ReplicaPort: 389
nsds7WindowsDomain: ipadomain.net
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
idnssoaserial
   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaCredentials:
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
  RERBNEJDUmtOelUzTTJJNVlpMDBaV1EyTTJRMQ0KWXkwNU0yTm1aV05sTVMxbU5qRXpaak5oTlFBQ
  0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQlo1VnlCSTY1Yzl5cl
  Z0cWlCc0hDdQ==}ReODwX5Q7vLGjmdGX57pmrLWKFF61dPc5SzPhk3RnIM=
nsds7DirsyncCookie::
TVNEUwMAAACTPfpcG5fQAQAAYAEAAKU8n
  AClPJwAAMUjuImqVZhBkOkdt24C0IsBAA4AY4GwFkVcvEmMMExrVon4d6
  13PwAADGzFNzznrESIxHzA74fbs0lWIQAAOnFoO5OE2E27lR/g4EcjQTLbIwAAuEm
  PWjYok0qGS0HM/+TDmK7FgAMA6PTFXvAdnkaJSIkZT1lS+4cAIQAA4qTQaC46/Ua4KXgP
  /ixNcerDRgAAWowbgYD1akibZ+sCul5C4dgsKwAAxSO4iapVmEGQ6R23bgLQi6U8n
  AAAogC6jFcyFUmhBp4B7FkaBWPPjAEAyhKMxsP0uUKGEnG2lsyA8eTUwgYA4n8Xx1bAlU
  mBUl3zhlZ9WBngDAAA71vM2ebFEkCJkBaLjB4CGU+4CQMAGfO+4ndZCkaVKnwZNlNsf90
  NDAAAgD6n+M2bcUGkOwo5gPLx7IOjAwAA
oneWaySync: fromWindows
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20150608161149Z
nsds5replicaLastUpdateEnd: 20150608161149Z
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
upd
  ate started


This looks like incremental update is successful . . .


nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0


. . . but this indicates that the sync agreement has never been 
initialized, which would also correspond to the errors below.  I'm 
really puzzled as to how sync could possibly work if it has never been 
initialized.  And I'm also not sure how you could have created the sync 
agreement using the IPA command line tools without initializing the 
agreement.  AFAIK, the only way to get rid of the errors is to 
reinitialize http://linux.die.net/man/1/ipa-replica-manage





However, my logs are still full of the following entry:

[08/Jun/2015:15:50:15 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:18 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:21 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:24 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:27 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:30 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:33 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:37 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToofficedc2.office.addomain.net" (officedc2:389): Replica has
no update vector. It has never been initialized.
[08/Jun/2015:15:50:40 +] NSMMReplicationPlugin - windows sync -
agmt="cn=

Re: [Freeipa-users] FreeIPA web UI Freezing up

[Rich Megginson]

On 06/08/2015 10:02 AM, nat...@nathanpeters.com wrote:

On 06/05/2015 03:31 PM, nat...@nathanpeters.com wrote:

I have noticed that happen a couple times in the last few days.
FreeIPA
server 4.1.3 on CentOS 7 with a sync relationship to a Windows server
2008R2 domain controller.

The web ui will stop working and just show a blank page.

When I try to do a ipactl status the command just freezes and does
nothing.

In the exmaple I paste below, there was 5 minutes between when I
entered
the command and when I did ctrl-c after getting tired of waiting for
nothing to happen.
After the ipactl command failed to work at all, I decided to restart
the
httpd service manually, and then saw a whole pile of strange errors
around
failing to bind to ldap server and generic kerberos errors.

Rebooting the server seems to work for 24 hours or so until things go
wonky again.

[username@dc1 ~]$ sudo su -
Last login: Fri Jun  5 16:05:55 UTC 2015 on pts/0
[root@dc1 ~]# ipactl status
^CCancelled.
[root@dc1 ~]# ipactl restart
^CCancelled.
[root@dc1 ~]# ipactl restart
^CCancelled.
[root@dc1 ~]# systemctl restart httpd
[root@dc1 ~]#


Jun 05 21:02:32 dc1.mydomain.net systemd[1]: Stopping The Apache HTTP
Server...
Jun 05 21:03:01 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:01 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Created slice
user-0.slice.
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Starting Session 161 of
user
root.
Jun 05 21:03:19 dc1.mydomain.net systemd-logind[604]: New session 161
of
user root.
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Started Session 161 of
user
root.
Jun 05 21:03:19 dc1.mydomain.net login[614]: pam_unix(login:session):
session opened for user root by LOGIN(uid=0)
Jun 05 21:03:19 dc1.mydomain.net login[614]: ROOT LOGIN ON tty1
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:03:22.932855,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:43 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:03:43.935800,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:03:43 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:03:46 dc1.mydomain.net smbd[2208]: GSSAPI client step 1
Jun 05 21:03:46 dc1.mydomain.net smbd[2208]: GSSAPI client step 1
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: httpd.service stopping
timed
out. Killing.
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: httpd.service: main
process
exited, code=killed, status=9/KILL
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Unit httpd.service entered
failed state.
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Starting The Apache HTTP
Server...
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Started The Apache HTTP
Server.
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05
21:04:07.152666,
0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05
21:04:07.152995,
0] ../source3/lib/smbldap.c:998(smbldap_connect_system)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: failed to bind to server
ldapi://%2fvar%2frun%2fslapd-MYDOMAIN-NET.socket with dn="[Anonymous
bind]" Error: Local error
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: (unknown)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05
21:04:07.153407,
0]
../source3/rpc_server/netlogon/srv_netlog_nt.c:975(_netr_ServerAuthenticate3)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: _netr_ServerAuthenticate3:
failed to get machine password for account office.mydomain.net.:
NT_STATUS_NONE_MAPPED
Jun 05 21:08:02 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:02 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:08:23.034001,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1

I also got this error from the web ui after restarting httpd:

Runtime error

Web UI got in unrecoverable state during "metadata" phase


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


Further information : restarting the httpd service didn't help, but
restarting the dirsrv service allowed me to once again login to the
webui
and the ipactl command started working again after the restart of
dirsrv.

Is there something I can loo

Re: [Freeipa-users] FreeIPA web UI Freezing up

[Rich Megginson]

On 06/05/2015 03:31 PM, nat...@nathanpeters.com wrote:

I have noticed that happen a couple times in the last few days.  FreeIPA
server 4.1.3 on CentOS 7 with a sync relationship to a Windows server
2008R2 domain controller.

The web ui will stop working and just show a blank page.

When I try to do a ipactl status the command just freezes and does
nothing.

In the exmaple I paste below, there was 5 minutes between when I entered
the command and when I did ctrl-c after getting tired of waiting for
nothing to happen.
After the ipactl command failed to work at all, I decided to restart the
httpd service manually, and then saw a whole pile of strange errors around
failing to bind to ldap server and generic kerberos errors.

Rebooting the server seems to work for 24 hours or so until things go
wonky again.

[username@dc1 ~]$ sudo su -
Last login: Fri Jun  5 16:05:55 UTC 2015 on pts/0
[root@dc1 ~]# ipactl status
^CCancelled.
[root@dc1 ~]# ipactl restart
^CCancelled.
[root@dc1 ~]# ipactl restart
^CCancelled.
[root@dc1 ~]# systemctl restart httpd
[root@dc1 ~]#


Jun 05 21:02:32 dc1.mydomain.net systemd[1]: Stopping The Apache HTTP
Server...
Jun 05 21:03:01 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:01 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Created slice user-0.slice.
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Starting Session 161 of user
root.
Jun 05 21:03:19 dc1.mydomain.net systemd-logind[604]: New session 161 of
user root.
Jun 05 21:03:19 dc1.mydomain.net systemd[1]: Started Session 161 of user
root.
Jun 05 21:03:19 dc1.mydomain.net login[614]: pam_unix(login:session):
session opened for user root by LOGIN(uid=0)
Jun 05 21:03:19 dc1.mydomain.net login[614]: ROOT LOGIN ON tty1
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:03:22.932855,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:22 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:03:43 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:03:43.935800,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:03:43 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:03:46 dc1.mydomain.net smbd[2208]: GSSAPI client step 1
Jun 05 21:03:46 dc1.mydomain.net smbd[2208]: GSSAPI client step 1
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: httpd.service stopping timed
out. Killing.
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: httpd.service: main process
exited, code=killed, status=9/KILL
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Unit httpd.service entered
failed state.
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Starting The Apache HTTP
Server...
Jun 05 21:04:02 dc1.mydomain.net systemd[1]: Started The Apache HTTP
Server.
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05 21:04:07.152666,
0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05 21:04:07.152995,
0] ../source3/lib/smbldap.c:998(smbldap_connect_system)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: failed to bind to server
ldapi://%2fvar%2frun%2fslapd-MYDOMAIN-NET.socket with dn="[Anonymous
bind]" Error: Local error
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: (unknown)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: [2015/06/05 21:04:07.153407,
0]
../source3/rpc_server/netlogon/srv_netlog_nt.c:975(_netr_ServerAuthenticate3)
Jun 05 21:04:07 dc1.mydomain.net smbd[2208]: _netr_ServerAuthenticate3:
failed to get machine password for account office.mydomain.net.:
NT_STATUS_NONE_MAPPED
Jun 05 21:08:02 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:02 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: [2015/06/05
21:08:23.034001,  0] ipa_sam.c:4144(bind_callback_cleanup)
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: kerberos error:
code=-1765328324, message=Generic error (see e-text)
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1
Jun 05 21:08:23 dc1.mydomain.net winbindd[2171]: GSSAPI client step 1

I also got this error from the web ui after restarting httpd:

Runtime error

Web UI got in unrecoverable state during "metadata" phase


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


Further information : restarting the httpd service didn't help, but
restarting the dirsrv service allowed me to once again login to the webui
and the ipactl command started working again after the restart of dirsrv.

Is there something I can look for in my logs next time this happens. I
have a feeli

Re: [Freeipa-users] ns-slapd started crashing suddenly

[Rich Megginson]

On 06/05/2015 03:40 AM, Dawid Rabiega wrote:

Hi,
One of my ipa server on fedora 19 since yesterday started to crash, 
with following message to dmesg:


$ dmesg | tail -n 20
[6706148.291648] ns-slapd[3212]: segfault at 0 ip 7f6fc9a84421 sp 
7f6f8f7eb928 error 4 in libc-2.17.so 
[7f6fc99fe000+1b6000]
[6706170.887926] ns-slapd[3359]: segfault at 0 ip 7f923ce89421 sp 
7f91fd7e7928 error 4 in libc-2.17.so 
[7f923ce03000+1b6000]
[6706264.491787] ns-slapd[3463]: segfault at 0 ip 7f2d9020d421 sp 
7f2d527e9928 error 4 in libc-2.17.so 
[7f2d90187000+1b6000]
[6706311.092133] ns-slapd[4015]: segfault at 0 ip 7f62287d7421 sp 
7f61efff4928 error 4 in libc-2.17.so 
[7f6228751000+1b6000]
[6706500.581441] ns-slapd[4361]: segfault at 0 ip 7facbe1e1421 sp 
7fac807e5928 error 4 in libc-2.17.so 
[7facbe15b000+1b6000]
[6706690.693958] ns-slapd[4932]: segfault at 0 ip 7f8d72cbc421 sp 
7f8d3d7f7928 error 4 in libc-2.17.so 
[7f8d72c36000+1b6000]
[6715473.156094] ns-slapd[18406]: segfault at 0 ip 7f22fedea421 sp 
7f22c1fe8928 error 4 in libc-2.17.so 
[7f22fed64000+1b6000]
[6716455.653949] ns-slapd[20571]: segfault at 0 ip 7f190695e421 sp 
7f18dcff6928 error 4 in libc-2.17.so 
[7f19068d8000+1b6000]
[6716646.006961] ns-slapd[21375]: segfault at 0 ip 7ffb9c889421 sp 
7ffb64ff6928 error 4 in libc-2.17.so 
[7ffb9c803000+1b6000]
[6717027.574362] ns-slapd[22082]: segfault at 0 ip 7f9fdbda7421 sp 
7f9faeffa928 error 4 in libc-2.17.so 
[7f9fdbd21000+1b6000]
[6751004.788596] ns-slapd[9779]: segfault at 0 ip 7f0398f48421 sp 
7f03617f7928 error 4 in libc-2.17.so 
[7f0398ec2000+1b6000]
[6751019.360517] ns-slapd[10018]: segfault at 0 ip 7f267852c421 sp 
7f263afea928 error 4 in libc-2.17.so 
[7f26784a6000+1b6000]
[6751154.258362] ns-slapd[10179]: segfault at 0 ip 7f2c6d854421 sp 
7f2c31ff0928 error 4 in libc-2.17.so 
[7f2c6d7ce000+1b6000]
[6751208.966127] ns-slapd[10520]: segfault at 0 ip 7f9a31a59421 sp 
7f99f87ed928 error 4 in libc-2.17.so 
[7f9a319d3000+1b6000]
[6751305.469969] ns-slapd[10608]: segfault at 0 ip 7f6e9348b421 sp 
7f6e55ff0928 error 4 in libc-2.17.so 
[7f6e93405000+1b6000]
[6751328.997404] ns-slapd[10736]: segfault at 0 ip 7f8c936b1421 sp 
7f8c5d7f7928 error 4 in libc-2.17.so 
[7f8c9362b000+1b6000]
[6751432.356753] ns-slapd[10835]: segfault at 0 ip 7f7dffd84421 sp 
7f7dca7f9928 error 4 in libc-2.17.so 
[7f7dffcfe000+1b6000]
[6751454.826551] ns-slapd[11107]: segfault at 0 ip 7f03621d5421 sp 
7f0326fea928 error 4 in libc-2.17.so 
[7f036214f000+1b6000]
[6751549.459424] ns-slapd[11414]: segfault at 0 ip 7f9e0f74b421 sp 
7f9dd2fea928 error 4 in libc-2.17.so 
[7f9e0f6c5000+1b6000]
[6751573.611284] ns-slapd[11567]: segfault at 0 ip 7f044fd73421 sp 
7f0419ff8928 error 4 in libc-2.17.so 
[7f044fced000+1b6000]


$ rpm -qa | grep 389
389-ds-base-1.3.1.22-1.fc19.x86_64
389-ds-base-libs-1.3.1.22-1.fc19.x86_

$ rpm -qa | grep ipa
libipa_hbac-python-1.11.5.1-1.fc19.x86_64
sssd-ipa-1.11.5.1-1.fc19.x86_64
freeipa-client-3.3.5-1.fc19.x86_64
freeipa-admintools-3.3.5-1.fc19.x86_64
freeipa-server-3.3.5-1.fc19.x86_64
python-iniparse-0.4-7.fc19.noarch
libipa_hbac-1.11.5.1-1.fc19.x86_64
freeipa-python-3.3.5-1.fc19.x86_64

I have no idea what happened, and what check next. Any idea?


We'll need to get a core, and see a good stacktrace from the core. 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

Since this is IPA, you'll need to

# debuginfo-install 389-ds-base ipa-server slapi-nis




Best Regards,
Dawid




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

[Rich Megginson]

On 05/25/2015 12:24 AM, Martin Kosek wrote:

On 05/25/2015 12:45 AM, Bill Graboyes wrote:

Hi List,

I have been digging around on this system that hung for the past hour or two
trying to figure out why dirserv seemed to be hung.  It was not using
resources, nor was there any information in any of the log files (dirserv,
sssd, etc), it was just stopped.  I was unable to run ipactl and get any
response.  The server would not even reboot cleanly (I had to power it off).
Of note that there didn't seem to be any problems with systems accessing via
sssd, but systems that were accessing via direct ldap connections, the
connection would just hang.

OS and Version information:
CentOS Linux release 7.1.1503 (Core)
ipa-server-4.1.0-18.el7.centos.3.x86_64

Hello,

I would suggesting starting with providing the information asked for in the 389
DS FAQ:

http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs

Martin


For IPA, you will also need to do: debuginfo-install ipa-server slapi-nis

--
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] replication again :-(

[Rich Megginson]

On 05/21/2015 06:25 AM, Janelle wrote:

On 5/21/15 5:20 AM, thierry bordaz wrote:

Hello Janelle,

Those 3 RIDs were already present in Node dc2-ipa1, correct ? They 
reappeared on others nodes as well ?
May be ds2-ipa1 established a replication session with its peers and 
send those RIDs.
Could you track in all the access logs, when the op 
csn=5552f71800030017 was applied.


Note that the two hexa values of replica 23 changed 
(5545d61f00020017 5552f71800030017 vs 5553e3a30017 
555432430017). Have you recreated a replica 23 ?.


Do you have replication logging enabled ?

thanks
thierry
Just to help me -- what is the best way to enable the logging level 
you need?


http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting
The Replication log level.

I thought I did it correctly adding to ldif.dse, but I don't think it 
took.


You cannot edit dse.ldif while the server is running.  Anyway, 
ldapmodify is the best way to set this value.


I am used to OpenLDAP, so perhaps there is a different way to do it 
with 389-ds. Can you suggest settings of logging you want me to use?



The Replication log level.


~Janelle



--
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] confused by ldapsearch results

[Rich Megginson]

On 05/19/2015 01:53 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote:


I don’t understand what is happening…

If I use a compound OR filter to search for “cn” or “uid”, I only get 
back the match for uid. I expect to get both. If I add a search for a 
nonexistent attribute like “name”, I get nothing back. I expect to get 
back the entry matched by the other term.


# l "(cn=gboyce)" dn

dn: cn=gboyce,cn=groups,cn=accounts,dc=…

# l "(uid=gboyce)" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(uid=gboyce)(cn=gboyce))" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(cn=gboyce)(uid=gboyce))" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(uid=gboyce)(name=gboyce))" dn

#



Does this give an error message or does ldapsearch exit with a non-zero 
value?  Can you check the dirsrv access log to see what is the result of 
this operation?


This is on a new deployment of ipa on centos, with just a couple of 
test records. I don’t have much recent experience with LDAP, but I 
don’t see what I’m doing wrong. Dirsrv on centos 6.5 works as expected.


# ipa --version

VERSION: 4.1.0, API_VERSION: 2.112

# cat /etc/centos-release

CentOS Linux release 7.1.1503 (Core)

George Boyce, SAIC/NICS

GCC Systems Support

NASA GSFC Code 762





-- 
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] getting rid of nsds5ReplConflict

[Rich Megginson]

On 05/19/2015 12:27 PM, Megan . wrote:

Thank you for the reply.  I think I just got frustrated.  I
uninstalled ipa on the dir2 replica then set it back up again as a
replica.  Everything seems to be replicating just fine without errors
now.  I know that this isn't the preferred or documented solution but
i needed the server back online asap.

When i run "ipa-replica-manage list-ruv" i see dir2 listed twice.  Is
this a concern?


No.  When you get a chance, you can remove the one that is no longer 
used with the documented clean ruv procedure.  I believe there is an ipa 
command for that.




[root@dir1 ipa]# ipa-replica-manage list-ruv
dir1.example.com:389: 4
dir3.example.com:389: 5
dir2.example.com:389: 6
dir2.example.com:389: 8

On Tue, May 19, 2015 at 12:37 PM, Rich Megginson  wrote:

On 05/19/2015 10:10 AM, Megan . wrote:

I'm struggling with a replication conflict.  I had three masters,
dir1, dir2, dir3.  There were some weird issues with dir2 where I was
getting  "error 49 (Invalid credentials)" without any real
information.


Where did you see this?  command line output?  Of what command?  In a log
file?  Which log file?  Can you post the exact error message along with the
context?


When i did " ipa-replica-manage list-ruv" i saw dir2
twice.


Can you post the output?


I couldn't get it straight


What does "get it straight" mean?  Does it mean you ran some commands?  If
so, what commands did you run and what was the result?


so i decided to try to re-create
the replica.  I disconnected the replica, ran the del for the replica.
When i check for replication conflicts i still see it in there and I
can't seem to get it to go away.


Deleting and recreating the replica will not remove the replication conflict
if the conflict has been replicated to other servers.

This document doesn't say anything about resolving replica conflict entries
by deleting and re-adding replicas:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


It only shows up on one of the
remaining masters.

I was trying to follow the documentation


The link above?


and use ldapmodify to change
the dn to cn=olddir2.somewhere.example.something.com7475d90c but
everything i seem to be trying doesn't work.


What exactly did you do?


I'm assuming this entry needs to be cleared up before i can
successfully setup dir2 again as a replica.


No, not necessarily.



Any help would be greatly appreciated.

Thanks!


[root@dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b
"dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \*
nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: nsds5ReplConflict=*
# requesting: * nsds5ReplConflict
#

# dir2.somewhere.example.something.com +
7475d90c-f34911e4-99a0ab24-58022cdf, masters
   , ipa, etc, somewhere.example.something.com
dn:
cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802

2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com
nsds5ReplConflict: namingConflict
cn=dir2.somewhere.example.something.com,cn=masters,c
   n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com
objectClass: top
objectClass: nsContainer
cn: dir2.somewhere.example.something.com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


--
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] getting rid of nsds5ReplConflict

[Rich Megginson]

On 05/19/2015 10:10 AM, Megan . wrote:

I'm struggling with a replication conflict.  I had three masters,
dir1, dir2, dir3.  There were some weird issues with dir2 where I was
getting  "error 49 (Invalid credentials)" without any real
information.


Where did you see this?  command line output?  Of what command?  In a 
log file?  Which log file?  Can you post the exact error message along 
with the context?



When i did " ipa-replica-manage list-ruv" i saw dir2
twice.


Can you post the output?


I couldn't get it straight


What does "get it straight" mean?  Does it mean you ran some commands?  
If so, what commands did you run and what was the result?



so i decided to try to re-create
the replica.  I disconnected the replica, ran the del for the replica.
When i check for replication conflicts i still see it in there and I
can't seem to get it to go away.


Deleting and recreating the replica will not remove the replication 
conflict if the conflict has been replicated to other servers.


This document doesn't say anything about resolving replica conflict 
entries by deleting and re-adding replicas:

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


It only shows up on one of the
remaining masters.

I was trying to follow the documentation


The link above?


and use ldapmodify to change
the dn to cn=olddir2.somewhere.example.something.com7475d90c but
everything i seem to be trying doesn't work.


What exactly did you do?



I'm assuming this entry needs to be cleared up before i can
successfully setup dir2 again as a replica.


No, not necessarily.



Any help would be greatly appreciated.

Thanks!


[root@dir1 ~]# ldapsearch -x -D "cn=directory manager" -W -b
"dc=somewhere,dc=example,dc=something,dc=com" "nsds5ReplConflict=*" \*
nsds5ReplConflict
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: nsds5ReplConflict=*
# requesting: * nsds5ReplConflict
#

# dir2.somewhere.example.something.com +
7475d90c-f34911e4-99a0ab24-58022cdf, masters
  , ipa, etc, somewhere.example.something.com
dn: 
cn=dir2.somewhere.example.something.com+nsuniqueid=7475d90c-f34911e4-99a0ab24-5802
  2cdf,cn=masters,cn=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com
nsds5ReplConflict: namingConflict
cn=dir2.somewhere.example.something.com,cn=masters,c
  n=ipa,cn=etc,dc=somewhere,dc=example,dc=something,dc=com
objectClass: top
objectClass: nsContainer
cn: dir2.somewhere.example.something.com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



--
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] Securing IPA Redux

[Rich Megginson]

On 05/18/2015 08:26 AM, Martin Kosek wrote:

Adding freeipa-users list back, to keep others in the loop.

On 05/18/2015 12:32 PM, Brian Topping wrote:

Thanks for taking the time to write that, Martin. It's good to have a reference 
to build from.

Result of "ida-client-install" outside the firewall with port 636 accessible:

Ah, I mostly just use 636 as a convenience port to show the supported cryptos,
389 is really the port we should be using by default.

Of course, 389 port + STARTTLS environment turned on, to make sure passwords do
not go in clean over the wire.


Please make sure the following ports are opened in the firewall settings:
  TCP: 80, 88, 389
  UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly 
after enrollment:
  TCP: 464
  UDP: 464, 123 (if NTP enabled)

No mention of 636, confirmed by tcpdump that it's not trying. Also no option on 
command line to specify 636.

Opening up 389 means that some misconfigured client could expose passwords.


Not necessarily.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/SecureConnections.html#requiring-secure-connections


It's possible to remove null ciphers, but then there's really no reason not to 
use 636.

Seems like ipa-client-install should try 636 by default, then fall back to 389 
in it's various forms, no?

I think the general direction here was the opposite. To work on the port 389 as
the common denominator, offering both password-less traffic and encrypted
traffic. I am not sure if there were other reasons too, I would let Rob or
Ludwig reply here if they know.

Martin


On May 18, 2015, at 4:10 PM, Martin Kosek  wrote:

On 05/15/2015 01:33 PM, Brian Topping wrote:

In the (apparently) first message to the list in 2014, 
https://www.redhat.com/archives/freeipa-users/2014-January/msg0.html 
 
addressed questions about securing IPA and I don't see much other talk about it. Now 
that 4.x is prevalent, I wanted to bring it up again.

This is the default by design. However, note that in FreeIPA 4.0+ you can
change that default (permission-mod) and let users or some of the user
attributes be only shown for authenticated users.

https://www.freeipa.org/page/V4/Permissions_V2

So, from my POV, this is not a flaw.


I'd like my installation to be allow hardened machines (i.e. in the cloud with encrypted 
filesystems) to be a part of the domain. I believe this means that I need to expose 
Kerberos and LDAP to the world, since the machines could live anywhere. I don't believe I 
need to worry about KRB5, but I am concerned about 389-DS since it seems somewhat difficult 
to force TLS (https://blog.routedlogic.net/?p=119 
) and maybe that's a bad idea under IPA for 
reasons I thought I'd ask here about. Last year's thread also referenced 
https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html 

 and I thought I would check to see if that's still necessary under 4.x.

389-DS and TLS should be also fixed, since FreeIPA 4.1 (RHEL/CentOS 7.1):

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

This is an nmap test against the FreeIPA public demo (4.1.x):

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-18 11:08 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.19s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
| compressors:
|   NULL
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 6.19 seconds


Setting up the firewall to allow cloud networks in is always an option, but if 
I can get a secure IPA setup going, it would also allow road warriors to kinit 
and use their credentials for configured intranet sites without having to turn 
on the VPN (which can really slow things down from remote parts of the globe).

BTW, if you are concerned about exposed Kerberos traffic, FreeIPA 4.2 plans to
offer Kerberos-over-HTTP functionality by default:
https://fedorahosted.org/freeipa/ticket/4801

Even now, it can be manually configured. This is what GNOME used:
https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/

So, if I am reading my notes correctly, there should be no blockers in using
FreeIPA in your

Re: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/16/2015 04:06 PM, Nathan Peters wrote:

I have updated the bug report you filed below.

The issue was that the instructions would only work in Windows Server 
2003 because My Network Places was removed in 2008 and above.  Since 
the manual clearly states that the AD sync is to be performed with 
server 2008 / 2012 only it made no sense to give instructions for an 
incompatible version of windows.


I have added to the ticket 2 methods to get the *correct* certificate 
that will work in both server 2008 r2 and server 2012 r2.


I am cc'd on the bug and have seen all of the information you added.  
Thanks!




On 05/15/2015 03:09 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to
certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become 
ready .

.
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - 
LDAP

error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ
-h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b 
"cn=Users,dc=test,dc=mycompany,dc=net"

"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer ldapsearch 
-xLLL

-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b 
"cn=Users,dc=test,dc=mycompany,dc=net"

"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally 
gave a

bad password or username.

Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting

Ok, that helped a lot.  I got this fixed now.  Because the manual tells
you to export the cert using a way that doesn't work on newer 
versions of

windows, I tried to improvise and my first attempt exported the wrong
cert.

The correct way is to go to mmc.exe and add the certificates snap-in.
Then go to personal certificates store for the machine account and 
export

the one that has -CA at the end of it in the issued to column.

Now that the correct certificate was exported, replication 
succeeded.  The

docs should be updated though to reflect the proper way to export.


https://bugzilla.redhat.com/show_bug.cgi?id=1222161

Please add yourself to the bug and provide any additional information.


--
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] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/15/2015 03:09 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to
certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready .
.
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ
-h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer  ldapsearch -xLLL
-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally gave a
bad password or username.

Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting

Ok, that helped a lot.  I got this fixed now.  Because the manual tells
you to export the cert using a way that doesn't work on newer versions of
windows, I tried to improvise and my first attempt exported the wrong
cert.

The correct way is to go to mmc.exe and add the certificates snap-in.
Then go to personal certificates store for the machine account and export
the one that has -CA at the end of it in the issued to column.

Now that the correct certificate was exported, replication succeeded.  The
docs should be updated though to reflect the proper way to export.


https://bugzilla.redhat.com/show_bug.cgi?id=1222161

Please add yourself to the bug and provide any additional information.

--
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] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/15/2015 03:09 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to
certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready .
.
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ
-h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer  ldapsearch -xLLL
-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally gave a
bad password or username.

Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting

Ok, that helped a lot.  I got this fixed now.  Because the manual tells
you to export the cert using a way that doesn't work on newer versions of
windows, I tried to improvise and my first attempt exported the wrong
cert.

The correct way is to go to mmc.exe and add the certificates snap-in.
Then go to personal certificates store for the machine account and export
the one that has -CA at the end of it in the issued to column.

Now that the correct certificate was exported, replication succeeded.  The
docs should be updated though to reflect the proper way to export.



I will file a doc bug.  What version of Windows are you using that does 
not have the correct instructions?



--
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] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/15/2015 02:44 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to
certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready .
.
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ
-h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer  ldapsearch -xLLL
-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally gave a
bad password or username.

Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting


After doing that and poking around in
/var/log/dirsrv/slapd-IPADOMAIN-NET/errors I found this :

[15/May/2015:20:27:17 +] slapi_ldap_bind - Error: could not send
startTLS request: error -11 (Connect error) errno 0 (Success)
[15/May/2015:20:27:17 +] NSMMReplicationPlugin - windows sync -
agmt="cn=meToaddc2.test.mycompany.net" (addc2:389): Replication bind with
SIMPLE auth failed: LDAP error -11 (Connect error) (TLS error -8179:Peer's
Certificate issuer is not recognized.)

So it's complaining that it doesn't recognize the certificate that was
signed by my AD certificate authority as suggested in here :
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req

I copied the certificate


Which certificate?  The CA cert or the server cert?  You need the CA 
cert, not the server cert.



to my server though and created the hashes just
like the manual said.


"created the hashes"?  There is nothing in

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/Setting_up_Active_Directory.html#ad-ca-req

about creating any hashes.



The only issue I had was the directions here :
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/managing-sync-agmt.html
tell you to go to my network places but that didn't exist on my server.  I
did it through start menu -> administrative tools -> certification
authority.  The rest of double clicking on the cert and going to the
details tab and copy to file was the same though.


Was it the CA cert or the server cert?  You need the CA cert, not the 
server cert.




So how do I get FreeIPA to not choke up on the self signed cert?



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

Re: [Freeipa-users] more replication issues

[Rich Megginson]

On 05/15/2015 09:53 AM, Janelle wrote:

On May 15, 2015, at 08:57, Ludwig Krispenz  wrote:



On 05/15/2015 02:45 PM, Janelle wrote:

On 5/15/15 3:30 AM, Ludwig Krispenz wrote:


On 05/13/2015 06:34 PM, Janelle wrote:

On 5/13/15 9:13 AM, Rich Megginson wrote:

On 05/13/2015 10:04 AM, Janelle wrote:

On 5/13/15 8:49 AM, Rich Megginson wrote:

On 05/13/2015 09:40 AM, Janelle wrote:
Recently I started seeing these crop up across my servers:

slapi_ldap_bind - Error: could not bind id [cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success)

Does that entry exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b 
"cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"

Does the parent exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base -b 
"ou=csusers,cn=config"

I am finding that there does seem to be a relation to the above error and a 
possible CSN issue:

Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.

I guess what concerns me is what could be causing this. We don't do a lot of 
changes all the time.

And in answer to the question above - we seem to have last the agreement 
somehow:

No such object (32)


Is there a DEL operation in the access log for "cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"?

maybe something like

# grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication Manager"


nope -- none of the servers have it.

your original message is very clear:

could not bind id [cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success)

this means that you have replication agreement wth SIMPLE auth which uses a
nsDS5ReplicaBindDN: cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config

which does not exist on the target server of the agreement. Now you say it was 
never deleted, so it was probably never added, but used in the replication 
agreements. How do you manage and setup replication agreements ?


All replicas are configred simply:

ipa-replica-prepare hostname...
scp ..
ipa-replica-install --no-ntp --setup-ca Replica-file

That is it. NTP is not set because internal NTP servers are used. All replicas 
are CA replicas for safety (no certs are managed)

ok, I was a bit puzzled because ipa uses ldapprincipals and gssapi for the main 
suffix replication.
But I just verified that after ipa-replica-install --setup-ca CA replication is 
setup with users in ou=csusers,cn=config and uses it as replica binddn, I have 
no idea why it would disappear.

when Rich asked to search for a DEL, did you check this on the server that logged the 
message or on the endpoint of the replication agreement (it should be there), and you 
may have to check in the rotated access logs access. as well

Checked it on ALL servers just to be sure.

~J



If it is present at some point, then is missing, it must be some 
internal operation that is removing it.  Please enable access logging of 
internal operations:


ldapmodify -x -h consumer.host -D "cn=directory manager" -w "password" <Is or was the server ipa01.example.com the target of a host delete, 
replica delete, or cleanallruv operation?


--
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 05/15/2015 08:46 AM, James James wrote:

[root@ipa ~]#  rpm -q 389-ds-base
389-ds-base-1.2.11.15-50.el6_6.x86_64


Ok.  Looks like this is planned to be fixed in RHEL 6.7 with version 
389-ds-base-1.2.11.15-56.el6


I don't know if there are any workarounds.





2015-05-15 16:32 GMT+02:00 Rich Megginson <mailto:rmegg...@redhat.com>>:


On 05/15/2015 08:22 AM, James James wrote:

I think that :

Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress


looks like a time error :
https://fedorahosted.org/freeipa/ticket/4756


That issue should have been fixed in 389-ds-base-1.3.3 branch. 
What version of 389-ds-base? rpm -q 389-ds-base





2015-05-15 16:00 GMT+02:00 Rich Megginson mailto:rmegg...@redhat.com>>:

On 05/15/2015 07:55 AM, James James wrote:

Is it possible to change the nsds5ReplicaTimeout value to
get rid of this timeout error ?


What timeout error?



2015-04-17 4:52 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>>:

On 04/15/2015 10:44 PM, James James wrote:

The ipareplica-install.log file in attachment ...


Here are the pertinent bits:

2015-04-15T15:06:31Z DEBUG wait_for_open_ports:
localhost [389] timeout 300
2015-04-15T15:06:32Z DEBUG flushing
ldap://ipa.example.com:389 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for
SchemaCache url=ldap://ipa.example.com:389
conn=
2015-04-15T15:06:32Z DEBUG flushing
ldaps://ipa1.example.com:636 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for
SchemaCache url=ldaps://ipa1.example.com:636
conn=
2015-04-15T15:08:44Z DEBUG Traceback (most recent call
last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 382, in start_creation
run_step(full_msg, method)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 372, in run_step
method()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 368, in __setup_replica
r_bindpw=self.dm_password)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 969, in setup_replication
raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

2015-04-15T15:08:44Z DEBUG   [error] RuntimeError:
Failed to start replication

The times are a little off, but I believe this
corresponds to
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import
complete.  Processed 1539 entries in 126 seconds. (12.21
entries/sec)
[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica
dc=lix,dc=polytechnique,dc=fr is coming online; enabling
replication

I don't know why setup_replication is reporting an error
if replication completed successfully.




2015-04-16 2:22 GMT+02:00 Rob Crittenden
mailto:rcrit...@redhat.com>>:

Rich Megginson wrote:
> On 04/15/2015 02:58 PM, James James wrote:
>> Nothing on the replica .. maybye a process on
the master. How can I
>> check that ?
>
> I have no idea.  But it seems highly unlikely
that a process on the
> master is able to shutdown a process on the
replica . . .
>
> I would say that there is some problem with the
ipa-replica-install not
> properly checking the status - see below:
>
>>
>> 2015-04-15 21:37 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>> <mailto:rmegg...@redhat.com
<mailto:rmegg...@redhat.com>>>:
>>
    >> On 04/15/2015 12:43 PM, James James wrote:
>>>  Here the log
>>>
>>>  2015-04-15 18:58 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>>><mailto:rmegg...@redhat.com
<mailto:rmegg...@redhat.com>>>:
>&g

Re: [Freeipa-users] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 05/15/2015 08:22 AM, James James wrote:

I think that :

Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress


looks like a time error : https://fedorahosted.org/freeipa/ticket/4756


That issue should have been fixed in 389-ds-base-1.3.3 branch.  What 
version of 389-ds-base?  rpm -q 389-ds-base




2015-05-15 16:00 GMT+02:00 Rich Megginson <mailto:rmegg...@redhat.com>>:


On 05/15/2015 07:55 AM, James James wrote:

Is it possible to change the nsds5ReplicaTimeout value to get rid
of this timeout error ?


What timeout error?



2015-04-17 4:52 GMT+02:00 Rich Megginson mailto:rmegg...@redhat.com>>:

On 04/15/2015 10:44 PM, James James wrote:

The ipareplica-install.log file in attachment ...


Here are the pertinent bits:

2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost
[389] timeout 300
2015-04-15T15:06:32Z DEBUG flushing
ldap://ipa.example.com:389 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa.example.com:389
conn=
2015-04-15T15:06:32Z DEBUG flushing
ldaps://ipa1.example.com:636 from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache
url=ldaps://ipa1.example.com:636
conn=
2015-04-15T15:08:44Z DEBUG Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 382, in start_creation
run_step(full_msg, method)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 372, in run_step
method()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 368, in __setup_replica
r_bindpw=self.dm_password)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 969, in setup_replication
raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

2015-04-15T15:08:44Z DEBUG   [error] RuntimeError: Failed to
start replication

The times are a little off, but I believe this corresponds to
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import
complete.  Processed 1539 entries in 126 seconds. (12.21
entries/sec)
[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica
dc=lix,dc=polytechnique,dc=fr is coming online; enabling
replication

I don't know why setup_replication is reporting an error if
replication completed successfully.




2015-04-16 2:22 GMT+02:00 Rob Crittenden
mailto:rcrit...@redhat.com>>:

Rich Megginson wrote:
> On 04/15/2015 02:58 PM, James James wrote:
>> Nothing on the replica .. maybye a process on the
master. How can I
>> check that ?
>
> I have no idea.  But it seems highly unlikely that a
process on the
> master is able to shutdown a process on the replica . . .
>
> I would say that there is some problem with the
ipa-replica-install not
> properly checking the status - see below:
>
>>
>> 2015-04-15 21:37 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>> <mailto:rmegg...@redhat.com
<mailto:rmegg...@redhat.com>>>:
>>
    >> On 04/15/2015 12:43 PM, James James wrote:
>>> Here the log
>>>
>>> 2015-04-15 18:58 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>>>  <mailto:rmegg...@redhat.com
<mailto:rmegg...@redhat.com>>>:
>>>
>>> On 04/15/2015 09:46 AM, James James wrote:
>>>>  Hello,
>>>>
>>>> I have been looking to solve my problem but
I 'm asking for
>>>> some help.
>>>>
>>>> The replication begins but cannot be
completed 
>>>>
>>>> I want to install a new fresh replica but
I've always got
>>>> this error :
>>>>
>>>>  [21/35]: configure dirsrv ccache
>>>>  [22/35]: enable SASL ma

Re: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/14/2015 11:33 PM, nat...@nathanpeters.com wrote:

[root@ipadc1 cacerts]# ipa-replica-manage connect --winsync --binddn
"cn=ad sync,cn=Users,dc=test,dc=mycompany,dc=net" --bindpw
supersecretpassword --passsync supersecretpassword --cacert
/etc/openldap/cacerts/addc2-test.cer addc2.test.mycompany.net -v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc2-test.cer to certificate
database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=test,DC=mycompany,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . .
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Have you tried using ldapsearch to verify the connection?

# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM ldapsearch -xLLL -ZZ -h
addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"

and/or

# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer  ldapsearch -xLLL
-ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w
"supersecretpassword" -s base -b "cn=Users,dc=test,dc=mycompany,dc=net"
"objectclass=*"


Both commands give the same successful result.  I don't think it's a
problem with the credentials because I was able to generate different
error messages during the attempted sync setup if I intentionally gave a
bad password or username.


Ok.  Have you tried enabling the replication log level?

http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting


Here is what happens when I run the above
commands :

[root@ipadc1 cacerts]# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN-COM
ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s
base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*"
dn: cn=Users,dc=test,dc=mycompany,dc=net
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net
instanceType: 4
whenCreated: 20150515024307.0Z
whenChanged: 20150515024307.0Z
uSNCreated: 5696
uSNChanged: 5696
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: V9KaoufynkWbJpSo2PjxiA==
systemFlags: -1946157056
objectCategory:
CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net
isCriticalSystemObject: TRUE
dSCorePropagationData: 20150515025646.0Z
dSCorePropagationData: 1601010101.0Z

[root@ipadc1 cacerts]# LDAPTLS_CACERT=/etc/openldap/cacerts/addc2-test.cer
ldapsearch -xLLL -ZZ -h addc2.test.mycompany.net -D "cn=ad
sync,cn=Users,dc=test,dc=mycompany,dc=net" -w "supersecretpassword" -s
base -b "cn=Users,dc=test,dc=mycompany,dc=net" "objectclass=*"
dn: cn=Users,dc=test,dc=mycompany,dc=net
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=test,DC=mycompany,DC=net
instanceType: 4
whenCreated: 20150515024307.0Z
whenChanged: 20150515024307.0Z
uSNCreated: 5696
uSNChanged: 5696
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: V9KaoufynkWbJpSo2PjxiA==
systemFlags: -1946157056
objectCategory:
CN=Container,CN=Schema,CN=Configuration,DC=test,DC=mycompany,DC=net
isCriticalSystemObject: TRUE
dSCorePropagationData: 20150515025646.0Z
dSCorePropagationData: 1601010101.0Z




--
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 05/15/2015 07:55 AM, James James wrote:
Is it possible to change the nsds5ReplicaTimeout value to get rid of 
this timeout error ?


What timeout error?



2015-04-17 4:52 GMT+02:00 Rich Megginson <mailto:rmegg...@redhat.com>>:


On 04/15/2015 10:44 PM, James James wrote:

The ipareplica-install.log file in attachment ...


Here are the pertinent bits:

2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389]
timeout 300
2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389
from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache
url=ldap://ipa.example.com:389
conn=
2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636
from SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache
url=ldaps://ipa1.example.com:636
conn=
2015-04-15T15:08:44Z DEBUG Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 382, in start_creation
run_step(full_msg, method)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 372, in run_step
method()
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line
368, in __setup_replica
r_bindpw=self.dm_password)
  File
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 969, in setup_replication
raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

2015-04-15T15:08:44Z DEBUG   [error] RuntimeError: Failed to start
replication

The times are a little off, but I believe this corresponds to
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. 
Processed 1539 entries in 126 seconds. (12.21 entries/sec)

[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr
is coming online; enabling replication

I don't know why setup_replication is reporting an error if
replication completed successfully.




2015-04-16 2:22 GMT+02:00 Rob Crittenden mailto:rcrit...@redhat.com>>:

Rich Megginson wrote:
> On 04/15/2015 02:58 PM, James James wrote:
>> Nothing on the replica .. maybye a process on the master.
How can I
>> check that ?
>
> I have no idea.  But it seems highly unlikely that a
process on the
> master is able to shutdown a process on the replica . . .
>
> I would say that there is some problem with the
ipa-replica-install not
> properly checking the status - see below:
>
>>
>> 2015-04-15 21:37 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>> <mailto:rmegg...@redhat.com <mailto:rmegg...@redhat.com>>>:
>>
>> On 04/15/2015 12:43 PM, James James wrote:
>>> Here the log
>>>
>>> 2015-04-15 18:58 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>>> <mailto:rmegg...@redhat.com
<mailto:rmegg...@redhat.com>>>:
>>>
>>> On 04/15/2015 09:46 AM, James James wrote:
>>>> Hello,
>>>>
>>>> I have been looking to solve my problem but I 'm
asking for
>>>> some help.
>>>>
>>>> The replication begins but cannot be completed 
>>>>
>>>> I want to install a new fresh replica but I've
always got
>>>> this error :
>>>>
>>>> [21/35]: configure dirsrv ccache
>>>>   [22/35]: enable SASL mapping fallback
>>>>   [23/35]: restarting directory server
>>>>   [24/35]: setting up initial replication
>>>> Starting replication, please wait until this has
completed.
>>>> Update in progress, 127 seconds elapsed
>>>> Update in progress yet not in progress
>>>>
>>>> Update in progress yet not in progress
>>>
>
> in progress yet not in progress The error log below
clearly shows
> that replica init succeeded after 127 seconds.
>
> IPA-ers - wasn't there some bug about checking replica
status properly?
>

The loop looks at nsds5BeginReplica

Re: [Freeipa-users] Replication Update in progress : FALSE LDAP ERROR

[Rich Megginson]

On 05/14/2015 05:43 PM, nat...@nathanpeters.com wrote:

On 05/14/2015 04:58 AM, nat...@nathanpeters.com wrote:

I have tried to setup synchronization between a FreeIPA domain and an AD
domain.  The certificates are in the right place.

[root@ipadc1 ~]# ipa-replica-manage connect --winsync --binddn "cn=sync
user,cn=Users,dc=datacenter,dc=addomain,dc=net" --bindpw secretpassword
--passsync secretpassword --cacert
/etc/openldap/cacerts/addc1-datacenter.cer addc1.datacenter.addomain.net
-v
Directory Manager password:

Added CA certificate /etc/openldap/cacerts/addc1-datacenter.cer to
certificate database for ipadc1.ipadomain.net
ipa: INFO: AD Suffix is: DC=datacenter,DC=addomain,DC=net
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net
Windows PassSync system account exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . .
.
ipa: INFO: Replication Update in progress: FALSE: status: -11  - LDAP
error: Connect error: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.

[ipadc1.ipadomain.net] reports: Update failed! Status: [-11  - LDAP
error:
Connect error]

Failed to start replication


This is the system journal while the failure is happening

May 14 02:50:39 ipadc1.ipadomain.net systemd[1]: Stopping 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: LDAP error:
Can't
contact LDAP server: ldap_sync_poll() failed
May 14 02:50:41 ipadc1.ipadomain.net named-pkcs11[5594]: ldap_syncrepl
will reconnect in 60 seconds
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ipa
:
ERRORsyncrepl_poll: LDAP error ({'desc': "Can't contact LDAP
server"})
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: Traceback
(most recent call last):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
"/usr/libexec/ipa/ipa-dnskeysyncd", line 106, in 
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: while
ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
"/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 349, in
syncrepl_poll
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]:
add_intermediates=1, add_ctrls=1, all = 0
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 483, in
result4
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: ldap_result
=
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: File
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 106, in
_ldap_call
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: result =
func(*args,**kwargs)
May 14 02:50:41 ipadc1.ipadomain.net ipa-dnskeysyncd[3163]: SERVER_DOWN:
{'desc': "Can't contact LDAP server"}
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]:
ipa-dnskeysyncd.service:
main process exited, code=exited, status=1/FAILURE
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Unit
ipa-dnskeysyncd.service entered failed state.
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Stopped 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Starting 389 Directory
Server IPADOMAIN-NET
May 14 02:50:41 ipadc1.ipadomain.net systemd[1]: Started 389 Directory
Server IPADOMAIN-NET..
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] SSL Initialization - Configured SSL version range: min: TLS1.0,
max: TLS1.2
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: Configured NSS Ciphers
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:
enabled
May 14 02:50:41 ipadc1.ipadomain.net ns-slapd[3268]:
[14/May/2015:02:50:41
+] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_

Re: [Freeipa-users] more replication issues

[Rich Megginson]

On 05/13/2015 10:34 AM, Janelle wrote:

On 5/13/15 9:13 AM, Rich Megginson wrote:

On 05/13/2015 10:04 AM, Janelle wrote:

On 5/13/15 8:49 AM, Rich Megginson wrote:

On 05/13/2015 09:40 AM, Janelle wrote:

Recently I started seeing these crop up across my servers:

slapi_ldap_bind - Error: could not bind id [cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication 
mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success)


Does that entry exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s 
base -b "cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"


Does the parent exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s 
base -b "ou=csusers,cn=config"


I am finding that there does seem to be a relation to the above 
error and a possible CSN issue:


Can't locate CSN 555131e500020019 in the changelog (DB 
rc=-30988). If replication stops, the consumer may need to be 
reinitialized.


I guess what concerns me is what could be causing this. We don't do 
a lot of changes all the time.


And in answer to the question above - we seem to have last the 
agreement somehow:


No such object (32)



Is there a DEL operation in the access log for "cn=Replication 
Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"?


maybe something like

# grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication 
Manager"



nope -- none of the servers have it.



Either there is some internal op that is deleting it, or there is a bug 
that is causing it to be removed.


To see what internal operation could be doing this, you could enable 
internal access logging:

ldapmodify -x -h consumer.host -D "cn=directory manager" -w "password" <Is or was the server ipa01.example.com the target of a host delete, 
replica delete, or cleanallruv operation?


--
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] more replication issues

[Rich Megginson]

On 05/13/2015 10:04 AM, Janelle wrote:

On 5/13/15 8:49 AM, Rich Megginson wrote:

On 05/13/2015 09:40 AM, Janelle wrote:

Recently I started seeing these crop up across my servers:

slapi_ldap_bind - Error: could not bind id [cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)


Does that entry exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s 
base -b "cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"


Does the parent exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s 
base -b "ou=csusers,cn=config"


I am finding that there does seem to be a relation to the above error 
and a possible CSN issue:


Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). 
If replication stops, the consumer may need to be reinitialized.


I guess what concerns me is what could be causing this. We don't do a 
lot of changes all the time.


And in answer to the question above - we seem to have last the 
agreement somehow:


No such object (32)



Is there a DEL operation in the access log for "cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"?


maybe something like

# grep DEL /var/log/dirsrv/slapd-INST/access|grep -i "Replication Manager"



results from the first ldapsearch.

however, the parent is there:
dn: ou=csusers,cn=config
objectClass: top
objectClass: organizationalUnit
ou: csusers




--
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] more replication issues

[Rich Megginson]

On 05/13/2015 09:40 AM, Janelle wrote:

Recently I started seeing these crop up across my servers:

slapi_ldap_bind - Error: could not bind id [cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)


Does that entry exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base 
-b "cn=Replication Manager 
masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config"


Does the parent exist?

ldapsearch -xLLL -h consumer.host -D "cn=directory manager" -W -s base 
-b "ou=csusers,cn=config"




more and more and more. When it happens, I have to re-initialize from 
one of the good servers and go around in a circle (I have replication 
in a ring, as shown in documentation examples).  The list-ruv on every 
server matches. And yet, out of 18 masters, thisis occuring now on 
about half of them.


Once again I am beginning to question the robustness of 389-ds and the 
replication problems that many of us continue to report. How do we get 
this to be more solid? I love this product. It really is something 
that RH can push, but it really needs to be rock solid and with all 
the replication issues, well, it seems like it is not commercially ready?


Any ideas/thoughts/comments?

thank you
Janelle



--
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] Known issues with IPA on VM?

[Rich Megginson]

On 05/06/2015 12:25 AM, Martin Kosek wrote:

On 05/06/2015 07:48 AM, Christoph Kaminski wrote:

Hi

we have some undefinably problems here with IPA inside a VM (rhev/kvm). We
has often zombie processes (defunct) with certmonger and dirsrv and
segfaults (dmesg)... We have 8 IPA servers, 4 Hardware and 4 VM's with
same Install (rhel7.1). We see these problems only on the VM's. Is there
something already known about such problems?

(The VM's have ever 4 CPU's and 2GB RAM, we have circa 120 Users/Groups)

I do not recall any specific VM problems in particular (maybe except that NTPD
does not work too well in VMs), so I would recommend checking for the real
reasons of crash. Maybe there are some useful errors in the DS/certmonger log
files.

If not, seeing the stack trace of the crash would help us/dirsrv developers
identify the problem:

http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes


For IPA, to get full stacktraces, you will also need to do this:

# debuginfo-install ipa-server slapi-nis

--
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] default e-mail address and aliases from LDAP

[Rich Megginson]

On 04/27/2015 07:49 AM, Ivars Strazdiņš wrote:

Hi there,
I am preparing to move our site e-mail authentication backend to 
FreeIPA. That is, integrate Postfix with FreeIPA.

Let's suppose user has two or more e-mail addresses,
j...@site.com 
joe.u...@site.com 

Currently we use smtp_generic_maps on Postfix side to ensure that mail 
always leaves site as joe.u...@site.com 


Is there a way to ensure in FreeIPA that user's default address is 
joe.u...@site.com  so that Postfix could do 
a smtp_generic_maps lookup in LDAP server and get the default address?


And another question - is it possible to maintain e-mail aliases in 
FreeIPA? Say, to expand address l...@site.com 
 to users j...@site.com , 
j...@site.com  and m...@site.com 
?

Any suggestions are welcome, I am just beginning to work with LDAP.


I myself don't know.  However, there are some email howto's on the 389 
site: http://www.port389.org/docs/389ds/tech-docs.html#mail


Hopefully someone with actual experience integrating Postfix and LDAP 
will chime in on this thread.  If not, try the 
389-us...@lists.fedoraproject.org list - there are some email server 
operators there.




Thanks for you time and kind regards,
Ivars





-- 
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 04/15/2015 10:44 PM, James James wrote:

The ipareplica-install.log file in attachment ...


Here are the pertinent bits:

2015-04-15T15:06:31Z DEBUG wait_for_open_ports: localhost [389] timeout 300
2015-04-15T15:06:32Z DEBUG flushing ldap://ipa.example.com:389 from 
SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache 
url=ldap://ipa.example.com:389 conn=instance at 0x484f4d0>
2015-04-15T15:06:32Z DEBUG flushing ldaps://ipa1.example.com:636 from 
SchemaCache
2015-04-15T15:06:32Z DEBUG retrieving schema for SchemaCache 
url=ldaps://ipa1.example.com:636 conn=instance at 0x4170290>

2015-04-15T15:08:44Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 382, in start_creation

run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 
line 372, in run_step

method()
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
368, in __setup_replica

r_bindpw=self.dm_password)
  File 
"/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", 
line 969, in setup_replication

raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication

2015-04-15T15:08:44Z DEBUG   [error] RuntimeError: Failed to start 
replication


The times are a little off, but I believe this corresponds to
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. 
Processed 1539 entries in 126 seconds. (12.21 entries/sec)
[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is 
coming online; enabling replication


I don't know why setup_replication is reporting an error if replication 
completed successfully.




2015-04-16 2:22 GMT+02:00 Rob Crittenden <mailto:rcrit...@redhat.com>>:


Rich Megginson wrote:
> On 04/15/2015 02:58 PM, James James wrote:
>> Nothing on the replica .. maybye a process on the master. How can I
>> check that ?
>
> I have no idea.  But it seems highly unlikely that a process on the
> master is able to shutdown a process on the replica . . .
>
> I would say that there is some problem with the
ipa-replica-install not
> properly checking the status - see below:
>
>>
>> 2015-04-15 21:37 GMT+02:00 Rich Megginson mailto:rmegg...@redhat.com>
>> <mailto:rmegg...@redhat.com <mailto:rmegg...@redhat.com>>>:
>>
>> On 04/15/2015 12:43 PM, James James wrote:
>>> Here the log
>>>
>>> 2015-04-15 18:58 GMT+02:00 Rich Megginson
mailto:rmegg...@redhat.com>
>>> <mailto:rmegg...@redhat.com <mailto:rmegg...@redhat.com>>>:
>>>
>>> On 04/15/2015 09:46 AM, James James wrote:
>>>> Hello,
>>>>
>>>> I have been looking to solve my problem but I 'm
asking for
>>>> some help.
>>>>
>>>> The replication begins but cannot be completed 
>>>>
>>>> I want to install a new fresh replica but I've always got
>>>> this error :
>>>>
>>>> [21/35]: configure dirsrv ccache
>>>>   [22/35]: enable SASL mapping fallback
>>>>   [23/35]: restarting directory server
>>>>   [24/35]: setting up initial replication
>>>> Starting replication, please wait until this has
completed.
>>>> Update in progress, 127 seconds elapsed
>>>> Update in progress yet not in progress
>>>>
>>>> Update in progress yet not in progress
>>>
>
> in progress yet not in progress  The error log below clearly
shows
> that replica init succeeded after 127 seconds.
>
> IPA-ers - wasn't there some bug about checking replica status
properly?
>

The loop looks at nsds5BeginReplicaRefresh,
nsds5replicaUpdateInProgress
and nsds5ReplicaLastInitStatus.

It loops looking for nsds5BeginReplicaRefresh. If there is no value it
prints "Update in progress, %d seconds elapsed". Once it gets a
status,
the update is done, and it looks at nsds5ReplicaLastInitStatus. If it
isn't empty, doesn't include 'replica busy' or 'Total update
succeeded'
then it looks to see if nsds5replicaUpdateInProgress is TRUE. If
it is,
ir prints Update in progress yet not in progress and tries the
loop again.

AFAICT this part of a replica install doesn't restart 389-ds.

/var/log/ipareplica-install.log may hold some details.

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] Errors in dirsrv logs

[Rich Megginson]

On 04/16/2015 01:52 AM, Alexander Frolushkin wrote:


Hello again.

Now, in addition to

connection - conn= fd=xxx Incoming BER Element was too long, max 
allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute 
in cn=config to increase.


messages, we have on six of our 16 servers

NSMMReplicationPlugin - changelog program - 
agmt="cn=meTonw-rhidm01.unix.ad.com" (nw-rhidm01:389): CSN 
552de186000b0011 not found, we aren't as up to date, or we purged


Maybe it begins to generate this error after one of our masters was 
re-initialized.


Is there any way to fix it without complete replicas reinstallation?



Not that I know of.

What version of 389-ds-base is this?  rpm -q 389-ds-base


WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764




Информация в этом сообщении предназначена исключительно для конкретных 
лиц, которым она адресована. В сообщении может содержаться 
конфиденциальная информация, которая не может быть раскрыта или 
использована кем-либо, кроме адресатов. Если вы не адресат этого 
сообщения, то использование, переадресация, копирование или 
распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, 
незамедлительно сообщите отправителю об этом и удалите со всем 
содержимым само сообщение и любые возможные его копии и приложения.


The information contained in this communication is intended solely for 
the use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally 
privileged information. The contents may not be disclosed or used by 
anyone other than the addressee. If you are not the intended 
recipient(s), any use, disclosure, copying, distribution or any action 
taken or omitted to be taken in reliance on it is prohibited and may 
be unlawful. If you have received this communication in error please 
notify us immediately by responding to this email and then delete the 
e-mail and all attachments and any copies thereof.


(c)20mf50




-- 
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 04/15/2015 02:58 PM, James James wrote:
Nothing on the replica .. maybye a process on the master. How can I 
check that ?


I have no idea.  But it seems highly unlikely that a process on the 
master is able to shutdown a process on the replica . . .


I would say that there is some problem with the ipa-replica-install not 
properly checking the status - see below:




2015-04-15 21:37 GMT+02:00 Rich Megginson <mailto:rmegg...@redhat.com>>:


On 04/15/2015 12:43 PM, James James wrote:

Here the log

2015-04-15 18:58 GMT+02:00 Rich Megginson mailto:rmegg...@redhat.com>>:

On 04/15/2015 09:46 AM, James James wrote:

Hello,

I have been looking to solve my problem but I 'm asking for
some help.

The replication begins but cannot be completed 

I want to install a new fresh replica but I've always got
this error :

[21/35]: configure dirsrv ccache
  [22/35]: enable SASL mapping fallback
  [23/35]: restarting directory server
  [24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress

Update in progress yet not in progress




in progress yet not in progress  The error log below clearly shows 
that replica init succeeded after 127 seconds.


IPA-ers - wasn't there some bug about checking replica status properly?



[ipa.example.com <http://ipa.example.com>] reports: Update
failed! Status: [10 Total update abortedLDAP error: Referral]

  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin -
CleanAllRUV Task: Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com <http://meToipa1.example.com>"
(ipa1:389): Replica has a different generation ID than the
local data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin -
Beginning total update of replica
"agmt="cn=meToipa1.example.com
<http://meToipa1.example.com>" (ipa1:389)".


What is happening on the consumer (ipa1.example.com
<http://ipa1.example.com>) error and access log at this time?



[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr
is going offline; disabling replication
[15/Apr/2015:17:06:33 +0200] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to
access the database
[15/Apr/2015:17:06:53 +0200] - import userRoot: Processed 1399
entries -- average rate 70.0/sec, recent rate 69.9/sec, hit ratio 0%
...
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. 
Processed 1539 entries in 126 seconds. (12.21 entries/sec)

[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr
is coming online; enabling replication

So it would appear that initialization finished successfully.  But
then . . .




[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com <http://meToipa1.example.com>"
(ipa1:389): Unable to receive the response for a
startReplication extended operation to consumer (Can't
contact LDAP server). Will retry later.




[15/Apr/2015:17:41:16 +0200] - slapd shutting down - freed 1 work
q stack objects - freed 2 op stack objects
[15/Apr/2015:17:41:16 +0200] - slapd stopped.

So the server is down.  Did someone or some process shutdown the
replica at this time?


[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could
not send startTLS request: error -1 (Can't contact LDAP
server) errno 107 (Transport endpoint is not connected)

Any hints will be useful.

Thanks.






--
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 04/15/2015 12:43 PM, James James wrote:

Here the log

2015-04-15 18:58 GMT+02:00 Rich Megginson <mailto:rmegg...@redhat.com>>:


On 04/15/2015 09:46 AM, James James wrote:

Hello,

I have been looking to solve my problem but I 'm asking for some
help.

The replication begins but cannot be completed 

I want to install a new fresh replica but I've always got this
error :

[21/35]: configure dirsrv ccache
  [22/35]: enable SASL mapping fallback
  [23/35]: restarting directory server
  [24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress

Update in progress yet not in progress

[ipa.example.com <http://ipa.example.com>] reports: Update
failed! Status: [10 Total update abortedLDAP error: Referral]

  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin - CleanAllRUV
Task: Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com <http://meToipa1.example.com>"
(ipa1:389): Replica has a different generation ID than the local
data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - Beginning
total update of replica "agmt="cn=meToipa1.example.com
<http://meToipa1.example.com>" (ipa1:389)".


What is happening on the consumer (ipa1.example.com
<http://ipa1.example.com>) error and access log at this time?



[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is 
going offline; disabling replication
[15/Apr/2015:17:06:33 +0200] - WARNING: Import is running with 
nsslapd-db-private-import-mem on; No other process is allowed to access 
the database
[15/Apr/2015:17:06:53 +0200] - import userRoot: Processed 1399 entries 
-- average rate 70.0/sec, recent rate 69.9/sec, hit ratio 0%

...
[15/Apr/2015:17:08:39 +0200] - import userRoot: Import complete. 
Processed 1539 entries in 126 seconds. (12.21 entries/sec)
[15/Apr/2015:17:08:39 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica dc=lix,dc=polytechnique,dc=fr is 
coming online; enabling replication


So it would appear that initialization finished successfully.  But then 
. . .





[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa1.example.com <http://meToipa1.example.com>"
(ipa1:389): Unable to receive the response for a startReplication
extended operation to consumer (Can't contact LDAP server). Will
retry later.




[15/Apr/2015:17:41:16 +0200] - slapd shutting down - freed 1 work q 
stack objects - freed 2 op stack objects

[15/Apr/2015:17:41:16 +0200] - slapd stopped.

So the server is down.  Did someone or some process shutdown the replica 
at this time?



[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could not
send startTLS request: error -1 (Can't contact LDAP server) errno
107 (Transport endpoint is not connected)

Any hints will be useful.

Thanks.






--
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] Replication seems to begin but failed after 127 seconds ...

[Rich Megginson]

On 04/15/2015 09:46 AM, James James wrote:

Hello,

I have been looking to solve my problem but I 'm asking for some help.

The replication begins but cannot be completed 

I want to install a new fresh replica but I've always got this error :

[21/35]: configure dirsrv ccache
  [22/35]: enable SASL mapping fallback
  [23/35]: restarting directory server
  [24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 127 seconds elapsed
Update in progress yet not in progress

Update in progress yet not in progress

[ipa.example.com ] reports: Update failed! 
Status: [10 Total update abortedLDAP error: Referral]


  [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication


On the master I have this message :
15/Apr/2015:15:57:37 +0200] NSMMReplicationPlugin - CleanAllRUV Task: 
Successfully cleaned rid(19).
[15/Apr/2015:17:06:32 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa1.example.com " 
(ipa1:389): Replica has a different generation ID than the local data.
[15/Apr/2015:17:06:33 +0200] NSMMReplicationPlugin - Beginning total 
update of replica "agmt="cn=meToipa1.example.com 
" (ipa1:389)".


What is happening on the consumer (ipa1.example.com) error and access 
log at this time?


[15/Apr/2015:17:41:25 +0200] NSMMReplicationPlugin - 
agmt="cn=meToipa1.example.com " 
(ipa1:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.
[15/Apr/2015:17:41:29 +0200] slapi_ldap_bind - Error: could not send 
startTLS request: error -1 (Can't contact LDAP server) errno 107 
(Transport endpoint is not connected)


Any hints will be useful.

Thanks.





-- 
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] Slow user logon with IPA

[Rich Megginson]

On 04/14/2015 12:35 PM, thierry bordaz wrote:

On 04/14/2015 05:36 PM, Mateusz Malek wrote:



On Fri, Apr 10, 2015 at 08:48 PM, Jakub Hrozek wrote:

On Fri, Apr 10, 2015 at 12:39:20PM -0400, Dmitri Pal wrote:

On 04/10/2015 08:13 AM, Mateusz Malek wrote:
I'm about to migrate my OpenLDAP-based environment to FreeIPA, 
however
I've hit some weird performance problems. When I'm using IPA, it 
takes
about 5-7 (or even more) seconds to get shell prompt after 
entering user

password (...)

(...)
Do authentication and see where the time is spent by examining the 
logs.

Correlate it to the logs on the server. (...)

I spent the better part of today fixing this issue:
 https://fedorahosted.org/sssd/ticket/2624

You might want to check if you're hit by this bug by setting:
 selinux_provider=none
temporarily.


With selinux_provider=none things seems faster.

It's still not as fast as with existing OpenLDAP, but logon times 
seem acceptable now (they mostly vary from 0.5 to 2 seconds, 
sometimes they go up to 3 seconds). It seems that most time is spent 
in Kerberos authentication (logs just "stop flowing" for a while) and 
on HBAC processing - on the 389 DS side it seems that LDAP is busy 
with requests (it looks like it sometimes "hangs" on MOD operation - 
is it updating user last logon time?).


Hello,

When such long requests happened, you may take several pstack of the 
389-ds process. Ideally you can timestamp the pstack output so that it 
is easier to correlate with DS access logs.
Providing pstacks+access/errors logs would really help to know if 
there is a bottleneck.


See also http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs

You'll need to do "debuginfo-install ipa-server slapi-nis"



thanks


Best regards,
Mateusz Malek





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

Re: [Freeipa-users] Unable to remove nsTombstone objects

[Rich Megginson]

On 03/18/2015 11:07 AM, Kim Perrin wrote:

ah, good question. Relevant errors around trying to use the ldif I
included to remove replica ID 97 --

[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to receive all the deleted replica
updates...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Sending cleanAllRUV task to all the replicas...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Cleaning local ruv's...
[18/Mar/2015:04:01:51 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to be cleaned...
[18/Mar/2015:04:01:52 +] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to finish cleaning...
[18/Mar/2015:04:01:52 +] NSMMReplicationPlugin - CleanAllRUV Task:
Successfully cleaned rid(14).
[18/Mar/2015:04:20:18 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:21 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:23 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:23 +] NSMMReplicationPlugin - CleanAllRUV Task:
Replica id (97) is already being cleaned
[18/Mar/2015:04:20:25 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:27 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:29 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:29 +] NSMMReplicationPlugin - CleanAllRUV Task:
Task failed...(-1)
[18/Mar/2015:04:20:31 +] - WARNING: can't modify task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32)
[18/Mar/2015:04:20:31 +] - WARNING: can't find task entry
'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'
[18/Mar/2015:04:24:46 +] ipa_range_check_pre_op - [file
ipa_range_check.c, line 235]: Missing entry to modify.


Not sure what this means.  Anyone?





On Wed, Mar 18, 2015 at 9:52 AM, Rich Megginson  wrote:

On 03/18/2015 10:50 AM, Kim Perrin wrote:

Hi all,
yesterday I cleared up replication problems on my last standing IPA
server. So I somewhat feel like I'm coming out of the tunnel. Today I
want to turn up a replica again. However before doing so I'd like to
clean out the last remnants of data about all previous replicas.
I can't figure out the properly formatted ldif to use to remove the
nsds50ruv and the nsruvReplicaLastModified records in these entries.
Any guidance on the proper ldif to use would be much appreciated --
Here is are the tombstone entries -

dn: nsuniqueid=---,o=ipaca
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5317a4490060
nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
60 550878b90060
nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
47 531ce06900030047
nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
4c 53f65954004c
nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
51 531bf26500010051
nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
56 531a325600040056
nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
5b 53194992005b
nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
061 5317a48a00010061
o: ipaca
nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
   550878ab
nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
   
nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
   
nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
   
nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
   
nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
   
nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389}
   



Using the following to clean these did NOT work -

dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=companyz,dc=com
replica-id: 97
cn: clean 97


Any errors in /var/log/dirsrv/slapd-DOMAIN/errors?

--
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] Unable to remove nsTombstone objects

[Rich Megginson]

On 03/18/2015 10:50 AM, Kim Perrin wrote:

Hi all,
yesterday I cleared up replication problems on my last standing IPA
server. So I somewhat feel like I'm coming out of the tunnel. Today I
want to turn up a replica again. However before doing so I'd like to
clean out the last remnants of data about all previous replicas.
I can't figure out the properly formatted ldif to use to remove the
nsds50ruv and the nsruvReplicaLastModified records in these entries.
Any guidance on the proper ldif to use would be much appreciated --
Here is are the tombstone entries -

dn: nsuniqueid=---,o=ipaca
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 5317a4490060
nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a45500
60 550878b90060
nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce01800
47 531ce06900030047
nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde800
4c 53f65954004c
nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf21600
51 531bf26500010051
nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a322200
56 531a325600040056
nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf00
5b 53194992005b
nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a4500
061 5317a48a00010061
o: ipaca
nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389}
  550878ab
nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389}
  
nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389}
  



Using the following to clean these did NOT work -

dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=companyz,dc=com
replica-id: 97
cn: clean 97


Any errors in /var/log/dirsrv/slapd-DOMAIN/errors?

--
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] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol

[Rich Megginson]

On 03/13/2015 10:45 AM, g.fer.or...@unicyber.co.uk wrote:

Hi

I am going forward with a Password Sync AD  (window 2013)  FreeIPA

ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box.

I got the Password Sync Tool installed in the Windows2013 box and I 
have created a user with it's related password as I am trying to test 
the password changes...




What version of PassSync are you using?

Looking at the access logs I can see the following related to the Sync 
Process:




[13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 nentries=0 
etime=0
[13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer reports 
incompatible or unsupported protocol version.
[13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection from 
AD.Server to FreeIPA.Server
[13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer reports 
incompatible or unsupported protocol version.


So the passwords do not seem to be copied across.
Any idea why is this happening and how to troubleshoot it?

Many Thanks





-- 
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] Windows AD --> LDAP (oneWay)

[Rich Megginson]

On 03/12/2015 03:44 PM, Gonzalo Fernandez Ordas wrote:


Thanks very much for the quick reply. And that was exactly the bit I 
never fully understood, till now.


is it known anyway of synchronising the passwords?


No.


Any recommendations on those regards?


Yes - use Trusts instead of sync.



Thanks



On 12/03/2015 22:13, Rich Megginson wrote:

On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote:

Hi

I have successfully setup an AD---> freeipa Model and joining bits 
and pieces from 389-ds I have setup a oneWaySinc fromWindows.
The issue I got for the last week is the pasword sync which does not 
seem to work at all, it does not matter what I do in the AD server I 
never get the passwords being transferred over.
I went through many manual pages, different versions and I do not 
have clear if I need to run any ldapmodification at all!
This will be a onewaySync and I do not want the passwords being 
replicated BACK to AD, also I read about the "reset" setting and I 
am not sure if every single password needs to be reset at all?


has anybody got any sort of definitive guide or maybe a clear path 
to follow?


http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync 



Note that you have to change a password in AD in order for it to be 
sync'd to freeipa.  PassSync will not sync already existing password.s




Many thanks for all your help

Gonzalo







--
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] Windows AD --> LDAP (oneWay)

[Rich Megginson]

On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote:

Hi

I have successfully setup an AD---> freeipa Model and joining bits and 
pieces from 389-ds I have setup a oneWaySinc fromWindows.
The issue I got for the last week is the pasword sync which does not 
seem to work at all, it does not matter what I do in the AD server I 
never get the passwords being transferred over.
I went through many manual pages, different versions and I do not have 
clear if I need to run any ldapmodification at all!
This will be a onewaySync and I do not want the passwords being 
replicated BACK to AD, also I read about the "reset" setting and I am 
not sure if every single password needs to be reset at all?


has anybody got any sort of definitive guide or maybe a clear path to 
follow?


http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync

Note that you have to change a password in AD in order for it to be 
sync'd to freeipa.  PassSync will not sync already existing password.s




Many thanks for all your help

Gonzalo



--
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] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup.

[Rich Megginson]

On 03/09/2015 03:35 PM, Steven Jones wrote:


Any idea what is going on here please?


==

[root@vuwunicoipam004    ipa-certs]# 
ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U 
replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg  --skip-conncheck
Checking forwarders, please wait ...
WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers
Please fix forwarder configuration to enable DNSSEC support.
(For BIND 9 add directive "dnssec-enable yes;" to "options {}")
WARNING: DNSSEC validation will be disabled


I don't know if this is a problem, so I will leave it to our DNS gurus 
to answer.



Directory Manager (existing master) password:

Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file
Using reverse zone(s) 32.100.10.in-addr.arpa.
Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
   [3/4]: configuring ntpd to start on boot
   [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
   [1/35]: creating directory server user
   [2/35]: creating directory server instance
   [3/35]: adding default schema
   [4/35]: enabling memberof plugin
   [5/35]: enabling winsync plugin
   [6/35]: configuring replication version plugin
   [7/35]: enabling IPA enrollment plugin
   [8/35]: enabling ldapi
   [9/35]: configuring uniqueness plugin
   [10/35]: configuring uuid plugin
   [11/35]: configuring modrdn plugin
   [12/35]: configuring DNS plugin
   [13/35]: enabling entryUSN plugin
   [14/35]: configuring lockout plugin
   [15/35]: creating indices
   [16/35]: enabling referential integrity plugin
   [17/35]: configuring ssl for ds instance
   [18/35]: configuring certmap.conf
   [19/35]: configure autobind for root
   [20/35]: configure new location for managed entries
   [21/35]: configure dirsrv ccache
   [22/35]: enable SASL mapping fallback
   [23/35]: restarting directory server
   [24/35]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 128 seconds elapsed
[vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total 
update abortedLDAP error: Referral]


If the client got back a referral, it means the replica was being 
re-initialized at this time.  Sounds like either the client is not 
checking to see if the initialization is complete, or the server is 
reporting back erroneously that initialization is complete.




   [error] RuntimeError: Failed to start replication

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

Failed to start replication
[root@vuwunicoipam004    ipa-certs]#


No firewalls are active and the network is a simple vyos virtual router.


=

[root@vuwunicoipam002    etc]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
[root@vuwunicoipam002    etc]#
=

=
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
[root@vuwunicoipam004    ipa-certs]#
=




regards

Steven





-- 
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] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO

[Rich Megginson]

On 03/06/2015 09:13 AM, Gianluca Cecchi wrote:
On Fri, Mar 6, 2015 at 4:40 PM, Rich Megginson <mailto:rmegg...@redhat.com>> wrote:





[06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101
nentries=2 etime=0 notes=P
[06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND
[06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1

vCenter SSO error:
Error: Idm client exception: Control not found


There's no error log debug level which will give us all of the
controls received by the server or all of the controls sent back
by the server.  The TRACE level will give us some information.



Could it be that the "Control not found" somehow related with "page 
results control" as described in

https://bugzilla.redhat.com/show_bug.cgi?id=558099


Could be.


Is the "notes=P" in ipa logs a setting managed by the server or by the 
type of the query done by the client?


Yes.  It means the client is requesting a Simple Paged Search by using 
that control.


In my past IPA 3.3.3 logs I didn't find it at the end of the log line 
with nentries...


It has everything to do with the client.  The server has supported 
Simple Paged Search for a long time.  Perhaps some newer version of the 
client is requesting paged results?




Just an attempt...



One more thing - does vCenter work with another LDAP server, like 
openldap or active directory?  If so, try capturing a wireshark trace of 
a successful search operation, then capture a wireshark trace of a 
session using ipa, and we can compare them to see which controls the 
working server is sending back that ipa is not.
-- 
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