Does 389org expand dynamic groups?

[Roberto Polli]

Hi all,

I'm playing with dynamic groups, but it seems that ldap doesn't evaluate them.
The MemberOf plugin doesn't work with dynamic groups too...

Do I have to search them programmatically?

Thx+Peace,
R.

PS. a similar question has been asked but not answered  
http://lists.fedoraproject.org/pipermail/389-users/2008-May/007784.html



-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. [phone] - fax [phone]
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

[Rich Megginson]

Roberto Polli wrote:
>  Hi all,
>
>  I'm playing with dynamic groups, but it seems that ldap doesn't evaluate them.
>  The MemberOf plugin doesn't work with dynamic groups too...
>
>  Do I have to search them programmatically?
>     
Yes.  This feature is on our roadmap - 
http://directory.fedoraproject.org/wiki/Roadmap - Dynamic group expansion
I don't know when we will get around to it (patches welcome!)
>  Thx+Peace,
>  R.
>
>  PS. a similar question has been asked but not answered  
>  http://lists.fedoraproject.org/pipermail/389-users/2008-May/007784.html
>
>
>
>

[Roberto Polli]

On Monday 17 May 2010 16:48:25 Rich Megginson wrote:
>  > Do I have to search them programmatically?
>  
>  Yes.  This feature is on our roadmap -
>  http://directory.fedoraproject.org/wiki/Roadmap - Dynamic group expansion
>  I don't know when we will get around to it (patches welcome!) 
thx for your answer!

Peace,
R.

-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. [phone] - fax [phone]
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

How to do this best with 389ds

[Roland Schwingel]

Hi...

After a while I got my 389ds ldap now up and running for users accounts, 
groups, dns and dhcp. Everything fine fast and stable (even I am running 
it on OpenSuse). 

But I got a question on how to realize a certain idea with 389ds.

I got a central LDAP directory. It contains all data. I am having 
different subnets but want to have a central user management.
Each subnet has different dedicated servers for user homeaccounts and each 
subnet has its own ldap server (replication consumer) to which each subnet 
referrs to. This is due to security/fault tolerance considerations and 
also due to different subsidiaries with sometimes slow network connection.

Example User "John":
He logs in in subnet A (eg from IP 192.168.1.100):
Unix homeaccount: /Servers/SubnetAServer/Users/John
Samba homeaccount: \\SubnetAServer\Users\John

He logs in in subnet B (eg from IP 192.168.2.100):
Unix homeaccount: /Servers/SubnetBServer/Users/John
Samba homeaccount: \\SubnetBServer\Users\John

(It is not possible to mask the servername for each subnet to be the same 
by dns).

Means the ldap search needs to return different attribute values when the 
search is performed from different subnets (all other values - like uids - 
shall remain constant). I don't want to have different user trees. User 
sometimes travel from subsidary to subsidary or are using different 
subnets at the same time. Can this be done by views or class of service or 
some other tricks/plugins?  Has anyone done this already?

Thanks in advance,

Roland

How to do this best with 389ds

[Roberto Polli]

On Tuesday 18 May 2010 12:16:43 Roland Schwingel wrote:
>  Means the ldap search needs to return different attribute values when
> the
>  search is performed from different subnets 
try mixing vlv and smart referral.
anyway ldap may not be the best place to play that game.

let us know+Peace,
R.


-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. [phone] - fax [phone]
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

SASL auth problem on bind with Mac OS X 10.4

[Roland Schwingel]

Hi...

With Mac OS X 10.4 I got a problem when user wants to log in into an 
account hosted in 389ds.
I presumably tracked the problem down to a SASL auth problem.

Using wireshark I recorded the traffic between my mac os x 10.4 machine 
and my 389ds server.
On logon the mac tries a bind without binddn but with SASL auth (mechanism 
CRAM-MD5).

