Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Howard Chu]

Frank Swasey wrote:

Today at 5:22pm, Howard Chu wrote:


Frank Swasey wrote:

On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:


I do make some modifications to the codebase, but have never [changed
auditContext from being DSA].  I'll double check the patch decks to make
sure something did not match and mess that attribute up unintentionally.


I have confirmed that my code modifications have not changed the auditContext
attribute's definition, it is still "Usage directoryOperation".


This is exactly wrong. It must be "usage dsaOperation". You have indeed
broken this in your patching.


Howard, before you accuse someone of such a thing, you should really go look
at the source...  I have done nothing to the definition in the
servers/slapd/overlays/accesslog.c file, the file is exactly as delivered in
the 2.4.44 tar ball, as well as the existing code here:

http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob_plain;f=servers/slapd/overlays/accesslog.c;hb=refs/heads/master


The above referenced code clearly has dSAOperation on line 399, not 
directoryOperation.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Frank Swasey]

Today at 7:49pm, Frank Swasey wrote:


Today at 5:22pm, Howard Chu wrote:


Frank Swasey wrote:

On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:


I do make some modifications to the codebase, but have never [changed
auditContext from being DSA].  I'll double check the patch decks to make
sure something did not match and mess that attribute up unintentionally.


I have confirmed that my code modifications have not changed the 
auditContext

attribute's definition, it is still "Usage directoryOperation".


This is exactly wrong. It must be "usage dsaOperation". You have indeed 
broken this in your patching.


Howard, before you accuse someone of such a thing, you should really go look 
at the source...  I have done nothing to the definition in the 
servers/slapd/overlays/accesslog.c file, the file is exactly as delivered in 
the 2.4.44 tar ball, as well as the existing code here:


http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob_plain;f=servers/slapd/overlays/accesslog.c;hb=refs/heads/master


I see... that "Usage directoryOperation" is inside a comment block. 
The real code is 5 lines further down and does have "USAGE dSAOperation" 
in it.


/sigh

--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Frank Swasey]

Today at 5:22pm, Howard Chu wrote:


Frank Swasey wrote:

On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:


I do make some modifications to the codebase, but have never [changed
auditContext from being DSA].  I'll double check the patch decks to make
sure something did not match and mess that attribute up unintentionally.


I have confirmed that my code modifications have not changed the 
auditContext

attribute's definition, it is still "Usage directoryOperation".


This is exactly wrong. It must be "usage dsaOperation". You have indeed 
broken this in your patching.


Howard, before you accuse someone of such a thing, you should really 
go look at the source...  I have done nothing to the definition in the 
servers/slapd/overlays/accesslog.c file, the file is exactly as 
delivered in the 2.4.44 tar ball, as well as the existing code here:


http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob_plain;f=servers/slapd/overlays/accesslog.c;hb=refs/heads/master

--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Howard Chu]

Frank Swasey wrote:

On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:


I do make some modifications to the codebase, but have never [changed
auditContext from being DSA].  I'll double check the patch decks to make
sure something did not match and mess that attribute up unintentionally.


I have confirmed that my code modifications have not changed the auditContext
attribute's definition, it is still "Usage directoryOperation".


This is exactly wrong. It must be "usage dsaOperation". You have indeed broken 
this in your patching.



--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: ldapsearch + read-only domain controller: cannot bind

[l]

Hi Mark.

Thank you, looks like the problem is not related to OpenLDAP package. I've 
tried to get a service ticket for ldap/dc.contoso@contoso.com, but to no 
avail:

assuming I've got valid TGT:
[root@centos7] # KRB5_TRACE=/dev/stdout kvno ldap/dc.contoso@contoso.com
Getting credentials u...@contoso.com -> ldap/dc.contoso@contoso.com using 
ccache FILE:/tmp/krb5cc_0
Retrieving u...@contoso.com -> ldap/dc.contoso@contoso.com from 
FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
Retrieving u...@contoso.com -> krbtgt/contoso@contoso.com from 
FILE:/tmp/krb5cc_0 with result: 0/Success
Starting with TGT for client realm: u...@contoso.com -> 
krbtgt/contoso@contoso.com
Requesting tickets for ldap/dc.contoso@contoso.com, referrals on
Generated subkey for TGS request: aes256-cts/BECF
etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, 
rc4-hmac, camellia128-cts, camellia256-cts
Encoding request body and padata into FAST request
Sending request (2185 bytes) to CONTOSO.COM
Resolving hostname dc.contoso.com
Initiating TCP connection to stream 192.168.0.100:88
Sending TCP request to stream 192.168.0.100:88
Resolving hostname dc.contoso.com
Sending initial UDP request to dgram 192.168.0.100:750
Sending initial UDP request to dgram 192.168.0.100:88
Sending retry UDP request to dgram 192.168.0.100:88
Sending retry UDP request to dgram 192.168.0.100:88
Terminating TCP connection to stream 192.168.0.100:88
kvno: A service is not available that is required to process the request while 
getting credentials for ldap/dc.contoso@contoso.com

