[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP server, Solaris 9 client
luiz@pucrs.br wrote:
Hello Jehan
ldapclient init -a profileName=profile-my -a domainName=my.domain -a
proxyDn=cn=proxyagent,ou=contasIT,dc=my,dc=domain -a
proxyPassword=secret
server
last parameter is the dns name of your openldap server ?
Yes, it is.
I think you have to put it in it's ip address (see my example :
157.159.55.199)
Hum. I don´t think so. Apparently, it works ok with DNS entry too.
OK, all the example/docs even man i think, talked about ip address !?
Now, I have the following:
# contasIT, my.domain
dn: ou=contasIT,dc=my,dc=domain
objectClass: top
objectClass: organizationalUnit
ou: contasIT
#
# proxyagent, contasIT, my.domain
dn: cn=proxyagent,ou=contasIT,dc=my,dc=domain
cn: proxyagent
sn: proxyagent
objectClass: top
objectClass: person
Your proxy-agent doesn't have a userpassword attribute !?? it should have
one
Yes, it has. The userPassword attribute doesn´t appears before because I
use only 'ldapsearch -x'. With 'ldapsearch -x -D "cn=admin,dc=my,dc=domain"
-W -LLL':
dn: cn=proxyagent,ou=contasIT,dc=pucrs,dc=br
cn: proxyagent
sn: proxyagent
objectClass: top
objectClass: person
userPassword:: $$$secret$$$
#
# profile, my.domain
dn: ou=profile,dc=my,dc=domain
objectClass: top
objectClass: organizationalUnit
ou: profile
#
# profile-my, profile, my.domain
dn: cn=profile-my,ou=profile,dc=my,dc=domain
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: server
defaultSearchBase: dc=my,dc=domain
authenticationMethod: simple
cn: profile-my
credentialLevel: proxy
followReferrals: true
serviceSearchDescriptor:
auto_master:nismapname=auto_master,dc=my,dc=domain
objectclassMap: automount:automountMap=nisMap
objectclassMap: automount:automount=nisObject
attributeMap: automount:automountMapName=nisMapName
attributeMap: automount:automountInformation=nismapentry
attributeMap: automount:automountKey=cn
All these stuff about automount maps haven't been tested however ...as I
still use /etc/auto.master and /etc/auto.home for automount !
Hum. Ok. I was changed it for this:
# profile-my, profile, my.domain
dn: cn=profile-my,ou=profile,dc=my,dc=domain
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: server
defaultSearchBase: dc=my,dc=domain
authenticationMethod: simple
cn: profile-my
credentialLevel: proxy
Is that ok?
looks like ok !
In my doc, i used ldapclient genprofile to generate this
$ ldapclient genprofile -a profilename=profile-mci -a defaultsearchbase=dc=int-evry,dc=fr \
-a authenticationmethod=simple -a credentiallevel=proxy 157.159.55.199
note again the use of an ip address
Well, the problem is that when I try to login, THIS hapens:
Jul 23 09:18:57 server slapd[4178]: conn=76 fd=13 ACCEPT from
IP=200.188.161.5:33660 (IP=0.0.0.0:389)
Jul 23 09:18:57 server slapd[4181]: conn=76 op=0 BIND
dn="cn=proxyagent,ou=contasIT,dc=my,dc=domain" method=128
Jul 23 09:18:57 server slapd[4181]: conn=76 op=0 BIND
dn="cn=proxyagent,ou=contasIT,dc=my,dc=domain" mech=simple ssf=0
Jul 23 09:18:57 server slapd[4181]: conn=76 op=0 RESULT tag=97 err=0
text=
base="ou=people,dc=my,dc=domain" scope=1
filter="(&(objectClass=posixAccount)(uid=user1))"
Jul 23 09:18:57 server slapd[4216]: conn=76 op=1 SRCH attr=cn uid
uidnumber
gidnumber gecos description homedirectory loginshell
Jul 23 09:18:57 server slapd[4216]: conn=76 op=1 RESULT tag=101 err=32
text=Jul 23 09:18:57 server slapd[4182]: conn=76 fd=13 closed
In other words: WHAT THE HELL THIS DAMNED SOLARIS USE THE OU
'PEOPLE'?!?!?!
I can´t use this OU. I tried:
Why do yopu say that "SOLARIS USE THE OU 'PEOPLE' ?" where do you see
that ?
Please, look it:
Jul 23 09:18:57 server slapd[4216]: conn=76 op=1 SRCH
base="ou=people,dc=my,dc=domain" scope=1
The search base, in the ldapsearch, is "defaultSearchBase:
dc=my,dc=domain", but here appears the "ou=people". Outrageous! I thought
that only Windows told us what we "NEED" to use... ;-)
oops , sorry didn't check enough the logs , however ou=people it quite
standard, it's the standard location for PosixAccount objects , maybe
defined in RFC2307 ...
Anyway, it's tru that my users are under the ou=people
here's my dn for example:
dn: uid=procacci,ou=People,dc=int-evry,dc=fr
Well, our site needs a diferenttiation between students, doctors,
employees, professors, etc. I don´t want this OU 'people'.
if solaris defaults cannot be changed, maybe you can play with openldap
rewrites or maps, cf man slapd-ldap and slapd-meta, or have an alias
(don't think it's supported now with 2.1.X, maybe back in 2.2.X ?)
ou=people pointing to ou=students ? not very good though ...
however it's a "subtree" search, so putting your students, professors,
employees just below a ou=people would be fine.
in the logs above there is an error searching posixAccount attributes
(field of /etc/passwd !)
Jul 23 09:18:57 server slapd[4216]: conn=76 op=1 SRCH attr=cn uid
uidnumber
gidnumber gecos description homedirectory loginshell
Jul 23 09:18:57 server slapd[4216]: conn=76 op=1 RESULT tag=101 err=32
text=trying to
login with has these attributes ? are your ACL positioned correctly ->
the proxy-agent you created must have read access on these attributes !
Hum. In fact, when I tried the comand:
# ldapsearch -x -D "cn=proxyagent,ou=contasIT,dc=my,dc=domain" -W
Enter LDAP Password:
ldap_bind: Insufficient access (50)
I was included this line in my 'slapd.conf':
by dn="cn=proxyagent,ou=contasIT,dc=pucrs,dc=br" read
Is it necessary write access? For change password, for example. I tried the
command above again and the result was apparently satisfactory:
No, changing the password will be done by the user's binddn not
proxy-agent, so there should be a self write on userpassword .
# user1, funcs, my.domain
dn: uid=user1,ou=funcs,dc=my,dc=domain
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user1
sn: sobre
cn: nome
cn: nome sobrenome
uidNumber: 1010
gidNumber: 40
homeDirectory: /home/funcs/user1
loginShell: /bin/bash
userPassword:: $$$secret$$$=
But, when I tried to login... the same error:
Jul 23 12:20:46 server slapd[4377]: conn=2 fd=13 ACCEPT from
IP=200.188.161.4:33731 (IP=0.0.0.0:389)
Jul 23 12:20:46 server slapd[4379]: conn=2 op=0 BIND
dn="cn=proxyagent,ou=contasIT,dc=my,dc=domain" method=128
Jul 23 12:20:46 server slapd[4379]: conn=2 op=0 BIND
dn="cn=proxyagent,ou=contasIT,dc=my,dc=domain" mech=simple ssf=0
Jul 23 12:20:46 server slapd[4379]: conn=2 op=0 RESULT tag=97 err=0 text=
Jul 23 12:20:46 server slapd[4380]: conn=2 op=1 SRCH
base="ou=people,dc=my,dc=domain" scope=1
filter="(&(objectClass=posixAccount)(uid=user1))"
Jul 23 12:20:46 server slapd[4380]: conn=2 op=1 SRCH attr=cn uid uidnumber
gidnumber gecos description homedirectory loginshell
Jul 23 12:20:46 server slapd[4380]: conn=2 op=1 RESULT tag=101 err=32 text=
Jul 23 12:20:46 server slapd[4380]: conn=2 op=2 UNBIND
Jul 23 12:20:46 server slapd[4380]: conn=2 fd=13 closed
Including the OU people! My god!!! :-(
I´m trying to find what means the error 32. Thanks for the alert. I didn´t
saw it before.
indeed, the problem is certainly the base search
"ou=people,dc=my,dc=domain", if you don't have it ... :-(
try what I proposed above about maps, alias, rewrite, move your ou under
ou=people, maybe someone on the list have better idea ? what about
solaris possibilities, they already have attributeMaps and
objectClassMaps ...
I kept on using only ldapclient solaris native ldap command without
manually editing files, and it works just fine. playing with these file
can be confusing ...
Excelent definition. :-)
Thanks a lot again. Has any additional idea?
Best regards
good luck :-)