Subject: Re: result code for a deleted identity on a connection

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 2 May 2003 22:40:55 +0200

Vijay KN writes:
> I am not very clear how a server can continue to serve requests on the
> connection. If new objects are created on the connection after the user
> object deletion, then what is the user-id assigned by the server as the
> creator/owner for such objects (since the user object has been deleted)
> ?

If the server did not detect the problem, it would just continue using
the user ID it did before.  It couldn't do that if it needed to look
up the ID object in the directory for each update, of course.  But if
the ID is just the bind DN, or if the info was cached, it would work.

> Audit logs would show that objects were created by the user, after
> the user object had been deleted. Isn't this a problem ?

Depends on what the logs are used for, or if they are used at all.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 2 May 2003 22:53:11 +0200

Vithalprasad Gaitonde writes:
> "I suspect it might be a lot of work for servers to keep track of this.
> So I think the server should have that option, but it should also have
> the option not to notice this condition and keep serving requests as
> if nothing happened."
> 
> Well...wouldn't this be a security breach. The object may have been
> deleted by the administrator as he is an invalid user for the directory
> (e.g. left the Organization). In such a case, it would be inappropriate
> for the user to be allowed access.

He'd have to keep an authenticated LDAP connection from an off-site host
alive when he anticipated that he'd be fired, but if so it would be a
problem, yes.  If that's a scenario you worry about, you'll need a
server which handles it.  I just think that in most cases the situation
is unlikely enough that it can be made a QoI issue, but if server
implementors don't mind implementing it I'm not going to quarrel.

If we are going to worry about the bind credentials being invalidated,
I'd be more worried about users who bound with valid credentials but
then the attribute with the credentials (password or certificate) was
deleted or modified from the user's object.  That happens frequently
here, and regularly because the user has broken the rules and gets
temporarily closed out from the system.  If so, it should be allowed to
configure the server to only start returning failures e.g. 4 hours after
the object was changed, though, since there are also 'benign' situations
where the password changes.  We don't want users thrown out of the
system immediately in these cases.  I don't know if the same can apply
when the bind object gets deleted.

> invalidCredentials may be a misleading error code to return as the bind
> has already succeeded.

Well, the bind had succeeded, but now the bind credentials have become
invalid.  And the code can't be mistaken for anything else, since no
other operation than bind normally returns it.

-- 
Hallvard