Mac -> 389DS:  bindrequest with CRAM-MD5 to get credentials
389DS -> Mac: bindresponse with md5 credentials (eg. 
"<3051212195.15971967(a)host.domain>")
Mac -> 389DS: bindrequest CRAM-MD5 with user and hashed password (eg. 
"roland b98c....")
389DS -> MAC: bindresponse invalidcredentials ("SASL(-13): user not found: 
no secret in database")
Mac says sorry no logon...

With Mac OS X 10.5/10.6 it works. It also tries the CRAM-MD5 SASL auth. 
But when it failes it alternatively tries a bind with a binddn (eg. 
"uid=roland,ou=people,dc=domain") which is successful. Unfortunately I 
have a bigger amount of mac os x 10.4 machines which I cannot migrate to 
10.5 oder later so I need to support this. I yet did not find a way to 
convince mac os x 10.4 to use a binddn for auth.

Any clue what is wrong here? Is this a SASL uid mapping problem or is it 
because the user passwords are stored SSHA hashed? I already tried to 
change the stored password from SSHA to MD5, but it does not help SASL 
auth fails with the same error message. Or is this a hash comparison 
problem?

Thanks in advance,

Roland

SASL auth problem on bind with Mac OS X 10.4

[Roland Schwingel]

Hi...

Sorry to follow up on my own post but I figured it out. 

>  Any clue what is wrong here? Is this a SASL uid mapping problem or is
> it  
because the user passwords are stored SSHA hashed? I 
>  already tried to change the stored password from SSHA to MD5, but it 
does not help SASL auth fails with the same error 
>  message. Or is this a hash comparison problem?  
It is indeed the hash problem.
When I switch my password storing to cleartext (BRR!) mac os x 10.4 can 
log in.
But this is nothing I want to have. Is it true that Apple's OpenDirectory 
Servers are also storing
their passwords in cleartext? Can someone with access to an OpenDirectory 
Server
verify this?

I don't want to store clear text passwords... 
Has anyone else 389ds running with Mac OS X 10.4 clients and managed to 
use it without
cleartext passwords?

Thanks,

Roland

SASL auth problem on bind with Mac OS X 10.4

[Per Qvindesland]

Hi

Is the ldap server configured for sasl? it would seem that the osx
client tries with sasl and only sasl when that does not work it unbinds
and does not try simple bind, it may see that the ldap server is showing
sasl as a available authentication method but it is not really
available, can you exec login into it? also did you reboot the mac box
after configuring the ldap login?

Per
On Wed, 2010-05-19 at 12:45 +0200, Roland Schwingel wrote:
>  
>  Hi... 
>  
>  With Mac OS X 10.4 I got a problem when user wants to log in into an
>  account hosted in 389ds. 
>  I presumably tracked the problem down to a SASL auth problem. 
>  
>  Using wireshark I recorded the traffic between my mac os x 10.4
>  machine and my 389ds server. 
>  On logon the mac tries a bind without binddn but with SASL auth
>  (mechanism CRAM-MD5). 
>  
>  Mac -> 389DS:  bindrequest with CRAM-MD5 to get credentials 
>  389DS -> Mac: bindresponse with md5 credentials (eg.
>  "<3051212195.15971967(a)host.domain>") 
>  Mac -> 389DS: bindrequest CRAM-MD5 with user and hashed password (eg.
>  "roland b98c....") 
>  389DS -> MAC: bindresponse invalidcredentials ("SASL(-13): user not
>  found: no secret in database") 
>  Mac says sorry no logon... 
>  
>  With Mac OS X 10.5/10.6 it works. It also tries the CRAM-MD5 SASL
>  auth. But when it failes it alternatively tries a bind with a binddn
>  (eg. "uid=roland,ou=people,dc=domain") which is successful.
>  Unfortunately I have a bigger amount of mac os x 10.4 machines which I
>  cannot migrate to 10.5 oder later so I need to support this. I yet did
>  not find a way to convince mac os x 10.4 to use a binddn for auth. 
>  
>  Any clue what is wrong here? Is this a SASL uid mapping problem or is
>  it because the user passwords are stored SSHA hashed? I already tried
>  to change the stored password from SSHA to MD5, but it does not help
>  SASL auth fails with the same error message. Or is this a hash
>  comparison problem? 
>  
>  Thanks in advance, 
>  
>  Roland 
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

SASL auth problem on bind with Mac OS X 10.4

[Roland Schwingel]

Hi Per,

Thanks for your reply.

389-users-bounces(a)lists.fedoraproject.org wrote on 19.05.2010 13:32:36:
>  Is the ldap server configured for sasl? 
Yes.

>  it would seem that the osx
>  client tries with sasl and only sasl when that does not work it unbinds
>  and does not try simple bind, it may see that the ldap server is showing
>  sasl as a available authentication method but it is not really
>  available, can you exec login into it?  
This is what I try to figure out right now.
I am just searching where
to switch of some SASL methods (or SASL at all) in 389ds. Do you know
where this can be done. Haven't found anything yet (beside of the 
./configure
switches). I am searching something which does not require a recompile.

>  also did you reboot the mac box
>  after configuring the ldap login? 
Sure. But it was reproducable without reboot. If
my password was
stored cleartext I could log in. If I changed it back to SSHA or MD5
login was no longer possible.

Roland

SASL auth problem on bind with Mac OS X 10.4

[Per Qvindesland]

Hi 

Sorry I did not see that you had already answered your own mail :)

