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.
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 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' )
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 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
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 Rowley <prowley <at> redhat.com> writes:
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
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.
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 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
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
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
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 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
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):
Looks like that picked up the MAY section nicely.
Mike Jackson wrote:
Try mine (and Yacine's):
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
389-users@lists.fedoraproject.org
-
David Hollis -
Jim Hogan -
Mike Jackson -
Pete Rowley -
Rich Megginson -
Scott