[Fedora-directory-users] Question about setting a Password Policy from the Command Line
by Eric Brown
I am trying to create an LDIF for importing a default password policy
for my FDS server that I can quickly import after I start it. I was
looking through the Adminstrator's Guide and it seems to be missing
some fields that are defined in the objectclass for password policy.
I was just wondering if the Admin guide was correct and has all of the
defined attributes for the policy there and defined, or if these extra
ones are also valid and have documentation associated with them. I am
using the 1.0.4 version of FDS and I would guess that they online
guides have been updated for the newer versions, but I didn't expect
to see this much of a difference.
Attributes from the Admin Guide:
passwordGraceLimit
passwordMustChange
passwordChange
passwordExp
passwordMaxAge
passwordWarning
passwordCheckSyntax
passwordMinLength
passwordMinAge
passwordHistory
passwordInHistory
passwordStorageScheme
Attributes from the 00core.ldif schema definition of the password
policy objectclass:
passwordMaxAge
passwordExp
passwordMinLength
passwordKeepHistory
passwordInHistory
passwordChange
passwordWarning
passwordLockout
passwordMaxFailure
passwordResetDuration
passwordUnlock
passwordLockoutDuration
passwordCheckSyntax
passwordMustChange
passwordStorageScheme
passwordMinAge
passwordResetFailureCount
passwordGraceLimit
passwordMinDigits
passwordMinAlphas
passwordMinUppers
passwordMinLowers
passwordMinSpecials
passwordMin8bit
passwordMaxRepeats
passwordMinCategories
passwordMinTokenLength
Just need to know which list is really valid, and I need the
documentation or at least explanations of the fields that I can use in
my version. Thanks in advance.
Eric
15 years, 8 months
[Fedora-directory-users] altServer
by Del
Hi,
Is there any plan to support the altServer attribute in the root DSE of
a Fedora Directory Server?
By that I mean that the server should advertise its list of replicas
(currently buried under cn=replica,cn="BASEDN",cn=mapping tree,cn=config
for each base DN) in the root DSE using the altServer attribute? This
would make it easier to build resilient clients that automatically knew
where to reconnect to if the primary server went down.
--
Del
Babel Com Australia
http://www.babel.com.au/
ph: 02 9966 9476
fax: 02 9906 2864
15 years, 8 months
[Fedora-directory-users] Using Console, posixGroups
by Hendry, Chris
Sorry if this has been asked before.
I'm using FDS to authenticate Linux and Mac.
Mac uses the LDAP Mappings: RFC 2307, thus to get what groups a users is
a part of, it looks at the attribute memberUid from posixGroup Class.
When using the console to create a group, by default, it uses the
attribute uniquemember from the groupOfUniquNames class. Thus I have
to add the posixGroup class manually using the advance button. Also, to
modify users of a group, I can not simply use the memberof window, must
use the advanced button to modify the memberUid attribute.
This does not make much sense. Adding a group should be like adding a
User, where you have a window to enable Posix attributes. Any ideas on
getting the console to handle the posixGroup class?
Chris
15 years, 8 months
[Fedora-directory-users] Re: Case Sensitive Lookup and Searching (Mike C)
by Howard Chu
> Date: Tue, 8 Jul 2008 10:16:09 +1200
> From: "Mike C"<smith.not.western(a)gmail.com>
> I agree, my schema (and data) are terrible. It's an artifact from
> openldap not being as conforming as fds.
Ahem. OpenLDAP conforms perfectly to the LDAPv3 spec here. The behavior you're
seeing with FDS is due to the fact that the FDS code base doesn't have full
LDAPv3 schema support. Rich's reference to ces and cis is an artifact of the
way the old UMich LDAPv2 code kludged schemas, and his mention of "case
sensitive syntax" is archaic. In X.500 and LDAPv3, string syntaxes have no
case sensitivity property at all; case sensitivity is determined solely by the
matching rules in the schema definition of the attribute using the syntax. The
only difference between IA5String and DirectoryString syntax is the range of
legal characters that may be contained in the string (DirectoryString
accomodates the entire Unicode set in UTF8 encoding, IA5String only allows 7
bit ASCII).
> My main concern is that sanitizing my repository would require
> changing usernames for a hundred odd external users, something I wish
> to avoid. But given how memberUid's case sensitivity is nullified when
> part of a dn, migration it is.
In a true LDAP/X.500 server, DN evaluation obeys all of the schema rules of
the individual attributes in each RDN composing the DN. E.g. in OpenLDAP,
memberUid is case-sensitive whether it's being used in a RDN or anywhere else.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 8 months
[Fedora-directory-users] Samba/FDS Integration upgrade steps?
by Ken Marsh
I am planning an upgrade on a supported RHES4 server from Samba
3.0.10-1.4E to 3.0.25b or the latest in the RHN update stream. I
currently have Samba authentication integrated with AD through FDS
1.0.1-4, only because FDS 1.1 doesn't run on RHES4. I have single
sign-on but not integrated password changes for Windows XP Domain users.
Every Samba+FDS user currently has objectClass attribute
sambasamaccount, and attributes sambaSID, sambaAcctFlags,
sAMAccountName, sambaLMPassword and sambaNTPassword.
According to Red Hat support (who cannot help me much because they only
support OpenLDAP), there is a "schema change" and a script to convert
the schema, however they did not know where the script was or its name.
I also noticed during an attempt to upgrade that the SambaSID has
changed format in 3.0.25b so I suppose I have to change that attribute
value for every user.
Can someone name the conversion script and lay out the steps that it
will take to get me from 3.0.10-1.4E to 3.0.25b/later while maintaining
AD integration? If it involves upgrading to FDS1.1, I can handle that,
but I'd rather do one thing at a time. If there are any side benefits
(like single password change) I'd also like to know.
Thanks,
Ken.
15 years, 8 months
[Fedora-directory-users] Case Sensitive Lookup and Searching
by Mike C
Hi,
I'm running Fedora-Directory/1.0.2 B2006.111.2147, and talking to it
via a Java App. Previously the app was talking to an OpenLDAP 2.3.x
server.
My problem is with this:
Object o = ctx.lookup("memberUid=steves,ou=People");
In OpenLDAP, it returns the correct user (steves). In FDS, it returns
the wrong user, 'Steves'. Yes, unfortunately our data is like that,
where case sensitivity is important. In fact, as a side issue, when we
import the data from ldif into FDS, the ldif2db process ignores
duplicate entries (i.e. steves was inserted, but Steves ignored as it
was considered a duplicate).
ldif2db Error: import company: WARNING: Skipping duplicate entry
"memberUid=steves,ou=People,o=company.com"
As you might imagine, I'd like to get it so both ldif2db and lookups
are case sensitive. However, it seems like ldapsearch is case
sensitive.
# ./ldapsearch -h 127.0.0.1 -b "o=company.com" memberUid=steves
# ./ldapsearch -h 127.0.0.1 -b "o=company.com" memberUid=Steves
version: 1
dn: memberUid=Steves,ou=People,o=company.com
personalTitle: Mr
etc...
So, the question goes, what am I missing? I've even tried changing the
definition of memberUid in config/schema/10rfc2307.ldif to use
attributeTypes: (
1.3.6.1.1.1.1.12
NAME 'memberUid'
DESC 'Standard LDAP attribute type'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String'
)
Ideas?
Thanks,
Mike
15 years, 8 months
[Fedora-directory-users] active directory synchronization info
by omight
Hi List,
Does fedora-ds only synchronize users, groups and passwords with
active directory?
So it's not possible to synchronize other objects?
Is it possible to synchronize all objects between active directory and
linux directory software? Which product do you recommend?
thanks heaps,
Omight
15 years, 8 months
[Fedora-directory-users] A multi-master disaster
by Edward Capriolo
Sorry for the funny title. I THINK* this may be a bug of multi-master
replication agreement created from the Windows Version of the Console
Tool but I was hoping someone could shed some light on this. I have
set up multi master replication before and did not run into this
issue.
I go about the normal process described in the documentation to setup
a multi-master replication agreement for only one suffix of my
directory server. dc_edops_dc_com.
Enable changelog
Select multi-master replication
Give each server a unique id
I initialize the side of the connection with data. (I also have tried
using ldif to get both sides in sync before the transfer. )
On the side I initialize from I get these messages in the error log.
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Workers
finished; cleaning up...
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Workers cleaned up.
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Cleaning up
producer thread...
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Indexing
complete. Post-processing...
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Flushing caches...
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Closing files...
[02/Jul/2008:18:25:19 -0400] - import dc_edops_dc_com: Import
complete. Processed 42 entries in 2 seconds. (21.00 entries/sec)
[02/Jul/2008:18:25:19 -0400] NSMMReplicationPlugin -
multimaster_be_state_change: replica dc=edops,dc=com is coming online;
enabling replication
[02/Jul/2008:18:25:20 -0400] NSMMReplicationPlugin -
repl_set_mtn_referrals: could not set referrals for replica
dc=edops,dc=com : 32
At this point actually multi-master replication is enabled, but the B
side of the connection has some strange referral to the A side. When I
connect to side B of the replication it seems like there is one more
level there.
Does anyone understand why this simple setup would not be working?
15 years, 8 months
[Fedora-directory-users] Question about setting a Password Policy from the Command Line
by Eric Brown
I am trying to create an LDIF for importing a default password policy
for my FDS server that I can quickly import after I start it. I was
looking through the Adminstrator's Guide and it seems to be missing
some fields that are defined in the objectclass for password policy.
I was just wondering if the Admin guide was correct and has all of the
defined attributes for the policy there and defined, or if these extra
ones are also valid and have documentation associated with them. I am
using the 1.0.4 version of FDS and I would guess that they online
guides have been updated for the newer versions, but I didn't expect
to see this much of a difference.
Attributes from the Admin Guide:
passwordGraceLimit
passwordMustChange
passwordChange
passwordExp
passwordMaxAge
passwordWarning
passwordCheckSyntax
passwordMinLength
passwordMinAge
passwordHistory
passwordInHistory
passwordStorageScheme
Attributes from the 00core.ldif schema definition of the password
policy objectclass:
passwordMaxAge
passwordExp
passwordMinLength
passwordKeepHistory
passwordInHistory
passwordChange
passwordWarning
passwordLockout
passwordMaxFailure
passwordResetDuration
passwordUnlock
passwordLockoutDuration
passwordCheckSyntax
passwordMustChange
passwordStorageScheme
passwordMinAge
passwordResetFailureCount
passwordGraceLimit
passwordMinDigits
passwordMinAlphas
passwordMinUppers
passwordMinLowers
passwordMinSpecials
passwordMin8bit
passwordMaxRepeats
passwordMinCategories
passwordMinTokenLength
Just need to know which list is really valid, and I need the
documentation or at least explanations of the fields that I can use in
my version. Thanks in advance.
Eric
15 years, 8 months