I've got the Fedora LDAP service running, connecting from other Linux server is
no problem.
the next step is to sunchronize the database to Active Directory.
Is there a way to keep my Fedora LDAP as a master database and the AD server
(W2003) as a member.
So that i should only configure my users
Hi,
Did you enable SSL on FDS and AD? It must be enabled for sync works.
Information is avaiable on FDS documentation page.
Paulo Estrela
- Original Message -
From: Michiel van Heukelom - Van Boxtel Software BV
To: fedora-directory-users@redhat.com
Sent: Friday, March 30, 200
On 3/27/07, Peter Biggerstaff <[EMAIL PROTECTED]>
wrote:
Is it possible to use Fedora DS as a windows PDC? so I can manage windows
and Linux clients from the same directory?
FDS by itself cannot serve as a Windows PDC; that's well outside the scope
of what it's designed to do.
Samba is desi
This is not true. You don't need SSL if AD will be a true slave. SLL is only
required if you want to allow users to change their passwords on AD and have
that propagated to FDS.
-Auggy
Paulo Estrela - Suporte LabInfo UNIFACS wrote:
Hi,
Did you enable SSL on FDS and AD? It must be enabled f
On 3/28/07, Coe, Colin C. (Unix Engineer) <[EMAIL PROTECTED]> wrote:
No, I'm not 100% sure that the clients are set right. My sanitised
/etc/ldap and /etc/openldap/ldap.conf are shown above. Can you suggest
any improvements to them?
We're using RHEL 3 and CentOS 4 with ldap.conf files pretty
Well, I have succeeding in getting SSL going and the howto is very
helpful for this:
http://directory.fedora.redhat.com/wiki/Howto:SSL
and in particular the script: setupssl.sh
http://directory.fedora.redhat.com/download/setupssl.sh
In doing so I came across a number of gotchas which might help ot
Hi Noriko, thanks for you reply.
On Thu, 29 Mar 2007, Noriko Hosoi wrote:
Ville Silventoinen wrote:
Same error for ancestorid.db4, objectclass.db4, parentid.db4, cn.db4,
givenName.db4 and sn.db4.
How about id2entry.db4? Is it broken? (It's a primary db file.)
No, id2entry.db4 is Good.
Hello, again! I'm trying to install Fedora DS 1.0.4 on Red Hat EL4.
Everything goes smoothly until I try to enable SSL in the admin server
console. When I try to save new settings on the Encryption tab and the User
DS tab, I get a message, "PSET failure. PSET attribute creation or local
cach
Or maybe it's not so complicated and I don't know how. ;)
This is what I'm trying to accomplish:
Users who are a member of the group 'cn=support'
can perform ALL operations on 'userPassword',
except on targets which are a member of group 'cn=admins' or 'cn=bosses'.
Is this possible? I can't fi
I've noticed that the 'ip' keyword in ACI bind rules seems to have no
effect on its own. For example,
This does not deny access to IP 1.2.3.4:
aci: (version 3.0; acl "Deny 1.2.3.4"; deny(all) (ip = "1.2.3.4");)
But when combined with a userdn clause like this, it works:
aci: (version 3.0; a
Alexandre Augusto da Rocha wrote:
This is not true. You don't need SSL if AD will be a true slave. SLL
is only required if you want to allow users to change their passwords
on AD and have that propagated to FDS.
Not exactly. You need SSL to allow passwords to be synchronized in
either direct
Ville Silventoinen wrote:
Hi Noriko, thanks for you reply.
On Thu, 29 Mar 2007, Noriko Hosoi wrote:
[...]
Is there a way to find out which entries are causing the problem?
Can there be illegal characters in the entries?
Could it be possible to share your data with us? (sample data would
be g
Under recent versions of FDS, is it OK to use virtual attributes (i.e.,
nsRole or CoS-generated) in ACI targetfilters?
In earlier versions of Netscape DS, this was not recommended, and this
is still mentioned in the RHDS 7.1 docs:
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#10
George Holbert wrote:
Are the docs just a little dated on this, or is it still not a good idea?
I believe this warning was written before virtual attribute evaluation
was added to the filter code (so searches etc. didn't work with virtual
attributes) - that is no longer the case and hasn't bee
I was looking through the logconv.pl output and I see that the majority
of connection codes are
B1 Bad Ber Tag Encountered
Should I be worried about this? LDAP seems to be working fine and has
been for months.
PK
--
Philip Kime
NOPS Systems Architect
310 401 0407
--
Fedora-directory-users
15 matches
Mail list logo