[Fedora-directory-users] sendmail alias in fds
by basile
here are mail.log :
Feb 24 12:25:30 sorbon2 sendmail[2222]: [ID 293258 mail.error] libsldap:
Status: 91 Mesg: Error 0
Feb 24 12:25:30 sorbon2 sendmail[2222]: [ID 293258 mail.error] libsldap:
Status: 91 Mesg: Bad file number
Feb 24 12:25:30 sorbon2 sendmail[2222]: [ID 293258 mail.error] libsldap:
Status: 7 Mesg: Session error no available
conn.
Feb 24 12:25:30 sorbon2 sendmail[2222]: [ID 801593 mail.warning]
k1OBPLbV002222: forward /dev/null/.forward: World writable directory
Feb 24 12:25:39 sorbon2 sendmail[2223]: [ID 801593 mail.notice]
k1OBPavK002223: alain.lierre@sorbon2.sorbonne.fr... User unknown
basile
18 years, 3 months
[Fedora-directory-users] Extending the Schema
by Scott Boggs
I used another thread to discuss forcing the schema to adhear to
caseSensitivity. As pointed out by the responses from many of the FDS vets out
there, breaking the RFC would be bad. I am looking for another solution to
enforcing exact matches for my users during the login process (non-case
specific). This is strictly to support site security policy and not a result of
any application integration.
To stay in compliance with RFC standards and to save myself headaches down the
road, I need to know if I can change the syntax for the attribute 'uid' to
follow something like distinguishedNameMatch for attribute type specification or
is there another method to match uid exactly (i.e uid=Test where "Test" not
"test" must be used to login).
Would applying the schema in this manner violate any RFC standards? Again I am
simply trying to enforce a exact character input during login and not trying to
change LDAP to enforce any form of case matching.
Thanks for all the help on this question.
18 years, 3 months
[Fedora-directory-users] Looking for expanded upgrade to 1.0 procedure
by Darren Fulton - CTI
We've been running FDS beta in production for a while now. I'd like to upgrade to 1.0 and then get current, especially because after the last reboot, the admin-serv won't run anymore. The only upgrade instructions that I've been able to find are at the bottom of the 1.0 Release Notes:
Unfortunately, rpm -U (rpm upgrade install) is not supported. You must perform a migration from the old version. Steps:
1. Backup your data, using the console or the db2bak command line (or Export to LDIF)
2. Make a copy of your server configuration - the slapd-instance/config/dse.ldif file
3. Backup your key/cert/module information - the /opt/fedora-ds/alias .db files (you can ignore the .so file)
4. Uninstall the previous version (e.g. rpm -e fedora-ds)
5. Install the new version (e.g. rpm -ivh fedora-ds-1.0-2.platform.i386.opt.rpm)
6. Add back your configuration to the new instance e.g. do a diff between your saved dse.ldif and the new one
7. Add back your saved key/cert/module .db files to /opt/fedora-ds/alias
8. Restore your saved data (or import from LDIF)
These notes aren't enough detail for me to get the job done. Is there a detailed procedure somewhere or can one of you good people help me? I've looked through the mailing list archives, FDS docs, RHDS docs, and googled. I'd like something like this:
mkdir /var/backup/fds
cd /opt/fedora-ds/slapd-host2
./db2bak /var/backup/fds
blah blah
rpm -e fedora-ds
etc etc
Specific things in the upgrade steps from the release notes that I don't feel good about are:
Step 1 - I don't know how to do that, but I think I might have done it correctly.
Step 4 - after rpm -e, it says some files may not have been removed and to remove them manually. Do you do rm -Rf /opt/fedora-ds?
Step 6 - I don't know how to do that
Step 8 - I don't know how to do that
Thanks in advance!
--
Best Regards,
Darren Fulton
18 years, 3 months
[Fedora-directory-users] solaris 10 SSL connections
by Susan
Hi, all. I've ssl enabled in FDS:
# ldapsearch -D "cn=Directory Manager" -w adminpass -b "cn=encryption,cn=config" -h cnyitlin02
cn=*
version: 1
dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: on
nsSSL3Ciphers: +rsa_rc4_128_md5,+rsa_3des_sha,+fortezza_null,-rsa_null_md5,+fo
Currently, I have authenticationMethod: simple in my default profile. I can ssh/telnet w/o
problems, authenticating from FDS (thank you, Gary Tay!)
I've been having a real hard time getting Solaris SSL to work, however. I did the whole mozilla
cert import thing, got the cert8.db (it's not 7), and key3.db, put them in /var/ldap
However, even though this returns data:
-bash-3.00# ldapsearch -b "dc=composers,dc=company,dc=com" -h cnyitlin02 -L "objectclass=*" -p
636 -Z
version: 1
dn: dc=composers,dc=company,dc=com
dn: cn=Directory Administrators, dc=composers,dc=company,dc=com
dn: ou=Groups, dc=composers,dc=company,dc=com
dn: ou=People, dc=composers,dc=company,dc=com
dn: ou=profile,dc=composers,dc=company,dc=com
dn: cn=proxyAgent,ou=profile,dc=composers,dc=company,dc=com
dn: uid=test, ou=People, dc=composers,dc=company,dc=com
It's not encrypted. I can see the traffic clear text in ethereal.
Any ideas what the problem is? Has anybody gotten solaris ssl to work with FDS?
Thank you.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
18 years, 3 months
[Fedora-directory-users] self-signed certificates
by Dan Lipsitt
It appears that the setup utility now creates self-signed certificates
in the alias directory, making the certutil instructions moot. Is that
correct? My alias directory contains the following files:
------
$ cd /opt/fedora-ds/alias/
$ ls -la
total 420
drwxr-xr-x 2 nobody nobody 4096 Feb 21 17:16 .
drwxr-xr-x 15 root root 4096 Feb 21 16:57 ..
-rw------- 1 nobody nobody 65536 Feb 21 17:16 admin-serv-roam104-178-cert8.db
-rw------- 1 nobody nobody 16384 Feb 21 17:16 admin-serv-roam104-178-key3.db
-rwxr-xr-x 1 root nobody 196340 Dec 8 11:04 libnssckbi.so
-rw------- 1 nobody nobody 16384 Feb 21 16:57 secmod.db
-rw------- 1 nobody nobody 65536 Feb 21 16:57 slapd-roam104-178-cert8.db
-rw------- 1 nobody nobody 16384 Feb 21 16:57 slapd-roam104-178-key3.db
------
I didn't create any of these files myself.
My problem is that no certificate shows up in the drop-down menu under
Encryption in the Admin Server console.
As you can see, my hostname has a dash in it. Could that be causing
problems? Or do I need to use certutil manually?
Thanks,
Dan
18 years, 3 months
RE: [Fedora-directory-users] Fedora directory server remote denial of server
by Bliss, Aaron
Great, thanks for the quick feedback.
Aaron
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
Megginson
Sent: Tuesday, February 21, 2006 2:07 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Fedora directory server remote
denial of server
Bliss, Aaron wrote:
>Can you tell me if fds 1.0.1 is affected by this?
>
Yes.
>If so, any near plans
>for a fix. Thanks.
>
>
Yes. We are going to be fixing this very, very soon.
>Aaron
>
>http://www.securityfocus.com/bid/16677
>
>www.preferredcare.org
>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>Power and Associates
>
>Confidentiality Notice:
>The information contained in this electronic message is intended for
the exclusive use of the individual or entity named above and may
contain privileged or confidential information. If the reader of this
message is not the intended recipient or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that dissemination, distribution or copying of this information
is prohibited. If you have received this communication in error, please
notify the sender immediately by telephone and destroy the copies you
received.
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
[Fedora-directory-users] Fedora directory server remote denial of server
by Bliss, Aaron
Can you tell me if fds 1.0.1 is affected by this? If so, any near plans
for a fix. Thanks.
Aaron
http://www.securityfocus.com/bid/16677
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
[Fedora-directory-users] Username Case Sensitivity
by Scott
I am curious; I understand that LDAP does not enforce case sensitivity for
user names or passwords.
However, I am wondering if there is a method to enforce such a policy on
fedora-ds? I noticed the behavior earlier this week and it reminded me this
behavior in LDAP. I am using a older version of fds, any chance the newer
version addresses this?
Tks
18 years, 3 months
RE: [Fedora-directory-users] Some password policy enforcement information questions
by Bliss, Aaron
Yep, this issue occurs over ssh.
Aaron
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
Megginson
Sent: Monday, February 20, 2006 10:08 AM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Some password policy enforcement
information questions
Bliss, Aaron wrote:
>Some more trouble with password expiration warnings; I have passwords
>warnings being displayed to users when they use passwords, however
>users configured to use key authentication
>
Do you mean ssh?
>do not receive this warnings; has
>anyone seen this before? This is of course going to be a very big
>problem for me. Any ideas? Thanks again.
>
>
>Aaron
>
>-----Original Message-----
>From: Bliss, Aaron
>Sent: Wednesday, January 25, 2006 7:48 PM
>To: General discussion list for the Fedora Directory server project.
>Subject: RE: [Fedora-directory-users] Some password policy enforcement
>information questions
>
>Turns out the issue I was having was with my clients; I'm not sure why,
>but the administrator before me had "UseLogin Yes" set in
>/etc/ssh/sshd_config; commenting this out immediately started
>generating password warnings to users (as configured by the directory
>server); does anyone know what the UseLogin option is used for?
Thanks.
>
>Aaron
>
>-----Original Message-----
>From: Bliss, Aaron
>Sent: Thursday, January 19, 2006 3:15 PM
>To: 'General discussion list for the Fedora Directory server project.'
>Subject: RE: [Fedora-directory-users] Some password policy enforcement
>information questions
>
>Thanks very much for the explanation; makes much sense to me now; I did
>some playing around, and got the directory server to spit out to me
>that your password is going to expire in x amount of days. Thanks
again.
>
>Aaron
>
>-----Original Message-----
>From: fedora-directory-users-bounces(a)redhat.com
>[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
>Megginson
>Sent: Thursday, January 19, 2006 2:35 PM
>To: General discussion list for the Fedora Directory server project.
>Subject: Re: [Fedora-directory-users] Some password policy enforcement
>information questions
>
>It looks like the way it works is this:
>When you have enabled password warning, an operational attribute called
>"passwordExpWarned" is created in the user's entry. The value will be
>0 until the user does a successful BIND operation and the time between
>now and the configured password expiration time is less than or equal
>to the configured password warning time. When this happens, the
>warning will be sent, the value of passwordExpWarned will be changed to
>1, and the operational attribute passwordExpirationTime in the user's
>entry will be set to the time at which the password will expire. When
>the user changes the password, passwordExpWarned will be reset to 0 and
>passwordExpirationTime will be set to the new expiration time.
>
>Bliss, Aaron wrote:
>
>
>
>>If I've configured a correct password policy and the warning attribute
>>is not getting updated, should this be considered a bug?
>>
>>Aaron
>>
>>-----Original Message-----
>>From: fedora-directory-users-bounces(a)redhat.com
>>[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of
>>Richard
>>
>>
>
>
>
>>Megginson
>>Sent: Thursday, January 19, 2006 1:48 PM
>>To: General discussion list for the Fedora Directory server project.
>>Subject: Re: [Fedora-directory-users] Some password policy enforcement
>>information questions
>>
>>Bliss, Aaron wrote:
>>
>>
>>
>>
>>
>>>Please forgive me if I'm asking silly newbie questions, however I'm
>>>trying to understand exactly what I'm seeing thru fds; first the
>>>policy
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>I've configured on the directory using the fds console:
>>>I've enabled fine-grain password policy for the data unit, including
>>>password history enforcement, password expiration after 90 days,
>>>password warning 14 days before password expires, check password
>>>syntax, account lockout policy enabled after 3 login failures for 120
>>>minutes and reset failure count after 15 minutes.
>>>
>>>Everything seems to be working except for send password warning; in
>>>
>>>
>the
>
>
>>>client's ldap.conf file, I've enabled pam_lookup_policy yes.
>>>
>>>Looking at account information attributes for a user,
>>>passwordexpwarnd
>>>
>>>
>
>
>
>>>value is 0; I've reset users password to try to initialize the
>>>password
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>policy, however this value never seems to change. According to this
>>>documentation
>>>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#10
>>>7
>>>7
>>>0
>>>81 I believe that this attribute is stored in seconds. Is this true?
>>>
>>>
>>>
>>>
>>>
>>>
>>Yes.
>>
>>
>>
>>
>>
>>>If so, what can I do to ensure this attribute is getting updated
>>>(assuming that this is the attribute responsible for triggering
>>>password expiration warning).
>>>
>>>
>>>
>>>
>>>
>>>
>>I'm not really sure.
>>
>>
>>
>>
>>
>>>Second issue/question:
>>>I've looked at this wiki
>>>http://directory.fedora.redhat.com/wiki/Howto:PAM and near the very
>>>bottom it mentions adding the following
>>>
>>>dn: cn=config
>>>changetype: modify
>>>add: passwordExp
>>>passwordExp: on
>>>-
>>>add: passwordMaxAge
>>>passwordMaxAge: 8640000 (this I believe would give a password max age
>>>of 100 days)
>>>
>>>Do I need to add these attributes even though I've configured the
>>>password policy using fds console has done this for me. Is this the
>>>case, I see don't these attributes in the gui, however I do see
>>>passwordexpirationtime as an attribute and is set to 90 days from now
>>>(I'm want to ensure that accounts are indeed locked after passwords
>>>have expired).
>>>
>>>
>>>
>>>
>>>
>>>
>>Those attributes are only for global (default) password policy - what
>>you have set for fine grained password policy will override those.
>>
>>
>>
>>
>>
>>>Also, Jim Summers posted to this group that he saw an issue with
>>>shadowpasswd / shadowexpire fields not being updated
>>>https://www.redhat.com/archives/fedora-directory-users/2005-December/
>>>m
>>>s
>>>g
>>>00367.html
>>>
>>>Can anyone tell me what these fields are used for, as I don't see any
>>>mention of them in this documentation
>>>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#10
>>>7
>>>7
>>>0
>>>81
>>>
>>>
>>>
>>>
>>>
>>>
>>Right. They are a PAM/posix thing - FDS treats them as any other data
>>- it doesn't update them from it's own password policy.
>>
>>
>>
>>
>>
>>>Thanks again very much.
>>>
>>>Aaron
>>>
>>>
>>>
>>>
>>>www.preferredcare.org
>>>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>>>Power and Associates
>>>
>>>Confidentiality Notice:
>>>The information contained in this electronic message is intended for
>>>
>>>
>>>
>>>
>>the exclusive use of the individual or entity named above and may
>>contain privileged or confidential information. If the reader of this
>>message is not the intended recipient or the employee or agent
>>responsible to deliver it to the intended recipient, you are hereby
>>notified that dissemination, distribution or copying of this
>>information is prohibited. If you have received this communication in
>>error, please notify the sender immediately by telephone and destroy
>>the copies you received.
>>
>>
>>
>>
>>>--
>>>Fedora-directory-users mailing list
>>>Fedora-directory-users(a)redhat.com
>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>>
>>>
>>>
>>>
>>www.preferredcare.org
>>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>>Power and Associates
>>
>>Confidentiality Notice:
>>The information contained in this electronic message is intended for
>>
>>
>the exclusive use of the individual or entity named above and may
>contain privileged or confidential information. If the reader of this
>message is not the intended recipient or the employee or agent
>responsible to deliver it to the intended recipient, you are hereby
>notified that dissemination, distribution or copying of this
>information is prohibited. If you have received this communication in
>error, please notify the sender immediately by telephone and destroy
>the copies you received.
>
>
>>--
>>Fedora-directory-users mailing list
>>Fedora-directory-users(a)redhat.com
>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>>
>
>
>www.preferredcare.org
>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>Power and Associates
>
>Confidentiality Notice:
>The information contained in this electronic message is intended for
the exclusive use of the individual or entity named above and may
contain privileged or confidential information. If the reader of this
message is not the intended recipient or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that dissemination, distribution or copying of this information
is prohibited. If you have received this communication in error, please
notify the sender immediately by telephone and destroy the copies you
received.
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months
RE: [Fedora-directory-users] Some password policy enforcement information questions
by Bliss, Aaron
Some more trouble with password expiration warnings; I have passwords
warnings being displayed to users when they use passwords, however users
configured to use key authentication do not receive this warnings; has
anyone seen this before? This is of course going to be a very big
problem for me. Any ideas? Thanks again.
Aaron
-----Original Message-----
From: Bliss, Aaron
Sent: Wednesday, January 25, 2006 7:48 PM
To: General discussion list for the Fedora Directory server project.
Subject: RE: [Fedora-directory-users] Some password policy enforcement
information questions
Turns out the issue I was having was with my clients; I'm not sure why,
but the administrator before me had "UseLogin Yes" set in
/etc/ssh/sshd_config; commenting this out immediately started generating
password warnings to users (as configured by the directory server); does
anyone know what the UseLogin option is used for? Thanks.
Aaron
-----Original Message-----
From: Bliss, Aaron
Sent: Thursday, January 19, 2006 3:15 PM
To: 'General discussion list for the Fedora Directory server project.'
Subject: RE: [Fedora-directory-users] Some password policy enforcement
information questions
Thanks very much for the explanation; makes much sense to me now; I did
some playing around, and got the directory server to spit out to me that
your password is going to expire in x amount of days. Thanks again.
Aaron
-----Original Message-----
From: fedora-directory-users-bounces(a)redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
Megginson
Sent: Thursday, January 19, 2006 2:35 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] Some password policy enforcement
information questions
It looks like the way it works is this:
When you have enabled password warning, an operational attribute called
"passwordExpWarned" is created in the user's entry. The value will be 0
until the user does a successful BIND operation and the time between now
and the configured password expiration time is less than or equal to the
configured password warning time. When this happens, the warning will
be sent, the value of passwordExpWarned will be changed to 1, and the
operational attribute passwordExpirationTime in the user's entry will be
set to the time at which the password will expire. When the user
changes the password, passwordExpWarned will be reset to 0 and
passwordExpirationTime will be set to the new expiration time.
Bliss, Aaron wrote:
>If I've configured a correct password policy and the warning attribute
>is not getting updated, should this be considered a bug?
>
>Aaron
>
>-----Original Message-----
>From: fedora-directory-users-bounces(a)redhat.com
>[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Richard
>Megginson
>Sent: Thursday, January 19, 2006 1:48 PM
>To: General discussion list for the Fedora Directory server project.
>Subject: Re: [Fedora-directory-users] Some password policy enforcement
>information questions
>
>Bliss, Aaron wrote:
>
>
>
>>Please forgive me if I'm asking silly newbie questions, however I'm
>>trying to understand exactly what I'm seeing thru fds; first the
>>policy
>>
>>
>
>
>
>>I've configured on the directory using the fds console:
>>I've enabled fine-grain password policy for the data unit, including
>>password history enforcement, password expiration after 90 days,
>>password warning 14 days before password expires, check password
>>syntax, account lockout policy enabled after 3 login failures for 120
>>minutes and reset failure count after 15 minutes.
>>
>>Everything seems to be working except for send password warning; in
the
>>client's ldap.conf file, I've enabled pam_lookup_policy yes.
>>
>>Looking at account information attributes for a user, passwordexpwarnd
>>value is 0; I've reset users password to try to initialize the
>>password
>>
>>
>
>
>
>>policy, however this value never seems to change. According to this
>>documentation
>>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#107
>>7
>>0
>>81 I believe that this attribute is stored in seconds. Is this true?
>>
>>
>>
>>
>Yes.
>
>
>
>>If so, what can I do to ensure this attribute is getting updated
>>(assuming that this is the attribute responsible for triggering
>>password expiration warning).
>>
>>
>>
>>
>I'm not really sure.
>
>
>
>>Second issue/question:
>>I've looked at this wiki
>>http://directory.fedora.redhat.com/wiki/Howto:PAM and near the very
>>bottom it mentions adding the following
>>
>>dn: cn=config
>>changetype: modify
>>add: passwordExp
>>passwordExp: on
>>-
>>add: passwordMaxAge
>>passwordMaxAge: 8640000 (this I believe would give a password max age
>>of 100 days)
>>
>>Do I need to add these attributes even though I've configured the
>>password policy using fds console has done this for me. Is this the
>>case, I see don't these attributes in the gui, however I do see
>>passwordexpirationtime as an attribute and is set to 90 days from now
>>(I'm want to ensure that accounts are indeed locked after passwords
>>have expired).
>>
>>
>>
>>
>Those attributes are only for global (default) password policy - what
>you have set for fine grained password policy will override those.
>
>
>
>>Also, Jim Summers posted to this group that he saw an issue with
>>shadowpasswd / shadowexpire fields not being updated
>>https://www.redhat.com/archives/fedora-directory-users/2005-December/m
>>s
>>g
>>00367.html
>>
>>Can anyone tell me what these fields are used for, as I don't see any
>>mention of them in this documentation
>>http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#107
>>7
>>0
>>81
>>
>>
>>
>>
>Right. They are a PAM/posix thing - FDS treats them as any other data
>- it doesn't update them from it's own password policy.
>
>
>
>>Thanks again very much.
>>
>>Aaron
>>
>>
>>
>>
>>www.preferredcare.org
>>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>>Power and Associates
>>
>>Confidentiality Notice:
>>The information contained in this electronic message is intended for
>>
>>
>the exclusive use of the individual or entity named above and may
>contain privileged or confidential information. If the reader of this
>message is not the intended recipient or the employee or agent
>responsible to deliver it to the intended recipient, you are hereby
>notified that dissemination, distribution or copying of this
>information is prohibited. If you have received this communication in
>error, please notify the sender immediately by telephone and destroy
>the copies you received.
>
>
>>--
>>Fedora-directory-users mailing list
>>Fedora-directory-users(a)redhat.com
>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>>
>
>
>www.preferredcare.org
>"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>Power and Associates
>
>Confidentiality Notice:
>The information contained in this electronic message is intended for
the exclusive use of the individual or entity named above and may
contain privileged or confidential information. If the reader of this
message is not the intended recipient or the employee or agent
responsible to deliver it to the intended recipient, you are hereby
notified that dissemination, distribution or copying of this information
is prohibited. If you have received this communication in error, please
notify the sender immediately by telephone and destroy the copies you
received.
>
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users(a)redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
www.preferredcare.org
"An Outstanding Member Experience," Preferred Care HMO Plans -- J. D. Power and Associates
Confidentiality Notice:
The information contained in this electronic message is intended for the exclusive use of the individual or entity named above and may contain privileged or confidential information. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that dissemination, distribution or copying of this information is prohibited. If you have received this communication in error, please notify the sender immediately by telephone and destroy the copies you received.
18 years, 3 months