I believe that it supports Shadow Hash and Password Server since version
10.2

Per
On Wed, 2010-05-19 at 13:19 +0200, Roland Schwingel wrote:
>  OpenDirectory

SASL auth problem on bind with Mac OS X 10.4

[Roland Schwingel]

Hi....

>  Is the ldap server configured for sasl? it would seem that the osx
>  client tries with sasl and only sasl when that does not work it unbinds
>  and does not try simple bind, it may see that the ldap server is showing
>  sasl as a available authentication method but it is not really
>  available, can you exec login into it?  
As I found no other way to test it I moved
away my libcrammd5.so on my
389ds box and restarted dirsrv. CRAM-MD5 was no longer in the list of
supported methods. 

I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL bind
that is the good news, but it does not switch over to a simple bind using
a binddn. It just does no bind anymore. What a mess. 

Anyway:
Maybe I haven't found it but an option to enable/disable certain SASL
methods within 389ds would IMHO be good to have for other situations
where you can come into these needs.

Roland

SASL auth problem on bind with Mac OS X 10.4

[Rich Megginson]

Roland Schwingel wrote:
>  Hi....
>
>  > Is the ldap server configured for sasl? it would seem that the osx
>  > client tries with sasl and only sasl when that does not work it unbinds
>  > and does not try simple bind, it may see that the ldap server is showing
>  > sasl as a available authentication method but it is not really
>  > available, can you exec login into it?
>  As I found no other way to test it I moved away my libcrammd5.so on my
>  389ds box and restarted dirsrv. CRAM-MD5 was no longer in the list of
>  supported methods.
>
>  I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL bind
>  that is the good news, but it does not switch over to a simple bind using
>  a binddn. It just does no bind anymore. What a mess.  
So the mac finds that
CRAM-MD5 is not available, and does nothing at all?

Note that Digest-MD5 requires that the directory server store the 
password in clear text.  This is because the directory server must use 
the clear text password to generate the challenge for the client.  This 
prevents any clear text passwords from being sent across the wire, as is 
done with a regular simple DN and password BIND operation.
>  Anyway:
>  Maybe I haven't found it but an option to enable/disable certain SASL
>  methods within 389ds would IMHO be good to have for other situations
>  where you can come into these needs. 
It's on the Roadmap -
http://directory.fedoraproject.org/wiki/Roadmap
>  Roland
>  ------------------------------------------------------------------------
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

SASL auth problem on bind with Mac OS X 10.4

[Roland Schwingel]

Hi Rich...

Thanks for your reply!

>  > I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL
> bind
>  > that is the good news, but it does not switch over to a simple bind  
using
>  > a binddn. It just does no bind anymore. What a mess. 
>  So the mac finds that CRAM-MD5 is not available, and does nothing at  
all?
Mac OS X 10.4 behaves that way. At least as far as I can tell from my 
wireshark sniffing and the 389ds access log file. It just does some 
searches
for user attributes (including userPassword), but no bind for 
authorization
as user just an anonymous bind ahead of all this which does not retrieve
the password due to the anonymous aci entry of 389ds. I removed the 
restriction
to not deliver the userPassword in searches with anonymous bind but it did 
not
help either. 

I consider this to be a bug in 10.4. With Mac OS X 10.5 and 10.6 this
has changed. There it tries the SASL auth first (if available) and if
it fails (or it is not available) it is doing a simple bind which then
succeeds.

>  > Maybe I haven't found it but an option to enable/disable
> certain SASL
>  > methods within 389ds would IMHO be good to have for other situations
>  > where you can come into these needs.
>  It's on the Roadmap - http://directory.fedoraproject.org/wiki/Roadmap 
Nice to
read... Thanks.... :-)

But generally speaking - with thinking while typing: 
If the password policy is set to something else than cleartext
SASL MD5 methods do not make sense at all. An auth using these methods 
will not succeed. Right? 
So they could automatically be disabled by dirsrv if the password policy 
is set
to something different than cleartext? Or am I wrong?

Hmm... Or would it work (at least if the password is stored in md5 not 
s(sha))
if the same salt is used in the sasl md5 challenge supplied to the client? 
If the 
client uses this supplied salt for hashing the password, the sent result 
should 
be comparable with the stored md5 hashed password using that same salt. So 
a SASL 
MD5 auth would be possible than. Maybe I am wrong and it is already much 
too late
for me to think about these things today ... ;-)

Roland

Logfile buffering

[Roland Schwingel]

Hi....

One last question before switching of my machine...
Is it possible that the dirsrv logfiles (access, error etc.) are written 
to disk with activated buffering?