At the first sight, it looks like a network problem. However, tcpdump + 
wireshark revealed that the packets are being sent and received with no errors, 
and dc.contoso.com answers with 'KRB Error: KRB5KDC_ERR_SVC_UNAVAILABLE'. So it 
looks like a problem on the DC itself. However, there are no failures logged.
I think it somehow related to Kerberos FAST protocol and its implementation on 
Windows Server side.
I'll keep digging.


18.06.2016, 15:48, "Mark Pröhl" :
> On 06/11/2016 01:27 PM, l...@avc.su wrote:
>>  Hello.
>>
>>  I'm seeing very strange behavior with ldapsearch with GSSAPI on CentOS 7
>>  and Microsoft Windows 2012R2 Read-only Domain Controller.
>>  I can obtain Kerberos ticket with no errors, with my user's credentials,
>>  or with machine's keytab.
>>
>>  However, when I'm trying to make LDAP request with GSSAPI bind, i'm
>>  getting an error:
>>
>>  ldapsearch -Y GSSAPI -H ldap://dc.contoso.com/ -b "dc=contoso,dc=com"
>>  "(sAMAccountName=user)"
>>  SASL/GSSAPI authentication started
>>  ldap_sasl_interactive_bind_s: Local error (-2)
>>  additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
>>  GSS failure. Minor code may provide more information (A service is not
>>  available that is required to process the request)
>>
>>  openldap-clients ver. 2.4.40 release 9.el7_2
>>
>>  Here's the -d1 output:
>>
>>  ldap_url_parse_ext(ldap://dc.contoso.com/)
>>  ldap_create
>>  ldap_url_parse_ext(ldap://dc.contoso.com:389/??base)
>>  ldap_sasl_interactive_bind: user selected: GSSAPI
>>  ldap_int_sasl_bind: GSSAPI
>>  ldap_new_connection 1 1 0
>>  ldap_int_open_connection
>>  ldap_connect_to_host: TCP dc.contoso.com:389
>>  ldap_new_socket: 3
>>  ldap_prepare_socket: 3
>>  ldap_connect_to_host: Trying 192.168.0.100:389
>>  ldap_pvt_connect: fd: 3 tm: -1 async: 0
>>  attempting to connect:
>>  connect success
>>  ldap_int_sasl_open: host=dc.contoso.com
>>  SASL/GSSAPI authentication started
>>  ldap_msgfree
>>  ldap_err2string
>>  ldap_sasl_interactive_bind_s: Local error (-2)
>>  additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
>>  GSS failure. Minor code may provide more information (A service is not
>>  available that is required to process the request)
>>  ldap_free_connection 1 1
>>  ldap_send_unbind
>>  ber_flush2: 7 bytes to sd 3
>>  ldap_free_connection: actually freed
>>
>>  This problem does not appear with regular DC servers. I can bind and
>>  search to them with no errors.
>>
>>  How can I debug this problem?
>
> Hi,
>
> Maybe you can turn on kerberos tracing and repeat the failing ldapsearch
> from CentOS7 and send us the output?
>
> I.e.:
>
> KRB5_TRACE=/dev/stdout ldapsearch -Y GSSAPI -H ldap://dc.contoso.com/ -b
> "dc=contoso,dc=com" "(sAMAccountName=user)"
>
> Cheers,
>
> Mark

Re: ldapsearch + read-only domain controller: cannot bind

[l]

Thank you for the hint.
However, I'm not running slapd since this is Microsoft AD environment + Linux 
clients. I've tried to obtain a ticket for service upn as root and got the TGT, 
so it doesn't look like permissions issue.

15.06.2016, 23:06, "Dieter Klünter" :
> Am Sun, 12 Jun 2016 17:34:47 +0300
> schrieb l...@avc.su:
>
>>  Hi Dieter.
>>
>>  I've tried performing this search from CentOS6 machine, with my own
>>  UPN, with machine UPN, and it were successful. Accessing SPN
>>  ldap/dc.contoso@contoso.com Keytab is located
>>  in /etc/krb5.keytab, owned by root, access mode 0600. Dumped traffic
>>  from the problem server. On myTGS-REQ, DC responds with
>>  'krb5kdc_err_svc_unavailable' packet.
>>  12.06.2016, 10:41, "Dieter Klünter" :
>>
>>  Am Sat, 11 Jun 2016 14:27:26 +0300
>>  schrieb l...@avc.su:
>
> [...]
>
> the user, slapd runs as, needs to read keytab. Check with klist
> whether a ldap service principal ticket is available.
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://sys4.de
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Frank Swasey]

Today, I am not able to make it fail (I swear, all I did was change the 
master the slave pointed to and then change it back).


--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Quanah Gibson-Mount]

