Fedora directory users - Feb 2006 - Cos? or plug-in issue?

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

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

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

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                   jimh *A T* u *DO T* washington *D OT* edu
/*********************************************************/

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 <dhollis@davehollis.com>

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):
> 
> http://www.netauth.com/~jacksonm/ldap/ol-schema-migrate.pl
> 
Looks like that picked up the MAY section nicely.
-- 
David Hollis <dhollis@davehollis.com>

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                  

/*********************************************************/