When I do a tail -f on these logfiles I see a big delay in output. When I 
do eg. an ldapsearch from
a client the result appears immediately at the client, but it takes about 
10 to 15 seconds until the tail -f
shows the search (or whatever I do). This is a bit inconvenient when 
debugging things. 

Does this happen only to me or is this generally the case? Can this be 
switched off/changed?

Thanks for your help,

Roland

Logfile buffering

[Nathan Kinder]

On 05/19/2010 01:39 PM, Roland Schwingel wrote:
>  Hi....
>
>  One last question before switching of my machine...
>  Is it possible that the dirsrv logfiles (access, error etc.) are 
>  written to disk with activated buffering?
>
>  When I do a tail -f on these logfiles I see a big delay in output. 
>  When I do eg. an ldapsearch from
>  a client the result appears immediately at the client, but it takes 
>  about 10 to 15 seconds until the tail -f
>  shows the search (or whatever I do). This is a bit inconvenient when 
>  debugging things.
>
>  Does this happen only to me or is this generally the case? Can this be 
>  switched off/changed? 
The access log output is buffered by default.  You can turn
this off by 
setting the "nsslapd-accesslog-logbuffering" attribute to "off" in the

"cn=config" entry.

The errors log is not buffered.

-NGK
>  Thanks for your help,
>
>  Roland
>
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

SASL auth problem on bind with Mac OS X 10.4

[Rich Megginson]

Roland Schwingel wrote:
>  Hi Rich...
>
>  Thanks for your reply!
>
>  > > I rebooted also my mac. My mac no longer issues a CRAM-MD5 SASL bind
>  > > that is the good news, but it does not switch over to a simple 
>  bind using
>  > > a binddn. It just does no bind anymore. What a mess.
>  > So the mac finds that CRAM-MD5 is not available, and does nothing at 
>  all?
>  Mac OS X 10.4 behaves that way. At least as far as I can tell from my
>  wireshark sniffing and the 389ds access log file. It just does some 
>  searches
>  for user attributes (including userPassword), but no bind for 
>  authorization
>  as user just an anonymous bind ahead of all this which does not retrieve
>  the password due to the anonymous aci entry of 389ds. I removed the 
>  restriction
>  to not deliver the userPassword in searches with anonymous bind but it 
>  did not
>  help either. 
If it is searching for the userPassword attribute, then it must be
doing 
something like linux pam_ldap does when you have pam_password md5 or 
something like that - it is attempting to do the password comparison 
locally rather than sending the cleartext password to the server and 
letting the server perform the BIND.  I am not at all familiar with Mac 
auth config, but it is possible that
* there is some mac auth config setting that you tell it to perform the 
bind on the server
* mac might not want to perform a simple bind over an unencrypted 
channel - that is, you may have to configure tls/ssl on the DS side and 
on the mac side before it will allow you to perform a simple password 
auth, without sending the clear text password over the wire
>  I consider this to be a bug in 10.4. With Mac OS X 10.5 and 10.6 this
>  has changed. There it tries the SASL auth first (if available) and if
>  it fails (or it is not available) it is doing a simple bind which then
>  succeeds. 
Weird.
>  > > Maybe I haven't found it but an option to enable/disable certain SASL
>  > > methods within 389ds would IMHO be good to have for other situations
>  > > where you can come into these needs.
>  > It's on the Roadmap - http://directory.fedoraproject.org/wiki/Roadmap
>  Nice to read... Thanks.... :-)
>
>  But generally speaking - with thinking while typing:
>  If the password policy is set to something else than cleartext
>  SASL MD5 methods do not make sense at all. An auth using these methods 
>  will not succeed. Right?  
Right.
>  So they could automatically be disabled by dirsrv if the password 
>  policy is set
>  to something different than cleartext? Or am I wrong? 
You are correct.  But
technically, all LDAPv3 servers are supposed to 
support Digest-MD5.
>  Hmm... Or would it work (at least if the password is stored in md5 not 
>  s(sha))
>  if the same salt is used in the sasl md5 challenge supplied to the 
>  client? If the
>  client uses this supplied salt for hashing the password, the sent 
>  result should
>  be comparable with the stored md5 hashed password using that same 
>  salt. So a SASL
>  MD5 auth would be possible than. Maybe I am wrong and it is already 
>  much too late
>  for me to think about these things today ... ;-) 
It's possible, but the sasl
digest/challenge stuff is handled internally 
by the cyrus sasl code (on the DS side, anyway) - not sure how that 
would work.
>  Roland
>  ------------------------------------------------------------------------
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users