--On Tuesday, June 21, 2016 8:09 AM -0400 Frank Swasey 
 wrote:



On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:


I do make some modifications to the codebase, but have never [changed
auditContext from being DSA].  I'll double check the patch decks to
make sure something did not match and mess that attribute up
unintentionally.


I have confirmed that my code modifications have not changed the
auditContext attribute's definition, it is still "Usage
directoryOperation".

To further complicate the matter, I have pointed my delta-syncrepl slave
consumer at a different MMR configured master and it replicates from
empty just fine.  That second MMR configured master is actually a VMware
clone of the one of the two test MMR systems and is identical in all
respects except the slapd configuration (it is paired with my current
non-MMR production master).  This leads me to believe it is either
something I've managed to mess up in the configuration of the testing MMR
pair, or it is because the base dn in the testing MMR pair has multiple
contextCSN values (for serverid's 0, 1, and 2) and (so far) the
production setup still has a single contextCSN value.

So, let me back up a few feet and make sure I am not setting myself up
for ultimate failure when I complete the migration of my production
environment to a full MMR master pair with delta-syncrepl slaves.

My plan is that I will have two systems which are configured as MMR, so
that should a datacenter fail, I can (manually) fail-over the service ip
address to the surviving datacenter and continue operation with LDAP
updates.  I also will have six read-only delta-syncrepl slaves to carry
the workload of approximately 20 million queries per day.

I did not think that using MMR for the master server would preclude
having delta-syncrepl slaves, and I find no discussion in my googling to
indicate either way.

Have I made a bad design?


I only use delta-syncrepl slaves, and I have multiple contextCSNs served 
out by masters, and do not have this issue at all.  In my case, it is CSNS 
0, 1, 2, 3, and 4.  In fact, I recently updated it so that my replicas can 
pull from N number of masters. ;)


--Quanah


--

Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc

Re: openldap 2.4.44 - delta-syncrepl fails on auditContext

[Frank Swasey]

On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:

I do make some modifications to the codebase, but have never [changed 
auditContext from being DSA].  I'll double check the patch decks to 
make sure something did not match and mess that attribute up 
unintentionally.


I have confirmed that my code modifications have not changed the 
auditContext attribute's definition, it is still "Usage 
directoryOperation".


To further complicate the matter, I have pointed my delta-syncrepl slave 
consumer at a different MMR configured master and it replicates from 
empty just fine.  That second MMR configured master is actually a VMware 
clone of the one of the two test MMR systems and is identical in all 
respects except the slapd configuration (it is paired with my current 
non-MMR production master).  This leads me to believe it is either 
something I've managed to mess up in the configuration of the testing 
MMR pair, or it is because the base dn in the testing MMR pair has 
multiple contextCSN values (for serverid's 0, 1, and 2) and (so far) the 
production setup still has a single contextCSN value.


So, let me back up a few feet and make sure I am not setting myself up 
for ultimate failure when I complete the migration of my production 
environment to a full MMR master pair with delta-syncrepl slaves.


My plan is that I will have two systems which are configured as MMR, so 
that should a datacenter fail, I can (manually) fail-over the service ip 
address to the surviving datacenter and continue operation with LDAP 
updates.  I also will have six read-only delta-syncrepl slaves to carry 
the workload of approximately 20 million queries per day.


I did not think that using MMR for the master server would preclude 
having delta-syncrepl slaves, and I find no discussion in my googling to 
indicate either way.


Have I made a bad design?

--
Frank Swasey| http://www.uvm.edu/~fcs
Sr Systems Administrator| Always remember: You are UNIQUE,
University of Vermont   |just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)

