Virtual list view problem
by Venish Khant
Hi all
I am using cpan Net::LDAP module to access LDAP entries. I want to
search LDAP entries using Net::LDAP search method. When I do search, I
want some limited number of entries from search result, for
this(searching) process I am using Net::LDAP::Control::VLV module. But
I get error on VLV response control. Please, any one have idea about
this error.
*
Error:* Died at vlv.pl line 50,
This is my example. I changed the font style of line 50
#!/usr/bin/perl -w
use Net::LDAP;
use Net::LDAP::Control::VLV;
use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE );
use Net::LDAP::Control::Sort;
sub procentry {
my ( $mesg, $entry) = @_;
# Return if there is no entry to process
if ( !defined($entry) ) {
return;
}
print "dn: " . $entry->dn() . "\n";
@attrs = $entry->attributes();
foreach $attr (@attrs) {
#printf("\t%s: %s\n", $attr, $entry->get_value($attr));
$attrvalue = $entry->get_value($attr,asref=>1);
#print $attr.":". $entry->get_value($attr)."\n";
foreach $value(@$attrvalue) {
print "$attr: $value\n";
}
}
$mesg->pop_entry;
print "\n";
}
$ldap = Net::LDAP->new( "localhost" );
# Get the first 20 entries
$vlv = Net::LDAP::Control::VLV->new(
before => 0, # No entries from before target entry
after => 19, # 19 entries after target entry
content => 0, # List size unknown
offset => 1, # Target entry is the first
);
my $sort = Net::LDAP::Control::Sort->new( order => 'cn' );
@args = ( base => "dc=example,dc=co,dc=in",
scope => "subtree",
filter => "(objectClass=inetOrgPerson)",
callback => \&procentry, # Call this sub for each entry
control => [ $sort, $vlv ],
);
$mesg = $ldap->search( @args );
# Get VLV response control
*($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;*
$vlv->response( $resp );
# Set the control to get the last 20 entries
$vlv->end;
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;
$vlv->response( $resp );
# Now get the previous page
$vlv->scroll_page( -1 );
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mes
# Now page with first entry starting with "B" in the middle
$vlv->before(9); # Change page to show 9 before
$vlv->after(10); # Change page to show 10 after
$vlv->assert("B"); # assert "B"
$mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or
die;
$vlv->response( $resp );
--
Venish Khant
www.deeproot.co.in
7 years, 6 months
OpenLDAP and dynalogin (two-factor auth with HOTP)
by Daniel Pocock
Some time ago I created the dynalogin ( http://www.dynalogin.org )
solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it
convenient to use with OpenLDAP seems like a good strategy: can anyone
comment on that?
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it
could be adapted for SASL PLAIN or DIGEST-MD5)
- should not prevent password logins (user should be able to use either
password or HOTP code)
- should enable people to use it indirectly (e.g. if someone already has
pam_ldap working, they should be able to add dynalogin to their OpenLDAP
server and get immediate benefit)
- use cases: UNIX login, high-security webmail login, VPN and OpenID
provider backed by OpenLDAP
I know that SASL already supports OTP, but that is not HOTP, it is OPIE
(or S/Key) RFC 2289:
http://tools.ietf.org/html/rfc2289
whereas HOTP is RFC 4226:
http://www.ietf.org/rfc/rfc4226.txt
HOTP is considered more secure and more widely implemented.
8 years, 5 months
SASL passthrough - multiple domains
by Liam Gretton
I have a working configuration with pass-through auth to an AD domain
using saslauthd.
However now there is a requirement to be able to handle another domain
too, and I cannot work out how to do this. It seems that saslauthd
cannot deal with multiple Kerberos realms, no matter what hoops one
jumps through it eventually boils down to only using whatever
'default_realm' is set to in the krb5.conf file.
Using multiple saslauthd daemons isn't possible either as there's no way
(that I can work out) of getting OpenLDAP to use anything other than the
single socket specified in /etc/sasl2/slapd.conf.
My final idea was to run an LDAP instance per realm, each talking to the
separate saslauthd daemons, and have another outward facing LDAP service
with these as the backends but that's a non starter too because there's
no way of specifying the sasl slapd.conf file, it seems sasl always
looks in /etc/sasl2 for a file derived from the process name (a chroot
environment for each LDAP server is therefore the next thing to look at).
But this seems like a lot of work just to be able to authenticate users
against multiple domains. I appreciate this is a SASL issue rather than
a problem with OpenLDAP, but I'm hoping that someone here has cracked
this already. Googling hasn't thrown up an solution that I can find.
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its
IT Services Tel: +44 (0)116 2522254
University of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
11 years, 5 months
Pass-though Authentication with Saslauthd and Kerberos
by Jeff B
I'm attempting to get pass-though auth to work against saslauthd and
kerberos and while the problem seems to be in sasl I think it's most
likely to be seen in this type of configuration with opendap which I
why I chose this mailing list.
When I run testsaslauthd it works but when I run ldapsearch it fails.
But the curious thing is where it is failing. in doing straces of
saslauthd and packet traces I've found that when ldapsearch calls
salsauthd, and not when I run saslauthd kerberos does not deliver the
AS-REP packets till just after saslauthd times out.
I can't find any difference in how I'm invoking saslauthd with
testdaslauthd and how ldapsearch is invoking saslauthd. However the
packet traces are quite different as you will see below.
I've seen these kind of errors here and there on google but no
resolutions that I can find.
(http://www.openldap.org/lists/openldap-software/200602/msg00278.html)
Centos 6
openldap-2.4.23-15.el6_1.3.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-servers-2.4.23-15.el6_1.3.x86_64
openldap-devel-2.4.23-15.el6_1.3.x86_64
krb5-server-1.9-9.el6_1.2.x86_64
krb5-server-ldap-1.9-9.el6_1.2.x86_64
krb5-workstation-1.9-9.el6_1.2.x86_64
krb5-libs-1.9-9.el6_1.2.x86_64
cyrus-sasl-2.1.23-8.el6.x86_64
cyrus-sasl-lib-2.1.23-8.el6.x86_64
cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
cyrus-sasl-plain-2.1.23-8.el6.x86_64
cyrus-sasl-devel-2.1.23-8.el6.x86_64
My slapd.conf contains nothing regarding kerberos / sasl /
pass-through authentication. I'm using a slapd.conf file for the time
being till i get it all worked out and plan on converting it to a
cn=config configuration.
In my DIT the userPassword field contains: {SASL}myuser@MYREALM where
myuser and my realm are replaced with the proper values.
/etc/sasl2/slapd.conf:
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
/etc/sysconfig/saslauthd
KRB5_KTNAME=/etc/krb5.keytab
SOCKETDIR=/var/run/saslauthd
MECH=kerberos5
Which builds a daemon command line of:
/usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5
My system keytab is:
/etc/krb5.keytab (root.ldap 0640)
host/my.hostname@realm
ldap/my.hostname@realm
My socket parent dir is:
/var/run/saslauthd (root.ldap 0770)
When I run testsaslauthd I get a packet trace between saslauthd and
kerberos is all UDP and works:
> AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
> AS-REQ
< AS-REP
> TGS-REQ
< TGS-REP
When I run ldapsearch the packet trace between saslauthd and kerberos
is UDP and TCP communication. None of the kerberos replies come back
for 18 seconds, the time it takes saslauthd to time out.
> AS-REQ
< KRB5KDC_ERR_PREAUTH_REQUIRED (25)
> AS-REQ
> TCP SYN
< TCP SYN, ACK
> TCP ACK
> TCP AS-REQ
< TCP ACK
> AS-REQ
> AS-REQ
> TCP FIN, ACK <-- saslauthd times out and the AS-REPS all come back at once.
< AS-REP
< AS-REP
< AS-REP
< TCP AS-REP
> TCP RST
an strace of saslauthd supports this timeout theory as it shows the
the timeouts and backoffs.
I can't find any info regarding saslauthd and TCP or UDP or timeouts
like this. Any ideas?
11 years, 6 months
Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
by Chris Hiestand
Part 1: Readability
I know you veterans are probably sick to death of us late-comers asking
questions about cn=config. I understand but please hear me out because I feel
I have done due diligence; but I still have some concerns with the transition.
Workflow has been discussed before, but I suspect it hasn't been fleshed out
because the switch from editing schema and ACLs in flat files to LDAP entries
reduces readability. I have no problem using cn=config for most configuration
attributes, but it gets a lot less user friendly when the value is, what used
to be in slapd.conf, a multi-line string. But I could just be missing something.
Your help is appreciated.
Attached are some screenshots of editing ACLs and a custom schema via 3 methods:
1. cn=config via ldap client (ie apache directory studio)
2. cn=config via ldif
3. old style slapd.conf
Look at the pictures and pick which method you'd like to use to edit
ACLs or a schema:
http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldap.png
http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldif.png
http://snl.salk.edu/~chiestand/openldap/ACLs-via-slapd.conf.png
http://snl.salk.edu/~chiestand/openldap/schema-via-ldap.png
http://snl.salk.edu/~chiestand/openldap/schema-via-ldif.png
http://snl.salk.edu/~chiestand/openldap/schema-via-slapd.conf.png
I think the choice is clearly old style slapd.conf. Otherwise you miss
comments and ordering (until Howard Chu's X-ORDERED ldap extension is implemented),
and unlimited whitespace to substantially improve readability.
The LDIF files are a mess because of the way words are split unpredictably by new
lines. You can't use a simple search and replace with any hope of it working.
Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …)
but I don't think it's possible to have ldapsearch output this way.
Editing via an ldap client is easy if you're just editing an
attribute here and there, but because of the interacting nature of ACLs and schema
elements, poor readability (no newlines) makes editing via an ldap client more difficult
(a gui with smart sorting and syntax highlighting could make it better).
Am I just missing workflow techniques or key concepts that improves readability?
Or is your advice to just suck it up and get used to it?
Part 2: Deleting entries in cn=config
Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still
the plan? The Roadmap page isn't specific.
What about whole schema deletes? From a sysadmin perspective, I should be able
to add, modify, or delete anything from the configuration. For QA reasons, you
want to be have the exact configuration you want; not the configuration you
want plus legacy boogers.
I understand if this isn't trivial to achieve from the developer perspective.
Granted I don't have the whole picture here, but I'd argue that it's worth it.
Lastly, I thank everyone who contributes to OpenLDAP.
11 years, 6 months
ACL syntax with wildcards
by Nick Milas
Hi,
We would like to use ACL statements of the form (used for illustration
purposes):
access to dn.subtree="ou=people,dc=example,dc=com"
filter="(ou=xxxxx)" attrs="someAttrs"
by group.exact="cn=xxxxxAdmins,ou=Groups,dc=example,dc=com" write
by group.exact="cn=allAdmins,ou=Groups,dc=example,dc=com" read
by self read
where xxxxx is some string.
In essence, we assign people entries to various administrative groups,
depending on the value of the ou attribute of the entry.
Of course we can write many statements, one per ou value / admin group,
but it would be much more concise to use just one statement using wildcards.
Could someone please suggest if and how the above can be written
correctly, using e.g. regex?
I appreciate any suggestions.
Thanks,
Nick
11 years, 6 months
DEL don't get synced
by Marc Patermann
Hi,
under some circumstances DEL don't get replicated to the consumers
(SyncRepl). I think this has to do with other changes at the some moment.
I attached two logs excepts in sync.log.
In the first except there is only a DEL
Jan 31 09:16:01 ldapserver slapd[10641]: conn=79138 op=2 DEL
dn="employeeNumber=19676,ou=humans,ou=foo"
For this there is a
Jan 31 09:16:01 ldapserver slapd[10641]: syncprov_sendresp:
cookie=rid=401,csn=20120131081601.377028Z#000000#000#000000
line for every connected consumer.
In the second step there is a MOD and a DEL
Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=2 MOD
dn="ou=FA-WF,ou=gruppen,ou=humans,ou=foo"
Jan 31 10:31:01 ldapserver slapd[10641]: conn=79938 op=3 DEL
dn="employeeNumber=24387,ou=humans,ou=foo"
As far as I can see, there is only sync activity for the MOD action, and
not for the DEL action. The DEL is not synced.
Marc
11 years, 7 months
db in shadow context without replication
by Julien Soula
hello,
I have a problem with a cancelation of replication of cn=config. I
configured replication of cn=config in slapd.d (without slapd.conf)
and I wanted to stop it.
First one, I didn't see how to cancel replication in cn=config
otherwise that deleting olcSyncRepl attribute directly in slapd.d
files since database was in shadow context. Is there a proper way ?
So I stopped slapd and deleted olcSyncRepl attribute and restarted
it. But when I commited change, it failed with error : "shadow context
without update referral" (there is no more olcSyncRepl in config) !
I tried to enable olcMirrorMode (directly in files again) but slapd
crashed at start saying that the database was not in shadow context !
I cannot explain this behaviour. How the server determine that a
database is in shadow context or not ? Is there a cache somewhere ?
Sincerly,
--
Julien
<< Vous n'avez rien a dire... Parlons-en! >>
11 years, 8 months
Password expiration
by Collins, Cris L.
I am running OpenLDAP as packaged for CentOS 5 and having problems with
password expiration.
Users are being told every time they login that their password has expired
and to change their password. When ShadowMax is changed to 99999 their
passwords are not expiring. The preferable setting is 90 days.
ShadowLastChange is updating to the correct date when they input a new
password. Thank you for you time and input as to why this might be
occurring.
11 years, 8 months
problem with ldap backend
by Alex Samad - Yieldbroker
Hi
I am trying to setup a connection from openldap to MS AD
I am using this
dn: olcDatabase={3}ldap
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {3}ldap
olcSuffix: dc=xyz,dc=com
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
olcReadOnly: TRUE
olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
olcSizeLimit: 500
olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com"
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: TRUE
This works fine when I pass a bind DN.
I would like to convert this to allow anon access to ldap, which does a user bind to MS AD so I added this
olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC= xyz,DC=com" credentials="secret" starttls=no
but it is not working, I can not make a anon search request, they retrieve any thing frome the MSAD ldap server.
Thanks
11 years, 8 months
