[Fedora-directory-devel] problems with VirtualHosts using Apache/mod_nss
by Peter Djalaliev
Hello,
We have Apache configured with a number of virtual hosts, each of them with
a different TLS certificate (all stored in the same NSS database).
There is one VirtualHost named with the IP address of the server (W.X.Y.Z).
The other VirtualHosts were configured for domain names that resolve to IP
address W.X.Y.Z.
Now, if we connect to Apache from a browser using W.X.Y.Z, we get the right
certificate - the one that I specified for the W.X.Y.Z VirtualHost.
However, if we connect using any of the domain names (which all resolve to
W.X.Y.Z), we still get the W.X.Y.Z certificate, instead of the one specified
for that domain's VirtualHost.
Each certificate is created using the IP address or domain name as the
common name. For example, the W.X.Y.Z certificate has W.X.Y.Z as common
name; the certificates for each domain name use the corresponding domain
name as common name.
Can anybody hint me into what we might be doing wrong?
I can post configuration file details, if needed.
Thanks,
Peter
15 years, 9 months
[Fedora-directory-devel] Please Review: (207893) importing users with crypted passwords results in a AD->DS sync loop
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207893
Resolves: bug 207893
Bug Description: Adding a pre-hashed password to DS when using Windows
Password
Syncronization will trigger a loop condition of password updates. The
DS will
send the hashed password to AD, which thinks it's clear-text. AD
stores the
password, attempts to bind to DS using the hash (which of course
fails), so it
sends the hashed password back to DS. This goes round and round.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This fix first checks if there is a password storage
scheme at
the beginning of the userpassword attribute value before syncing it.
If there
is a storage scheme present, a message is logged at the replication
logging level
that this hashed password is being skipped instead of just trying to
sync it.
If someone adds a password with the clear prefix on it to DS (such as
"{clear}secret"), we will detect that and strip off the "{clear}"
prefix before
sending it to AD. All other passwords that start with the "{"
character and
contain the "}" character somewhere else in the password will be
considered to
be already hashed.
Platforms tested: FC6 & Windows 2003 Server
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=172462&action=diff
15 years, 9 months
[Fedora-directory-devel] Please Review: (243221) AD Directory sync fails if attribute 'initials' has too many characters in one of the entries
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243221
Resolves: bug 243221
Bug Description: The directory synchronization between DS and
Active Directory fails if an entry has an initials attribute
containing too many characters. There is no constraint on the
DS side, so the sync should handle this better than failing. It
should ignore the attribute or truncate it and flag a warning,
or skip the invalid entry.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: These diffs address the attribute length constraint
of the "initials" attribute by trimming attribute values larger than
the 6 character limit imposed by AD. This trimming occurs in the
DS -> AD direction only.
What this means is that you can store an initials attribute value of
"longname" in DS, but the value will be trimmed to "longna" when
sent to AD. This trimmed attribute will not be synch'd back to DS
on the next Dirsync operation. This case is handled by only comparing
the first 6 characters of the initials attribute value when changes go
in the AD -> DS direction.
Platforms tested: FC6
Flag Day: no
Doc impact: Yes. We should document the trimming behavior of the
initials attribute.
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=172375&action=diff
15 years, 9 months
[Fedora-directory-devel] Please review: [Bug 253811] RFE: registration tool (register-ds-admin.pl)
by Noriko Hosoi
Summary: RFE: registration tool (register-ds-admin.pl)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253811
Description of problem:
1. if ldap servers are installed at the non-standard location using .inf file
(as quickinstall does), register-ds-admin.pl cannot find them.
2. there should be some way to select ldap servers not to register on the
Configuration Directory Server.
------- Additional Comments From nhosoi(a)redhat.com 2007-08-21 22:09 EST -------
Created an attachment (id=162024)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=162024&action=view)
cvs diff (adminserver)
Files:
admserv/newinst/src/AdminUtil.pm.in
admserv/newinst/src/RegDSDialogs.pm
admserv/newinst/src/register-ds-admin.pl.in
admserv/newinst/src/register-ds-admin.res.in
Change description:
1. Added a question if there is DS located at a non-standard place; if any ask
for the path. The question is repeated till empty input (return) is given.
2. Changed the instances data structure to hash to make the comparison easy to
check whether the path and server instance name pair is already in the hash or
not.
3. When registering the sub DSes, it prompts for the Directory Manager
password. If empty password (return) is given, the server is not registered.
------- Additional Comments From nhosoi(a)redhat.com 2007-08-21 22:27 EST -------
Created an attachment (id=162025)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=162025&action=view)
sample usage
Thanks,
--noriko
15 years, 9 months
[Fedora-directory-devel] Fedora Directory Server Toolkit
by Christian Lahti
Announcing developer release of FDS Tookit
http://fdstools.sourceforge.net
fdstools is a suite of management tools for Fedora Directory Server (FDS)
licensed under the GPL. This includes a perl module which provides and API
for managing all aspects of posix, samba, aix, and computer accounts as well
as automount maps. Additionally command line tools and a Webmin module are
provided that use the API to accomplish all these management tasks. This
project was born mainly because most of the available tools out there are
geared toward managing these objects in OpenLDAP, and there are subtle
differences with FDS. Additionally the (excellent) java console provided
with FDS does not manage shadow, samba, or AIX attributes, and there are
people who do not wish to or cannot run Java on their systems. The design
goals (which most other tools seem to be lacking in one form or another)
are:
- Provide a rich API of functions with very few external dependencies
- Consistent function naming and parameter formats where applicable
- Use and enforce Password Policies if they are specified
- Use and enforce account lockout parameters
- Properly handle error states (i.e. don't DIE in the API, set an
error and return to the client for further handling)
- Provide optional logging of client operations
- Provide command line utilities that use the API to perform
user/group/computer management tasks
- Provide Webmin module that uses the API to perform
user/group/computer management tasks
- Long term goal of providing a lightweight alternative to the java
console for server administrative tasks
Project Status
- The command line portion is feature complete (alpha quality) and we
are seeking testers
- The GUI portion coding is underway
Please see the project page for more information
/Christian
15 years, 9 months
[Fedora-directory-devel] Please Review: (251262) ldap-agent needs to find slapd.stats file dynamically
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251262
Resolves: bug 251262
Bug Description: Our SNMP subagent (ldap-agent) currently requires a
full path to
a DS instance in it's config file. It is hardcoded to look in the log
subdirectory
for the slapd.stats file. It also uses expects a config subdirectory
to find the
dse.ldif. This will no longer work now that DS has been restructured
to follow
FHS standards.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The proposed fix changes the ldap-agent config to
simply expect
the instance name (i.e - slapd-foo). The subagent will then use this
instance
name to load the dse.ldif from the proper location in
$SYSCONFDIR/$PACKAGE_NAME.
The subagent will look up the value of nsslapd-tmpdir to find out
where the
slapd.stats file is for that particular instance. I also improved the
error
checking around processing the ldap-agent config file.
Platforms tested: FC6
Flag Day: no
Doc impact: Yes. A bug will be opened to change the documentation of
the ldap-agent "server" config parameter.
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=160867&action=diff
15 years, 10 months
[Fedora-directory-devel] Please Review: (251418) Add header and footer support to help.cgi
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251418
Resolves: bug 251418
Bug Description: The current help.cgi in Admin Server simply looks
up tokens in a map file and returns the contents of the html file
that the mapping points to. This works ok, but the online help
for a product may have 100+ different help html files. Each of
these files contains the same html header and footer (or at least
they should for a consistent look). It would be much better to
have separate header and footer html files that are always
prepended and appended to the help html that the user requested.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The proposed fix expects the online help directory
for each product to have a header.htm and footer.htm alongside it's
token.map file. These files will be combined with the requested
help topic and returned to the client via the help.cgi. This will
allow us to simplify our many online help html files so we only
have to worry about the actual content.
Platforms tested: FC6
Flag Day: no
Doc impact:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=160940&action=diff
15 years, 10 months