Re: Odd MMR behaviour with delta-syncrepl and refreshAndPersist

[Mark Cairney]

Sure, the ITS is 8444:

http://www.openldap.org/its/index.cgi/Incoming?id=8444;page=44

I'm out the office this week anyway so won't be in a position to do any 
testing etc till next.



On 21/06/2016 02:39, Paul B. Henson wrote:

On Thu, Jun 16, 2016 at 10:10:19AM +0100, Mark Cairney wrote:


I'll fill in an ITS as suggested.

Hmm, this is on a 2.4.44 deployment with the patch from head applied
that Quanah indicated fixed the original problem he was having? I just
compiled 2.4.44 with that patch last week in preparation for an upcoming
planned upgrade; however, we use memberOf as well so now perhaps I'll
hold off again a bit . Would you be so kind as to post the ITS #
once you file it?

Thanks...




--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: Give user only access to a few entries that he "owns"

[Michael Ströder]

PenguinWhispererThe . wrote:
> Thanks for the link.  I've looked in the examples. Should expand be used to
> accomplish this then?
> 
> Note that the host is in an other tree. And the attribute that should be
> editable by the user is at the same level (sibling) as the owner (so the
> user that should be able to edit it).

That's all possible and you should find similar examples in the FAQ.
But crafting your ACLs is your homework.
And yes, it takes some time to get familiar with this.

Ciao, Michael.

> On Jun 21, 2016 7:59 AM, "Michael Ströder"  wrote:
> 
>> PenguinWhispererThe . wrote:
>>> I want the user to be able to update one attribute of this host.
>>> "self" keyword doesn't work here as the user doesn't bind to it.
>>> [..]
>>> Could anyone share an example?
>>
>> The FAQ-O-MATIC has many very useful examples.
>>
>> Start here: http://www.openldap.org/faq/data/cache/189.html
>>
>> Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: cn=config database setup

[Clément OUDOT]

Le 20/06/2016 17:50, Trent Dierking a écrit :
Following the quickstart guide at 
http://www.openldap.org/doc/admin24/quickstart.html and the following 
happens


# ./sbin/slapadd -F etc/'cn=config' -l etc/openldap/slapd.ldif
57680d0f invalid config directory etc/cn=config, error 2
slapadd: bad configuration directory!

# mkdir -p 'etc/cn=config'

# ./sbin/slapadd -F etc/'cn=config' -l etc/openldap/slapd.ldif
Available database(s) do not allow slapadd

I've ensured the appropriate var/openldap-data directory exists. I've 
tried adding the maxsize key shown on the guide. I am not sure what 
else could cause this, as this is for the hardcoded cn=config database.


You should try to add -n0 to your slapadd command, which will select the 
"0" backend which should be the cn=config backend.


--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
87, rue de Turbigo - 75003 PARIS
Blog: http://sflx.ca/coudot

Re: Give user only access to a few entries that he "owns"

[PenguinWhispererThe .]

Hi Michael.

Thanks for the link.  I've looked in the examples. Should expand be used to
accomplish this then?

Note that the host is in an other tree. And the attribute that should be
editable by the user is at the same level (sibling) as the owner (so the
user that should be able to edit it).

Thanks in advance.
On Jun 21, 2016 7:59 AM, "Michael Ströder"  wrote:

> PenguinWhispererThe . wrote:
> > I want the user to be able to update one attribute of this host.
> > "self" keyword doesn't work here as the user doesn't bind to it.
> > [..]
> > Could anyone share an example?
>
> The FAQ-O-MATIC has many very useful examples.
>
> Start here: http://www.openldap.org/faq/data/cache/189.html
>
> Ciao, Michael.
>
>

Re: Give user only access to a few entries that he "owns"

[Michael Ströder]

PenguinWhispererThe . wrote:
> I want the user to be able to update one attribute of this host.
> "self" keyword doesn't work here as the user doesn't bind to it.
> [..]
> Could anyone share an example?

The FAQ-O-MATIC has many very useful examples.

Start here: http://www.openldap.org/faq/data/cache/189.html

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature