dynlist vs memberof performance issues
by Mark Cairney
Hi,
I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.
2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738
(IP=129.215.17.9:636)
2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256
tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms
2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014
etime=0.000214 nentries=1 text=
2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 BIND dn="" method=163
2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030
etime=0.009084 text=SASL(0): successful result:
2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 BIND dn="" method=163
2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031
etime=0.000181 text=SASL(0): successful result:
2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND dn="" method=163
2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK"
authzid="mcairney(a)EASE.ED.AC.UK"
2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND
dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk"
mech=GSSAPI bind_ssf=256 ssf=256
2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024
etime=0.000409 text=
2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH
base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(uid=mcairney)"
2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH attr=* +
2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=5 UNBIND
2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031
etime=13.233679 nentries=1 text=
2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 closed
I'm guessing that as the values are computed that this will be heavier
on the CPU but it seems a bit excessive? Has anyone else noticed any
similar performance issues?
This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I
guess this could be a factor but there's no io waiting on the server and
no swapping?
The database is on a par in size with our Production service ( about
400K user objects with 1 group object per user and then about 80K actual
groups of users)
The config for the primary DB (ACLs and rootPW redacted) is:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /opt/openldap/var/openldap-data/authorise
olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 2
olcReadOnly: FALSE
olcSecurity: ssf=1
olcSecurity: update_ssf=112
olcSecurity: simple_bind=64
olcSizeLimit: unlimited
olcSyncUseSubentry: FALSE
olcTimeLimit: unlimited
olcMonitoring: TRUE
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: eduniType eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniOrgCode eq
olcDbIndex: memberOf pres,eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: member pres,eq
olcDbIndex: memberUid pres,eq
olcDbIndex: eduniRefNo pres,eq
olcDbIndex: eduniTitle pres,eq
olcDbIndex: title pres,eq,sub
olcDbIndex: eduniCardNumber pres,eq
olcDbIndex: eduniYearOfStudy eq
olcDbIndex: description pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: aliasedObjectName eq
olcDbIndex: yubiKeyId pres,eq
olcDbIndex: isMemberOf pres,eq
olcDbIndex: hasMember pres,eq
olcDbIndex: proxyAddresses pres,eq,sub
olcDbMaxReaders: 96
olcDbMaxSize: 32212254720
olcDbMode: 0600
olcDbSearchStack: 16
structuralObjectClass: olcMdbConfig
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
4 months, 4 weeks
mmr of cn=config with OpenLDAP 2.6
by Stefan Kania
Hi to all,
is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it
running with 4 server.
I'm installing all 4 server with Ansible so I created a basic configuration:
------------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: sync
olcLogLevel: stats
olcPidFile: /var/symas/run/slapd.pid
olcArgsFile: /var/symas/run/slapd.args
olcToolThreads: 1
olcServerID: 4
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# Read all needed schema from variable in default/main.yml
include: file:///opt/symas/etc/openldap/schema/core.ldif
include: file:///opt/symas/etc/openldap/schema/cosine.ldif
include: file:///opt/symas/etc/openldap/schema/nis.ldif
include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif
include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif
# Read all modules from variable in default/main.yml
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/symas/lib/openldap
olcModuleLoad: back_mdb
olcModuleLoad: back_monitor
olcModuleLoad: autoca.la
olcModuleLoad: otp.la
olcModuleLoad: argon2.la
olcModuleLoad: syncprov
olcModuleLoad: back_monitor
olcModuleLoad: accesslog.la
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcSizeLimit: 500
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by * break
olcAccess: {1}to dn="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcPasswordHash: {ARGON2}
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by * break
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"
by dn.exact=cn=admin,cn=config read
by dn.exact=cn=admin,dc=example,dc=net read
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcmdbConfig
olcDatabase: {2}mdb
olcSuffix: dc=example,dc=net
olcRootDN: cn=admin,dc=example,dc=net
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcDbCheckpoint: 512 30
olcDbDirectory: /var/symas/openldap-data
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: description pres,eq,sub
olcDbIndex: title pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbMaxSize: 85899345920
olcAccess: {0} to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
manage
by
dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth
manage
by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write
by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read
by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
olcAccess: {3} to attrs=userPassword
by anonymous auth by self write by * none
olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net"
time=unlimited
size=unlimited
------------------
The "ServerID" is different for every server, every thing else is
identical.
Then I created a file to change the serverID:
------------------
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldap01.example.net
olcServerID: 2 ldap://ldap02.example.net
olcServerID: 3 ldap://ldap03.example.net
olcServerID: 4 ldap://ldap04.example.net
------------------
and a file to configure the replication:
------------------
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=1
provider=ldap://ldap01.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=2
provider=ldap://ldap02.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=3
provider=ldap://ldap03.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
olcSyncRepl: rid=4
provider=ldap://ldap04.example.net
binddn="cn=admin,cn=config"
bindmethod=simple
credentials=secret
searchbase="cn=config"
type=refreshAndPersist
retry="5 5 300 20"
timeout=1
starttls=yes
-
add: olcMirrorMode
olcMirrorMode: TRUE
------------------
When I configure the server via Ansible (everything in one playbook) the
replication of cn=config is not working. When I only do the basic
configuration via Ansible and then add the change of serverID and then
the replication of cn=config step by step on every single server:
-------------
ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif
ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
-------------
everything is fine. The two files "serverid.ldif" and "repl_config.ldif"
are the files Ansible created, so the content of the file is the same.
Can it be, that the problem is because Ansible first sets all the
ServerIDs on all servers and then configure the replication of cn=config
on all servers?
For setting up the configuration I took:
https://www.openldap.org/devel/admin/replication.html
Starting at 18.3.3
What I don't understand: Do I realy have to put all Servers in the
replication, even the server it self? So do I realy have to add on
Server-01, the Server "server-01, server-02, server-03 ,server-04" to
the replication? Dosn't it mean that server-01 is replicating to it
self? If it's correct, can someone explain why? O did I understud
something wrong on the webpage?
Stefan
1 year, 4 months
OpenLDAP's UB minefield
by openldap-technical＠kolttonen.fi
Someone recently wrote on openldap-bugs:
> The kernel recently got bitten using the same pattern of unaligned
> short pointers through casts. GCC produced code which corrupted
> initramfs during unpacking.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100363.
> OpenLDAP should fix that code.
Correct. That's what I said long time ago, too. I wonder if OpenLDAP
projects' delusions about Undefined Behaviour "not being a bug" still
persist, or are they perhaps going to fix their buggy code? What a
minefield to walk on, it can blow up anytime.
I am very happy to not have to administer this server code anymore, but I
sure am scared for those who do.
best regards,
Unto Sten
1 year, 5 months
Guide to setup syncrepl with proxy-based push config
by David White
Hello,
I have some basic experience interacting with & troubleshooting OpenLDAP as well as 389-ds, but I don't have a whole lot of experience setting them up or configuring an OpenLDAP server.
My goal is to setup replication from a Primary inside a trusted network outwards to a Replica that is in an untrusted network, without allowing the replica any direct access to the primary, due to firewall flows and network requirements. This is true even for the initial connection, so a simple RefreshAndPersist configuration won't work.
I have read that it is possible to setup a push-based replication using a proxy, such that:
- The proxy gets installed as a "hidden" database onto the same server as the primary
- The proxy sets up replication with the primary using RefreshAndPersist
- The proxy is then able to push the data out of the replica
I have skimmed over, and re-read, a lot of portions from this document: https://www.openldap.org/doc/admin24/replication.html
I have also followed this basic guide to setup a Primary with replication capability: https://ubuntu.com/server/docs/service-ldap-replication
What I'm having trouble with, is finding a useful guide that will walk me through the process to setup and configure the proxy as I've described above.
Questions:
- Based on my requirements above, will the proxy with syncrepl meet my needs?
- If I put the proxy onto the same server as the primary, then due to firewall flows, the replica will not have any access to the primary. All communication will need to be initiated outbound
- If I put the proxy into the same network as the replica, well.... that won't work either, for the same reason
- The following URL from the OpenLDAP docs provides some example configs: https://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy
- If I'm reading everything correctly, though, the "new" / "accepted" / "preferred" way to configure the ldap server is to use the `ldapadd`, `ldapmodify`, and related commands. My confusion and question here is.... should I try to configure all of this by editing the old slapd.conf file as the openldap.org docs provide examples, or is there a way to do this using the ldapmodify & related commands?
- If I can / should do this from the command line... are there any guides or tutorials that will take me step-by-step through the process as I try to build this in a lab environment?
Thanks in advance,
David
Sent with ProtonMail Secure Email.
1 year, 5 months
A very simple olcAccess rule doesn't work
by Volodymyr Melnyk
Dear colleagues,
There's a question I posted on ServerFault
(https://serverfault.com/questions/1088252/a-very-simple-olcaccess-rule-do...),
but it seems that asking my question in this mailing list would be a
better idea/
So, long story short, I have a domain (let's call it
`dc=example,dc=org`) .
The domain has a branch
(`ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`).
There's a simpleSecurityObject in this domain
(`uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`).
I need the uid=admin,*** user to have full (manage) access to the
ou=users,*** branch, so I added the following olcAccess record: `to
dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"
by
dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"`.
It has added to the default set of rules:
```
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage
by * break
olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by
dn="cn=a dmin,dc=example,dc=org" write by anonymous auth by * none
olcAccess: {2}to * by self read by dn="cn=admin,dc=example,dc=org" write
by * none
olcAccess: {3}to
dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=
infra,dc=example,dc=org" by
dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"
manage
```
But something seems to be wrong. When I run `ldapsearch -D
uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org
-W -b
ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`,
I get the following result:
```
# extended LDIF
#
# LDAPv3
# base
<ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org>
with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
command terminated with exit code 32
```
The object is actually available and `cn=admin,dc=example,dc=org` can
see it without any difficulties, so it seems that my access rule is
wrong. But what exactly it is?
It seems that the default rule #2 (`{2} to * by self read by
dn="cn=admin,dc=example,dc=org" write by * none`) fires up earlier than
the rule I added. Does that mean that I should always add my custom
rules before it?
And why does this rule has `by * none`? Doesn't it contradict the
OpenLDAP documentation? "The default access control policy is allow read
by all clients"
(https://www.openldap.org/doc/admin24/access-control.html).
Thank you in advance.
With best regards,
V.Melnyk
1 year, 5 months
openldap ppolicy pwdAccountLockedTime
by kevin martin
it appears from looking at ppolicy.c that pwdAccountLockedTime is not
supported in openlda. is there another way to lock a users account in
openldap outside of simply changing the users password?
---
Regards,
Kevin Martin
1 year, 5 months
symas openldap-packages and kerberos
by Stefan Kania
Hello to all,
I'm trying to get GSSAPI authentication running with the symas-packages.
I generated a ldap.keytab file and it's readable for the ldap-user
running the slapd. With the Debian-packages I ad:
---------
export KRB5_KTNAME="/path/to/ldap.keytab"
---------
I don't want to use the system keytab /etc/krb5.keytab. How do I tell
slapd from the symas-packages to use my service-keytab?
I try to add to my /etc/default/symas-openldap:
---------
KRB5_KTNAME="/path/to/ldap.keytab
---------
but it's not working.
Stefan
1 year, 5 months
remove overlay from cn=config 2.6
by Stefan Kania
hi to all,
with 2.4.x the only way to remove an overlay from cn=config was exort
cn=config edit the export and reimport it. I found a thread where it said:
---------
This will probably be supported in OpenLDAP 2.5.
---------
So is it possible somehow or do I still have to go the way with slapcat
and slapadd?
If it's possible where can I read how?
Stefan
1 year, 5 months
Interpreting username@domainname
by Volodymyr Melnyk
Hello,
Is that possible to tweak some settings that would make OpenLDAP always
interpreting `uid=username@domainname` as `uid=username,ou=domainname`
in authentication queries?
Of course, making the clients to do its job would be preferred, but this
would be less preferable option in my case.
With thanks in advance,
V.Melnyk
1 year, 5 months
