Hi All,
We have an AD architecture setup, and are looking to sync FDS with
this to allow us to authenticate Linux machines and network devices.
We have two AD domains, and have a winsync and passsync setup with one
of the domain controllers in each domain. This works, subject to the
limitation that we have to manually create each OU. Once we create the
OU in FDS, the users appear at the next sync. Question 1: is it
possible to automatically sync *all* OU's, including creating the OU
in FDS if it does not exist? We have hundreds of OUs, and I don't want
to have to create them all manually.
Question 2 is on UNIX UID/GID sync from AD. I've found a couple of
posts which imply that it is not possible to sync UID/GUD from AD[1],
but this was some time ago. An alternative piece of documentation
suggests that it is, but provides no details[2]. I'm also struggling
to find documentation on the libdna plugin, which I believe is
involved[3].
My questions are
- Is it possible to sync UID/GID from AD (where AD has the Unix Tools
installed, and therefore has these attributes in the schema).
- Is it possible to automatically apply a unique UID/GID to each user
that does not have a UID/GID?
Any help/pointers greatly appreciated.
Many thanks,
Alex
[1] http://www.redhat.com/archives/fedora-directory-users/2007-February/msg00...
[2] "Fedora DS gets posix/unix automatic uid generation (February 08, 2007)
The cvs head now contains a new feature for automatic generation of
sequenced numbers which is compatible with multi-master replication
environments. This feature can be used for automatic generation of
posix uidNumber and gidNumber in addition to other sequenced numeric
attributes required by your deployment. "
http://directory.fedoraproject.org/
[3] About the only referenceI can find:
http://www.redhat.com/archives/fedora-directory-users/2008-January/msg000...

