10:50 p.m.
I have been working with updating the attributeType 'uid' to conform the a
"caseExactMatch" setting. I understand that this does agree with RFC
standards, but this Directory Server will not be interacting with any ldap
applications. The primary purpose is user authentication.
I must be missing something on how the Directory Server (fedora-ds) defines
the attributes. I was under the impression I could just update the
00core.ldif entry and the new matching rule would then be applied. This has
proven not to be the case, I think it might have to do with the server
interacts with the plugins or the CoS which needs to be addressed.
Anyone who could educate me on a method to enforce case sensitivity for the
attribute uid, it would help me out greatly. I have read everything I can
find on the subject and it just does not seem to be documented (not in a
direct manner anyway).
This is how the attribute appears in the 00core.ldif after I attempted to
change the attribute definition but it does not seem to have any effect.
attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC
'Standard LDAP attribute type' EQUALITY caseExactMatch SUBSTR
caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC
1274' )
Thanks in advance to anyone who can point me in the correct direction, I
must be making this more difficult then it needs to be.
2:08 p.m.
Scott wrote:
I must be missing something on how the Directory Server (fedora-ds)
defines the attributes. I was under the impression I could just update
the 00core.ldif entry and the new matching rule would then be applied.
This has proven not to be the case, I think it might have to do with
the server interacts with the plugins or the CoS which needs to be
addressed.
What exactly failed and how?
--
Pete
11:17 a.m.
New subject: [Fedora-directory-users] Re: Cos? or plug-in issue?
Pete Rowley <prowley <at> redhat.com> writes:
Scott wrote:
> I must be missing something on how the Directory Server (fedora-ds)
> defines the attributes. I was under the impression I could just update
> the 00core.ldif entry and the new matching rule would then be applied.
> This has proven not to be the case, I think it might have to do with
> the server interacts with the plugins or the CoS which needs to be
> addressed.
>
What exactly failed and how?
When I apply the caseExactMatch definition to the attribute, I expected it to
enforce the matching rule. However it did not seem to have any effect. I
tested it both with the schema checking on and off. I ended up using the
default attributeType and I just changed the SYNTAX to
1.3.6.1.4.1.1466.115.121.1.26.
This seems to enforce the case for the uid. I think I was under the mis-
understanding that I could tweak the attribute type specifically to meet my
sites needs. I have been reading up on the CoS and I think this is where I
went wrong. Is there an alternate method to provide granular control over
attributeTypes, or is the FDS tied to the CoS model? The entry I am talking
about is listed below. Thanks
attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' )
DESC 'Standard LDAP attribute type' EQUALITY caseExactMatch SUBSTR
caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC
1274' )
4:02 p.m.
New subject: [Fedora-directory-users] Re: Cos? or plug-in issue?
Scott wrote:
Pete Rowley <prowley <at> redhat.com> writes:
>Scott wrote:
>
>
>
>>I must be missing something on how the Directory Server (fedora-ds)
>>defines the attributes. I was under the impression I could just update
>>the 00core.ldif entry and the new matching rule would then be applied.
>>This has proven not to be the case, I think it might have to do with
>>the server interacts with the plugins or the CoS which needs to be
>>addressed.
>>
>>
>>
>What exactly failed and how?
>
>
>
When I apply the caseExactMatch definition to the attribute, I expected it to
enforce the matching rule. However it did not seem to have any effect. I
tested it both with the schema checking on and off. I ended up using the
default attributeType and I just changed the SYNTAX to
1.3.6.1.4.1.1466.115.121.1.26.
This seems to enforce the case for the uid. I think I was under the mis-
understanding that I could tweak the attribute type specifically to meet my
sites needs. I have been reading up on the CoS and I think this is where I
went wrong. Is there an alternate method to provide granular control over
attributeTypes, or is the FDS tied to the CoS model? The entry I am talking
about is listed below. Thanks
Class of service has nothing to do with schema. It is a mechanism for
sharing attribute / value pairs among a group of entries so that an
administrator has one place to change those attribute value pairs. The
only place CoS gets involved with schema is when schema checking is on,
when it will ensure the attribute / value pairs it provides are allowed
to appear in the entry.
I am at a loss to explain why changing the syntax from DirectoryString
to IA5String would suddenly produce the results you were expecting. Are
you restarting the server between changes to the schema files?
--
Pete
5:30 p.m.
New subject: [Fedora-directory-users] Re: Cos? or plug-in issue?
Pete Rowley <prowley <at> redhat.com> writes:
>When I apply the caseExactMatch definition to the attribute, I expected it to
>enforce the matching rule. However it did not seem to have any effect. I
>tested it both with the schema checking on and off. I ended up using the
>default attributeType and I just changed the SYNTAX to
>1.3.6.1.4.1.1466.115.121.1.26.
>This seems to enforce the case for the uid. I think I was under the mis-
>understanding that I could tweak the attribute type specifically to meet my
>sites needs. I have been reading up on the CoS and I think this is where I
>went wrong. Is there an alternate method to provide granular control over
>attributeTypes, or is the FDS tied to the CoS model? The entry I am talking
>about is listed below. Thanks
>
>
Class of service has nothing to do with schema. It is a mechanism for
sharing attribute / value pairs among a group of entries so that an
administrator has one place to change those attribute value pairs. The
only place CoS gets involved with schema is when schema checking is on,
when it will ensure the attribute / value pairs it provides are allowed
to appear in the entry.
I am at a loss to explain why changing the syntax from DirectoryString
to IA5String would suddenly produce the results you were expecting. Are
you restarting the server between changes to the schema files?
Well if that is the case and there is no underlying mechanisims that I was
exluding I am really discouraged with the ability to provide customization. Do
you see anyting wrong with how I attempted to define the attribute that could
have been causing the issue? It has to be something I am leaving out.
Yes I restarted everytime. The onlytime I can get it to enforce the case is with
the IA5String. Since the IA5String seems to be working, do you see any problem
with me leaving it defined? Thanks again
6 p.m.
New subject: [Fedora-directory-users] Re: Cos? or plug-in issue?
Scott wrote:
Well if that is the case and there is no underlying mechanisims that I
was
exluding I am really discouraged with the ability to provide customization. Do
you see anyting wrong with how I attempted to define the attribute that could
have been causing the issue? It has to be something I am leaving out.
No I don't see anything wrong per se. What was your test? Was it a
straight LDAP search?
Yes I restarted everytime. The onlytime I can get it to enforce the
case is with
the IA5String. Since the IA5String seems to be working, do you see any problem
with me leaving it defined? Thanks again
IA5String is essentially 7 bit ascii, so no international characters.
If you are fine with that, it is ok.
--
Pete
10:06 p.m.
New subject: [Fedora-directory-users] Re: Cos? or plug-in issue?
Pete Rowley <prowley <at> redhat.com> writes:
> >
> >
> IA5String is essentially 7 bit ascii, so no international characters.
> If you are fine with that, it is ok.
for now I dont have any issues with using appreciate your
perspective. I hope
to eventually figure out what the issue is with the alternate method,
but for now it meets my requirments. Thanks again.
>
>
No I don't see anything wrong per se. What was your test? Was it a
straight LDAP search?
straight LDAP search via CLI and via web express interface
6:19 p.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
Halloo!
I am attempting to migrate an existing OpenLDAP directory to FDS 1.01.
I had extended the OL setup with samba.schema and had imported a bunch
of existing Samba data with scripts. This is all on Fedora Core 3. I
was motivated to migrate by 1) the console apps and 2) better ACI mgmt;
I figured both of these might better support a better self-service
directory model where people can edit some of their own details.
I have FDS running and just got console running. I found the script to
convert samba.schema to FDS LDIF format and that seemed to work a
treat. However, on startup, FDS seems to completely ignore my
"61samba.ldif". Worse, it seems not to notice any errors. What this
measn is that I am not able to import any users (and other elements)
from my OL directory as they have various samba* attributes.
The rest of the XXname.ldif schema files seem to be processing just
fine. I have audited some of the last to load 50ns-web, 50ns-calendar
and 60pam-plugin, and all of their attributes appear in the listing I
can find via the console (or phpLDAPadmin).
I saw nothing in the slapd-servername/logs/* so I increased error
loglevel to 192 and then to some ridiculous combined value from the
debug table in the FAQ. I never see any reference to problems
processing "61samba" -- the only errors I can generate with "samba" in
them are when I attempt to add users "has unknown object class
'sambaSamAccount'", for example. I changed 61samba.ldif to
21samba.ldif to see if this problem was order-dependent. No change.
For grins, I added a junk ldif called 59nonsense.ldif and I couldn't get
*that* to generate any lines in the "errors" log file or anywhere that I
can tell. "service ldap restart" just seems to go on its merry way. It
is like the ancillary LDIF list doesn't exist or something.
So, for fun I *copied* one of the LDIF schema files to "59nonsense.ldif"
and figured I would see log complaints about duplicate attributes, but
*nothing*. and nothing in debug log. slapd restarts without a hitch.
Anyhow, FDS looks great and I am sure it will be a lot of fun, but at
the moment, I think I am missing some *big*, dope-slap-worthy item --
some big, red switch that says "COMMIT" that I need to flip!
Thoughts? Thanks.
Jim
--
/*********************************************************/
Jim Hogan jimh *A T* u *DO T* washington *D OT* edu
/*********************************************************/
8:12 p.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
Jim Hogan wrote:
Halloo!
I am attempting to migrate an existing OpenLDAP directory to FDS
1.01. I had extended the OL setup with samba.schema and had imported
a bunch of existing Samba data with scripts. This is all on Fedora
Core 3. I was motivated to migrate by 1) the console apps and 2)
better ACI mgmt; I figured both of these might better support a better
self-service directory model where people can edit some of their own
details.
I have FDS running and just got console running. I found the script
to convert samba.schema to FDS LDIF format and that seemed to work a
treat. However, on startup, FDS seems to completely ignore my
"61samba.ldif". Worse, it seems not to notice any errors. What this
measn is that I am not able to import any users (and other elements)
from my OL directory as they have various samba* attributes.
This is what I did:
cd /opt/fedora-ds/slapd-localhost/config/schema
perl ~/ol2rhds.pl < /usr/share/doc/samba-3.0.14a/LDAP/samba.schema >
61samba.ldif
# http://www.directory.fedora.redhat.com/download/ol2rhds.pl
../../restart-slapd
ldapsearch -x -h localhost -p myport -s base -b "cn=schema"
"objectclass=*" | grep -i samba
I see lots of output like the following:
....
objectClasses: ( 1.3.6.1.4.1.7165.2.2.12 NAME 'sambaConfigOption' DESC
'Samba
Configuration Option' SUP top STRUCTURAL MUST sambaOptionName X-ORIGIN
'user
objectClasses: ( 1.3.6.1.4.1.7165.2.2.15 NAME 'sambaAccountPolicy' DESC
'Samba
Account Policy' SUP top STRUCTURAL MUST ( sambaAccountPolicyName $
sambaAcco
attributeTypes: ( 1.3.6.1.4.1.7165.2.1.40 NAME 'sambaAlgorithmicRidBase'
DESC
'Base at which the samba RID generation algorithm should operate'
EQUALITY in
attributeTypes: ( 1.3.6.1.4.1.7165.2.1.19 NAME 'sambaGroupType' DESC 'NT
Group
attributeTypes: ( 1.3.6.1.4.1.7165.2.1.55 NAME 'sambaLogonHours' DESC
'Logon H
....
The rest of the XXname.ldif schema files seem to be processing just
fine. I have audited some of the last to load 50ns-web, 50ns-calendar
and 60pam-plugin, and all of their attributes appear in the listing I
can find via the console (or phpLDAPadmin).
I saw nothing in the slapd-servername/logs/* so I increased error
loglevel to 192 and then to some ridiculous combined value from the
debug table in the FAQ. I never see any reference to problems
processing "61samba" -- the only errors I can generate with "samba"
in
them are when I attempt to add users "has unknown object class
'sambaSamAccount'", for example. I changed 61samba.ldif to
21samba.ldif to see if this problem was order-dependent. No change.
For grins, I added a junk ldif called 59nonsense.ldif and I couldn't
get *that* to generate any lines in the "errors" log file or anywhere
that I can tell. "service ldap restart" just seems to go on its merry
way. It is like the ancillary LDIF list doesn't exist or something.
So, for fun I *copied* one of the LDIF schema files to
"59nonsense.ldif" and figured I would see log complaints about
duplicate attributes, but *nothing*. and nothing in debug log. slapd
restarts without a hitch.
Anyhow, FDS looks great and I am sure it will be a lot of fun, but at
the moment, I think I am missing some *big*, dope-slap-worthy item --
some big, red switch that says "COMMIT" that I need to flip!
Thoughts? Thanks.
Jim
9 p.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
On Wed, 1 Mar 2006, Richard Megginson wrote:
This is what I did:
cd /opt/fedora-ds/slapd-localhost/config/schema
perl ~/ol2rhds.pl < /usr/share/doc/samba-3.0.14a/LDAP/samba.schema >
61samba.ldif
# http://www.directory.fedora.redhat.com/download/ol2rhds.pl
This I had covered...
../../restart-slapd
BING. D'Oh! The Big Red Clue Switch right there. Something is obviously
whacked with my init.d/ldap, as it causes/logs slapd start/stop, but isn't
doing it right. I need to look to see if that rc script is a munged
artifact of the old OL install or something (which I was just starting to
do when you emailed). Anyhow, I wasn't using the restart script that was
sitting there in slapd-host staring at me.
ldapsearch -x -h localhost -p myport -s base -b "cn=schema"
"objectclass=*" |
grep -i samba
I get lots of "samba" now. Maybe this thread will help the next wanderer
:)
Thanks!
Jim
9:18 p.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
On Wed, 1 Mar 2006, Jim Hogan wrote:
On Wed, 1 Mar 2006, Richard Megginson wrote:
> ../../restart-slapd
BING. D'Oh! ....
To embarass myself further I can categorically say that it does not help
to restart OpenLDAP slapd if you want FDS to reread your schema :) And I
was wondering why it didn't write to the FDS slapd logs???
I think at one point I took openldap-server off this box, but then...put
it back? And I thought I saw FDS replace the init.d/ldap.
Thanks again.
Jim
9:48 a.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
On Wed, 2006-03-01 at 19:12 -0700, Richard Megginson wrote:
This is what I did:
cd /opt/fedora-ds/slapd-localhost/config/schema
perl ~/ol2rhds.pl < /usr/share/doc/samba-3.0.14a/LDAP/samba.schema >
61samba.ldif
# http://www.directory.fedora.redhat.com/download/ol2rhds.pl
../../restart-slapd
ldapsearch -x -h localhost -p myport -s base -b "cn=schema"
"objectclass=*" | grep -i samba
I just did those exact same steps myself and there does appear to be a
problem. They "MAY" portions of the schema get dropped. Here is the
sambaSamAccount from my converted schema:
objectClasses: (
1.3.6.1.4.1.7165.2.2.6
NAME 'sambaSamAccount'
DESC 'Samba 3.0 Auxilary SAM Account'
SUP top
AUXILIARY
MUST ( uid $ sambaSID )
)
and here is the sambaSamAccount from the /usr/share/doc/ samba.schema:
objectclass ( 1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top
AUXILIARY
DESC 'Samba 3.0 Auxilary SAM Account'
MUST ( uid $ sambaSID )
MAY ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet
$
sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $
sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $
displayName $ sambaHomePath $ sambaHomeDrive $
sambaLogonScript $ sambaProfilePath $ description $
sambaUserWorkstations $
sambaPrimaryGroupSID $ sambaDomainName $ sambaMungedDial
$
sambaBadPasswordCount $ sambaBadPasswordTime $
sambaPasswordHistory $ sambaLogonHours))
Without the 'MAY' portion, when I import my directory dump from
OpenLDAP, any accounts that have any of those samba attributes set (all
of them unfortunately) don't import because of the invalid attributes.
Looks like it's a bug in the ol2rhds.pl script.
--
David Hollis <dhollis(a)davehollis.com>
9:51 a.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
David Hollis wrote:
Without the 'MAY' portion, when I import my directory dump
from
OpenLDAP, any accounts that have any of those samba attributes set (all
of them unfortunately) don't import because of the invalid attributes.
Looks like it's a bug in the ol2rhds.pl script.
Try mine (and Yacine's):
http://www.netauth.com/~jacksonm/ldap/ol-schema-migrate.pl
--
mike
10:05 a.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
On Thu, 2006-03-02 at 17:51 +0200, Mike Jackson wrote:
David Hollis wrote:
> Without the 'MAY' portion, when I import my directory dump from
> OpenLDAP, any accounts that have any of those samba attributes set (all
> of them unfortunately) don't import because of the invalid attributes.
>
> Looks like it's a bug in the ol2rhds.pl script.
Try mine (and Yacine's):
http://www.netauth.com/~jacksonm/ldap/ol-schema-migrate.pl
Looks like that picked up the MAY section nicely.
--
David Hollis <dhollis(a)davehollis.com>
12:58 p.m.
New subject: [Fedora-directory-users] Samba schema not loading in FDS...
Mike Jackson wrote:
Try mine (and Yacine's):
http://www.netauth.com/~jacksonm/ldap/ol-schema-migrate.pl
I should close this loop by pointing out that it was your fine script
that I used to migrate my schema and not the original ol2rhds.pl that I
credited.
Thanks,
Jim
--
/*********************************************************/
Jim Hogan
/*********************************************************/
6624
days inactive
6632
days old
389-users@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
David Hollis -
Jim Hogan -
Mike Jackson -
Pete Rowley -
Rich Megginson -
Scott