I'm trying to make admin server install and run without having to use
setup, which means I have to use hard coded values. Since directory
server listens to port 389, and I don't want to have admin server listen
to a low port (< 1024), how about 1389?
Thanks for the input.
I would not recommend RH423 for those who are trying to immediately
deploy ldap or Keberos across a network. There is just no way someone
new to ldap/Kerberos can gain enough insight into all the possible
problems and gotchas in four days of instruction! If you need to use
ldap immediately hire a good consultant! I do highly recommend the
course to those who have time to plot and plan their implementation. The
course was very good about walking through all the cli tools and the
steps needed to create and manage ldap.
Even if you plan to use openldap directly and not Redhat Directory
Service, the course is worth the time. It gives you a quick foundation
to build on.
Phpldapadmin is where I am going to start. Has anyone seen a practical
implementation using Webmin?
[mailto:firstname.lastname@example.org] On Behalf Of Mike
Sent: Friday, July 21, 2006 9:07 AM
To: Fedora Directory server developer discussion.
Subject: Re: [Fedora-directory-devel] General use questions and diffs
Deas, Jim wrote:
> I recently completed Redhats course on Directory Services and decided
> setup a test deployment using Fedora. In the course of doing this I
> across a couple of issues that I need to answer before I could use
> Directory as a valid authentication system.
What did you think about the course?
> 1) The web interface appears to create/handle group entrys different
> from those migrated from the local files using the Redhat class
> paddle scripts. From the class I remember changing the 'group' schema
> 'groups'. End result, is there a way to create/manage 'groups' schema
> entries using the Directory web page that match those created when my
> existing /etc/group was migrated using the altered paddle scripts. If
> not, why does Redhat suggest this change in their class?
The web interface is not meant to be a full-blown user management
solution. You'd do much better with something like phpldapadmin, or
writing your own command line tools.
> 2) Is there a way that the Directory web page can be used to create
> user accounts that include an autogen uid and gid? Currently it
> to create a new user with all the posix data turned off. This is fine
> from a management position as long as a uid generator exist to keep me
> safe from producing duplicate uid/gid numbers.
I wrote a user addition script which supports uid uniqueness checking
for manually specified uids, as well as auto incrementing of uid if
desired (does a search, sorts the uid list, and adds 1).
Just edit the configuration section to match your setup, and you're all
NOTE that this is not a very advanced tool, but the price is right :-) I
have written some very advanced ones, but they are not open source...
http://www.netauth.com - LDAP Directory Consulting
Fedora-directory-devel mailing list
I recently completed Redhats course on Directory Services and decided to
setup a test deployment using Fedora. In the course of doing this I came
across a couple of issues that I need to answer before I could use
Directory as a valid authentication system.
1) The web interface appears to create/handle group entrys different
from those migrated from the local files using the Redhat class altered
paddle scripts. From the class I remember changing the 'group' schema to
'groups'. End result, is there a way to create/manage 'groups' schema
entries using the Directory web page that match those created when my
existing /etc/group was migrated using the altered paddle scripts. If
not, why does Redhat suggest this change in their class?
2) Is there a way that the Directory web page can be used to create new
user accounts that include an autogen uid and gid? Currently it appears
to create a new user with all the posix data turned off. This is fine
from a management position as long as a uid generator exist to keep me
safe from producing duplicate uid/gid numbers.
Any help is appreciated.
I'm building up a list of general, problematic security
vulnerabilities that are common across computer networks today.
Hopefully we'll be able to explain how to target many of these on the
realsecurity website (so I have a bias for problems that can be
tackled using the DS/CS/smartcard combo, but we should open it up
beyond that too). Would love for other people to jump in and add some
(or discuss them in this thread).
Here's what I've jotted down thus far:
Problem: People choose passwords that are easily guessable/crackable
Attack vector: passwords are cracked and the systems compromised
Problem: People post important passwords around their workplaces
Attack vector: anyone gaining physical access to a building can
harvest large numbers of passwords AND account names (usernames are
usually derived from the person's name which is also present around
their workplace), and use them covertly remotely at a later time
Problem: People forget their passwords and have to get them reset
frequently Attack vector: as the frequency of password resets
increases, it is natural for, e.g. help desk personel to become lax in
when and why they will re-issue a password. This increases
vulnerability to social engineering. If resetting passwords is a big
deal and an unusual event, this is much less likely to occur. But that
is only feasible if people don't forget their passwords.
Problem: Computer screens are rarely locked when unattended Attack
vector: By gaining physical access to a computer not only can a
variety of keylogging and other intrusive programs be installed, not
only can data be taken, but immediate access to other resources is
often granted (from open ssh logins to file shares). This is
particularly problematic on modern operating systems featuring a
"keychain" which caches passwords for a login. Once the computer is
unlocked access to a variety of remote resources is typically also
Problem: Stored data and sent messages, even highly sensitive ones,
are rarely encrypted Why? Its a PITA to encrypt things, maintain a set
of keys/certs between systems, etc
Problem: Its relatively easy to learn secret information such as
passwords through social engineering, and this is typically all that
is required to gain access to a computer system
Problem: Computers are not updated and contain many security
vulnerabilities This is often ameliorated by the presence of a
firewall, but it does render the inside of the network extremely soft
i've read carefully the build documentation written for solaris, but it
assumes i'm using the sun workshop and the procedure does not work
unmodified for gcc
someone has experiences about the build process using gcc and/or has
documentation about that?
thanks in advance :-D
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
I would like to learn more about the LDAP, but a lot of the book I found on
amazon.com are more than 2-3 years old. I am afraid they're out of date.
Is there any good books that you guys would like to suggest? I am
interested in in-depth LDAP explaination/usages/design/schema design.
I don't really want to be product specific because the last 2 years, we
already switched 3 directory server. From Sun DS to OpenLDAP to Fedora DS.
Thanks in advance!