Sorry for not replying to the original thread, but I just joined this
list.
On Tue, 13 May 2008, Rich Megginson wrote:
> Has anyone seen these errors with 1.1? We fixed a few 64-bit
issues in 1.1.
I am running two 32-bit FDS 1.1 (fedora-ds-1.1.0-3.fc6) servers, on
RHEL 5.1, in an MMR configuration. These servers, which are
configured behind a load balancer, act as the University's central
authentication service. We have are using the password policy plugin
and have the "passwordisglobalpolicy" setting enabled, so there is a
substantial amount of write activity due to replication of password-
policy-related attributes (e.g., passwordRetryCount,
retryCountResetTime, etc). Time on both systems is synchronized via
NTP; clocks are in sync.
We have the same situation as Reinhard Nappert reported on 5/13/2008:
MMR will work fine for a while (usually a few weeks; the longest
period we've gone is a month, the shortest time a few hours).
Eventually replication will fail with the following sequence of
messages in the errors log:
[24/May/2008:05:18:54 -0700] - csngen_adjust_time: adjustment limit
exceeded; value - 86401, limit - 86400
[24/May/2008:05:18:54 -0700] NSMMReplicationPlugin - conn=1800
op=60262 replica="<suffix>": Unable to acquire replica: error:
excessive clock skew
[24/May/2008:05:20:05 -0700] - csngen_adjust_time: adjustment limit
exceeded; value - 86401, limit - 86400
[24/May/2008:05:20:05 -0700] NSMMReplicationPlugin -
agmt="cn=kif2zapp" (zapp:389): Incremental protocol: fatal er
ror - too much time skew between replicas!
[24/May/2008:05:20:05 -0700] NSMMReplicationPlugin -
agmt="cn=kif2zapp" (zapp:389): Incremental update failed and
requires administrator action
The "csngen_adjust_time" error message always reports the same value
when this occurs (86401).
We have also employed the workaround described by Chris St. Pierre in https://bugzilla.redhat.com/show_bug.cgi?id=233642
#c3. This resolves the problem for a short while, but it always
reappears. BTW, I was in contact with Chris recently about his
experiences with MMR and he said that, in addition to moving to FDS
1.1, he moved a lot of "frequently updated" data out of FDS and into
MySQL, and that his problem disappeared afterward; obviously this
isn't a solution for us as we are utilizing FDS as an authentication
engine.
We are desperately trying to find a solution to this issue that will
allow us to continue using MMR...we could resort to a traditional
passive/active + shared storage HA design, but we want to keep that as
a last resort. If there is any additional information I should
provide, please let me know.
--
Gary Windham
Senior Enterprise Systems Architect
The University of Arizona, UITS
+1 520 626 5981

I have successfully installed Fedora ds 1.0.4 on Ubuntu 8.04. I run into
some issues when configuring Pam and Nss for the samba portion. On my
first test server I was able to complete the setup without an y major
problems. On all subsequent servers. I install FDS and successfully
start the console and add one posix user.
I then begin installing Pam and Libnss by using the auth-client-config
to automatically configure the files in /etc/pam.d/ as well as the
nssswith.conf. after I do this, I can no longer log in to the console,
and the error logs get filled with the following error.
[Mon May 19 00:43:26 2008] [notice] child pid 10675 exit signal
Segmentation fault (11)
Can anyone point me in the right direction?
Sanga M. Collins
Network Engineering
~~~~~~~~~~~~~~~~~~~~~~~
IT Management LLC
6491 Sunset Strip #5,
Sunrise Fl, 33313
Tel: (954) 572 7411,
Fax: (435) 578 7411

Hello all
I'm using the fedora directory server for centralized authentication ,
and i have made users with posix account and i put them in ou=People
like this :
---------------------------------------------------------------------------------------------
# alexadu, People, pol.mediaimage.ro
dn: uid=alexadu,ou=People,dc=pol,dc=ro
givenName: Alexandra
sn: Dumitru
loginShell: /bin/bash
uidNumber: 1069
gidNumber: 100
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
uid: alexadu
cn: Alexandra Dumitru
homeDirectory: /home/alexadu
------------------------------------------------------------------------------------------
and after that i made some groups
in ou=Groups
like this :
-----------------------------------------------------------------------------------------
# Server1, Groups, pol.ro
dn: cn=Server1,ou=Groups,dc=pol,dc=ro
description: group for users that have access on server 1
objectClass: top
objectClass: groupofuniquenames
uniqueMember: uid=lauru,ou=People,dc=pol,dc=ro
uniqueMember: uid=alexadu,ou=People,dc=pol,dc=ro
cn: Server1
----------------------------------------------------------------------------------------
and my ldap.conf looks like this :
URI ldap://lacatzel.pol.ro
port=389
BASE dc=pol,dc=ro
host lacatzel.pol.ro
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow
scope sub
bind_policy soft
#pam_password exop
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
pam_groupdn cn=Server1,ou=Groups,dc=pol,dc=ro
pam_check_host_attr yes
nss_default_attribute_value loginShell /bin/false
nss_base_passwd ou=People,dc=pol,dc=ro
nss_base_shadow ou=People,dc=pol,dc=ro
nss_base_group ou=People,dc=pol,dc=ro
---------------------------------------------------------------------------------------------
now i want to restrict some users to servers based on groups but my pam_ldap
does not help me to do that , I'm using my old friend "www.google.com" to
help me in this problem but with no luck ..... all my users have access to
this computer .... so , if i understand wright all i have to do is create
users with posix account and after that create groups and put the users in
that group but this does not work ..... any ideas ? anyone use FDS for what i
intend to do ?
Thank you for your time .....
Bogdan

Hi,
I have a curious problem where a few (important) users cannot log into
the Red Hat Enterprise Server 4 update 4 systems. However, most users
(including myself) can log in. These users can log in fine to ldap'd
RHES3 Update 6 systems.
The FDS logs indicate a normal fetch of the user's attributes with no
errors. The /var/log/secure on Red Hat 4 simply says
sshd[8898]: Failed password for <username> from <hex>...
Yet they can log into other LDAP based systems, including a few other
RHE4 systems, that all go back to the same FDS.
I have deleted their accounts and recreated them, which usually fixes
strange problems like this, but no luck. Some accounts are old (date
back to FDS 7.1) and others are new.
I examined the DS attributes for these users, and the only difference I
could find was the "Object class" attribute was missing the "account"
value. So, I added it, but to no avail.
I compared /etc/pam.d/system-auth and they are essentially identical
between RHES3 and 4 systems.
/var/log/secure also has a "error" Could not get shadow information for
<username>" but that happens on all users. It seems to be a soft error,
but I would like to get rid of it.
Can anyone give me a clue where to look?
Thanks!
Ken

> Date: Fri, 23 May 2008 10:42:25 -0600
> From: Rich Megginson<rmeggins(a)redhat.com>
> Fernando MuÃ±oz wrote:
>> Hello,
>>
>>
>> I've got a question,
>>
>> Is there any way for raise a LDAP instance over 389 UDP port (CLDAP)?
OpenLDAP supports CLDAP. Note that there is no formal spec for this protocol;
there was a draft for LDAPv2 that expired long ago. Microsoft's version of
CLDAP (naturally) does not conform to that draft. OpenLDAP supports both the
expired draft and the Microsoft bastardization thereof, and has done so since
at least 2000.
But offering LDAP over UDP is a far cry from joining an AD environment. (See
PADL's XAD, for instance, which was developed on OpenLDAP and subsequently
sold to Novell.)
>> I've been trying to join a WindowsXP machine to a
>> FDS(backend)-SAMBA3(PDC) environment, and I've got a problem:
>>
>> Sniffing a WindowsXP (client) machine traffic, ï»¿I see there are LDAP
>> petitions (connections) through UDP 389 port, and FDS instance run over
>> TCP ports.
>>
> No, Fedora DS does not support UDP (CLDAP).
>
> You should check out Samba4.
Yes, that would probably be the best route now.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

I have been trying to get the Password Syntax Checking working with
FDS 1.0.4 and am having some trouble with the passwords that it is
allowing and the ones that are returning invalid syntax.
I started by setting the password policy the way I thought I wanted to
use for my environment, but then no passwords would work, so I changed
everything down to the minimums that I could find, but I am still
getting several passwords rejected due to a syntax error. I am not
using the console and I need to be able to set this through an LDIF
file.
Currently I have these settings for the password policy configuration:
passwordInHistory: 2
passwordUnlock: on
passwordGraceLimit: 0
passwordMustChange: off
passwordWarning: 86400
passwordLockout: on
passwordMinLength: 4
passwordMinDigits: 0
passwordMinAlphas: 0
passwordMinUppers: 0
passwordMinLowers: 0
passwordMinSpecials: 0
passwordMin8bit: 0
passwordMaxRepeats: 0
passwordMinCategories: 1
passwordMinTokenLength: 1
passwordMaxFailure: 3
passwordMaxAge: 3888000
passwordResetFailureCount: 120
passwordisglobalpolicy: off
passwordChange: on
passwordExp: on
passwordLockoutDuration: 300
passwordCheckSyntax: on
passwordMinAge: 0
passwordStorageScheme: SSHA256
I am getting syntax errors on passwords like the following:
spfihykr
spfihykr10
qpwoeiru
10293847
cmdjeu37
alskdj37
xnshwy26
doggie
doggie12
but things like testpass works just fine.
I figure that I have something not configured properly, but I don't
know what needs to be changed. And some of the values that I am using
were in the User Account Management section of the Administrator's
Guide two weeks ago, but they are missing now.
Thanks in advance,
Eric Brown