[Date Prev][Date Next]
Re: Bind DN not logged with GSSAPI binds (ITS#2283)
Okay, I understand your point. I guess what I'm looking at, is the logs
don't reflect back to me, where I'm getting my permissions at. Now, I
obviously already know this, but someone else looking at the logs, and
comparing it to the slapd.acl file we have, isn't going to know.
So, here is what I see:
What would be handy, is if the Bind DN (or something else) would reflect is
giving me the permissions into the database, like
"supervisor,cn=applications,dc=stanford,dc=edu", which is the group I
access to *
by dn.base="cn=replicator,cn=Applications,dc=stanford,dc=edu" write
by group.base="cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu" read
by * break
Unfortunately, this information is not available at loglevel 256:
Jan 22 12:46:41 ldap1.Stanford.EDU slapd: [ID 951063 local4.debug]
conn=155 op=3 BIND authcid="firstname.lastname@example.org"
Jan 22 12:46:41 ldap1.Stanford.EDU slapd: [ID 988814 local4.debug]
conn=155 op=3 AUTHZ
Jan 22 12:46:41 ldap1.Stanford.EDU slapd: [ID 902418 local4.debug]
conn=155 op=4 SRCH base="dc=stanford,dc=edu" scope=2 filter="(uid=quanah)"
Bumping up the logging to 65535:
Jan 22 12:49:07 ldap1.Stanford.EDU slapd: [ID 110968 local4.debug] <=
tanford,dc=edu" is in "cn=supervisor,cn=applications,dc=stanford,dc=edu":
And that is really what tells me I'm binding as supervisor.
--On Wednesday, January 22, 2003 12:40 PM -0800 "Kurt D. Zeilenga"
> At 06:07 PM 1/21/2003, email@example.com wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.1.10
>> OS: Solaris 8
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (188.8.131.52)
>> In the past (due to a previous request, as I recall), openldap would log
>> the BIND dn of a person making a GSSAPI connection at loglevel 256.
> The authorization DN (which is not necessarily the bind DN) is
> logged both at 256 (STATS) and at 1 (TRACE). The message is
> labeled "AUTHZ" in 2.1.12 but will labeled "BIND" in the next
> release (for consistency with other messages).
>> It correctly
>> logs the authcid and the authzid now, but the resulting BIND dn (in the
>> case of group memberships) is not being logged.
> authzid is the authorization DN used for ACLs, etc..
>> It is important to know to what BIND DN
>> these two bits of information were eventually resolved to.
> A recent software message shows logging is working.
Senior Systems Administrator
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html