RE: LDAP

> Kurt,
> You are correct to point out the ability to create and modify user
> profiles via LDAP.
> 
> I also agree that there are more serious problems with AS/400 security.

That's not what I meant.  I meant that if this is actually an issue for
someone then they have other bigger security problems.  I hope that when you
say that there are serious problems with AS/400 security that you actually
mean there are serious problems with the way some people have implemented
security on their AS/400.

> However, I believe that an active LDAP server does create a security
> exposure.
> 
> The LDAP server projected backend allows any AS/400 user to enumerate all
> user profiles he has access to, and to display details about this profile.
> That includes listing the group profile the user may belong to.
> Many AS400 applications use group profiles to manage access to the
> applicxation objects. Take BPCS for example. All BPCS users belong to the
> SSA group,
> and a BPCS user can retrieve the full list of all other BPCS users via
> LDAP, by querying the SSA profile.

Someone that is capable of installing and using an LDAP browser, and has
gone to the lengths to figure out how to log in to the projected backend, is
surely able to figure the companies naming convention; then all they need is
a company directory.  I have never used BPCS but in JD Edwards I would just
go look in the address book.

> All security experts recommend that acquiring a list of accounts on a
> server should not be made easy, because it opens some new attack vectors,
> like dictionary attacks and social engineering.

> On top of this, LDAP is not protected by the current iSeries security
> products, and telnet is. 

What iSeries security products are you referring to?

> You can fully manage and audit the telnet connections to your server, 

What do you mean by fully manage?  There is very little information provided
to a Telnet exit program.  All you can count on is Device name and IP
Address - user ID is only available if the user is trying to do
automatically sign-on.  The Telnet exit is only useful, from a security
standpoint, for logging and/or limiting connections by address.

> and while ldap has internal management and
> auditing capabilities, they are separated from the system auditing of from
> any other system log.

Actually the audit records are cut in QAUDJRN but I think the non-iSeries
way of logging in Directory Server is still available.  The projected
backend is implemented with commands and APIs and normal auditing for those
would still apply.

> Therefore, I recommend to turn LDAP off, unless there is business usage of
> it, and the sysadmin knows how to manage it.

>From what I'm told in V5R3 and later there are some system management
functions that will require the use of LDAP.  I'm not sure what all of them
are but EIM is one.  

> Consider ldap as a chink in the as400 armor. It is not like the
> vulnerabilities that are periodically found on other platforms, the as400
> has more severe problems, but nonetheless it is a chink in the armor.

That explains a lot - 1) why they weight so damn much and 2) why they are
called bullet proof systems!

> 
> Shalom
> 
> 
> ----- Original Message -----
> From: midrange-l-request@xxxxxxxxxxxx
> To: midrange-l@xxxxxxxxxxxx
> Sent: 4/17/05 1:00 PM
> Subject: MIDRANGE-L Digest, Vol 4, Issue 713
> 
> > date: Sun, 17 Apr 2005 11:04:09 -0500
> > from: "Kurt Goolsbee"
> > subject: RE: LDAP
> >
> > Shalom,
> >
> > If you are going to promote selling your book and information here then
> you
> > should at least provide the full explanation of what you are alleging.
> >
> > The interface you are referring to is available on the IBM Directory
> Server
> > for OS/400, AIX and z/OS.  It has different names on each platform but
> it is
> > available and it is read/write not just read.  When a request is made to
> the
> > directory context for the projected backend the Directory Server uses
> APIs
> > rather than database calls to service the request.  This keeps you (or
> > OS400) from having to synchronize account data between the user
> repository
> > and the directory.  When a client sends a modify, add or delete
> operation
> > for a user to the server it will format the corresponding OS400
> CRTUSRPRF,
> > DLTUSRPRF or CHGUSRPRF command and attempt to execute it.  What is the
> most
> > important to note is that in order to use the projected backend you must
> be
> > authenticated using a projected user account.  This is required so that
> the
> > directory server can service the request under the authority of the
> client.
> > Bottom line is that you can't get a list of users that you do not have
> > authority to see and likewise you can't modify users you don't have
> > authority to.  Having the LDAP server open is no smaller or greater risk
> > than having the telnet server open.  If it is then I'd argue that you
> have
> > more serious security issues to deal with than worrying about this.
> >
> > I talked to THE OS400 Security Expert about this alleged exposure a few
> > weeks ago and their response was that this is not an issue.
> >
> > Kurt
> >
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of shalom@xxxxxxxxxx
> > Sent: Sunday, April 17, 2005 9:35 AM
> > To: midrange-l@xxxxxxxxxxxx
> > Subject: RE: LDAP
> >
> > Hey,
> > You can't create new system user profiles via LDAP.
> >
> > You can only list system user profiles via LDAP.
> > For an interesting example of the security problem this may present,
> > read the relevant article on my web site, at
> www.venera.com/downloads.htm
> >
> > (or just google for as400 ldap)
> >
> > Shalom Carmel
> > --
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.