Re: LDAP Access

[Mark Torluemke]

I do not support the position of what appears to be dramatically changing
access without a tangible migration plan -- I feel like we should comply
with the "principle of least surprise" in this case.



On Fri, Jun 2, 2017 at 8:28 AM, Jeremy Mitchell <mitchell...@gmail.com>
wrote:

> I'm fine merging Rob's PR -
> https://github.com/apache/incubator-trafficcontrol/pull/627
>
> as long as it's understood that pure LDAP users (users with no user in the
> tm_user table) will not work for 99% of the UI or the API.
>
> If they want to get back that 99%, they need to have a user created for
> them in the tm_user table where username=their ldap username...
>
> jeremy
>
>
> On Thu, Jun 1, 2017 at 12:20 PM, Dave Neuman <neu...@apache.org> wrote:
>
> > Just because we *can* do something doesn't mean we *should* do something.
> > I don't think we should try to over engineer this part of the system and
> > make it any more complicated than it needs to be.
> > I think Rob's PR should be merged so that LDAP users, by default, have
> very
> > limited capabilities.
> >
> > On Thu, Jun 1, 2017 at 10:16 AM, Robert Butts <robert.o.bu...@gmail.com>
> > wrote:
> >
> > > > that ship has sailed when the roles/capabilities model was agreed
> upon
> > >
> > > I don't agree. We could configure PostgreSQL Roles and Row Security
> > > Policies with the same capabilities, and the same UI. Users would click
> > the
> > > "create role" or "assign capability" button, and the UI would issue an
> > API
> > > call which issues a SQL command to create or assign the appropriate
> > > PostgreSQL Roles and Policies. Same model, different backend.
> > >
> > > On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would
> > _be_
> > > > PostgreSQL users. There wouldn't be a single "trafficops" Postgres
> > user,
> > > > every TO user would have their own user in Postgres itself.
> > > >
> > > > ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that
> > ship
> > > > has sailed when the roles/capabilities model was agreed upon and is
> > > > currently in the works...
> > > >
> > > > Just to clarify for others, currently, when you login via LDAP and no
> > > user
> > > > is found in the tm_user table with the same username, we assign the
> > > > "read-only" role to the "current user". Rob doesn't think (and he's
> > > > probably right) that the "read-only" role is restrictive enough for
> > these
> > > > LDAP only users. There are lots of GET routes that "read-only" users
> > can
> > > > access that contain "sensitive" info... (depending on your definition
> > of
> > > > sensitive)
> > > >
> > > > Anyhow, with this PR -
> > > > https://github.com/apache/incubator-trafficcontrol/pull/544 - the
> > > concept
> > > > of "capabilities" was introducedroles can now have
> > capabilitiesso
> > > > in theory we could create a role called "Graph Viewer" or something
> > which
> > > > maps to the cdn-graph-read capability that maps to certain api
> > > > endpoints...and then the "Graph Viewer" role would be automatically
> > > > assigned to LDAP only users..just an example.
> > > >
> > > > ^^ however the role/capabilities thing only applies to the API (not
> the
> > > > current TO UI) and was to be enforced by the API gateway
> > > >
> > > > In my opinion, trying to do what's best for the TO UI and the TO API
> at
> > > the
> > > > same time is very difficult, thus, my push to deprecate the TO UI and
> > the
> > > > entire UI namespace of endpoints, in favor of the TO API and the API
> > > > namespace... TO API + API Gateway + Roles/Capabilities gives us more
> > > > granularity
> > > >
> > > > Jeremy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo <els...@apache.org>
> wrote:
> > > >
> > > > > We use LDAP all the time. It's optional of course, but in our
> > > > > deployment nobody should be using local accounts un

Re: LDAP Access

[Dave Neuman]

Just because we *can* do something doesn't mean we *should* do something.
I don't think we should try to over engineer this part of the system and
make it any more complicated than it needs to be.
I think Rob's PR should be merged so that LDAP users, by default, have very
limited capabilities.

On Thu, Jun 1, 2017 at 10:16 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:

> > that ship has sailed when the roles/capabilities model was agreed upon
>
> I don't agree. We could configure PostgreSQL Roles and Row Security
> Policies with the same capabilities, and the same UI. Users would click the
> "create role" or "assign capability" button, and the UI would issue an API
> call which issues a SQL command to create or assign the appropriate
> PostgreSQL Roles and Policies. Same model, different backend.
>
> On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <mitchell...@gmail.com>
> wrote:
>
> > > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_
> > PostgreSQL users. There wouldn't be a single "trafficops" Postgres user,
> > every TO user would have their own user in Postgres itself.
> >
> > ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that ship
> > has sailed when the roles/capabilities model was agreed upon and is
> > currently in the works...
> >
> > Just to clarify for others, currently, when you login via LDAP and no
> user
> > is found in the tm_user table with the same username, we assign the
> > "read-only" role to the "current user". Rob doesn't think (and he's
> > probably right) that the "read-only" role is restrictive enough for these
> > LDAP only users. There are lots of GET routes that "read-only" users can
> > access that contain "sensitive" info... (depending on your definition of
> > sensitive)
> >
> > Anyhow, with this PR -
> > https://github.com/apache/incubator-trafficcontrol/pull/544 - the
> concept
> > of "capabilities" was introducedroles can now have capabilitiesso
> > in theory we could create a role called "Graph Viewer" or something which
> > maps to the cdn-graph-read capability that maps to certain api
> > endpoints...and then the "Graph Viewer" role would be automatically
> > assigned to LDAP only users..just an example.
> >
> > ^^ however the role/capabilities thing only applies to the API (not the
> > current TO UI) and was to be enforced by the API gateway
> >
> > In my opinion, trying to do what's best for the TO UI and the TO API at
> the
> > same time is very difficult, thus, my push to deprecate the TO UI and the
> > entire UI namespace of endpoints, in favor of the TO API and the API
> > namespace... TO API + API Gateway + Roles/Capabilities gives us more
> > granularity
> >
> > Jeremy
> >
> >
> >
> >
> >
> > On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo <els...@apache.org> wrote:
> >
> > > We use LDAP all the time. It's optional of course, but in our
> > > deployment nobody should be using local accounts unless they're not in
> > > LDAP for some reason (external users, portal users, etc).
> > > Application/API accounts could go either way, but users of the TO UI
> > > should use LDAP whenever possible to avoid having to manage multiple
> > > accounts/passwords.
> > >
> > > Basic enterprise operations best practices dictate centralized user
> > > management, and most enterprises do so using some sort of LDAP based
> > > directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on moving
> > > away from this model. If anything we need to make our LDAP
> > > implementation more flexible.
> > > --
> > > Thanks,
> > > Jeff
> > >
> > >
> > > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <dewr...@gmail.com>
> > > wrote:
> > > > I have a question in a similar vein, how often do we really use LDAP?
> > My
> > > > understanding is we created LDAP access to allow external users in to
> > see
> > > > our TO Graphs.  Now that graphs are in Graphana is the need for LDAP
> > > still
> > > > needed?  If we require anyone using TO or the TO API to be in the
> > > database
> > > > it would alleviate this LDAP security issue entirely.
> > > >
> > > >  I also wonder if we shouldn't try to leverage transitioning our user
> > > > management to Postgres.  Postgres has many options for authentication
> > > (as I
&g

Re: LDAP Access

[Robert Butts]

> that ship has sailed when the roles/capabilities model was agreed upon

I don't agree. We could configure PostgreSQL Roles and Row Security
Policies with the same capabilities, and the same UI. Users would click the
"create role" or "assign capability" button, and the UI would issue an API
call which issues a SQL command to create or assign the appropriate
PostgreSQL Roles and Policies. Same model, different backend.

On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <mitchell...@gmail.com>
wrote:

> > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_
> PostgreSQL users. There wouldn't be a single "trafficops" Postgres user,
> every TO user would have their own user in Postgres itself.
>
> ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that ship
> has sailed when the roles/capabilities model was agreed upon and is
> currently in the works...
>
> Just to clarify for others, currently, when you login via LDAP and no user
> is found in the tm_user table with the same username, we assign the
> "read-only" role to the "current user". Rob doesn't think (and he's
> probably right) that the "read-only" role is restrictive enough for these
> LDAP only users. There are lots of GET routes that "read-only" users can
> access that contain "sensitive" info... (depending on your definition of
> sensitive)
>
> Anyhow, with this PR -
> https://github.com/apache/incubator-trafficcontrol/pull/544 - the concept
> of "capabilities" was introducedroles can now have capabilitiesso
> in theory we could create a role called "Graph Viewer" or something which
> maps to the cdn-graph-read capability that maps to certain api
> endpoints...and then the "Graph Viewer" role would be automatically
> assigned to LDAP only users..just an example.
>
> ^^ however the role/capabilities thing only applies to the API (not the
> current TO UI) and was to be enforced by the API gateway
>
> In my opinion, trying to do what's best for the TO UI and the TO API at the
> same time is very difficult, thus, my push to deprecate the TO UI and the
> entire UI namespace of endpoints, in favor of the TO API and the API
> namespace... TO API + API Gateway + Roles/Capabilities gives us more
> granularity
>
> Jeremy
>
>
>
>
>
> On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo <els...@apache.org> wrote:
>
> > We use LDAP all the time. It's optional of course, but in our
> > deployment nobody should be using local accounts unless they're not in
> > LDAP for some reason (external users, portal users, etc).
> > Application/API accounts could go either way, but users of the TO UI
> > should use LDAP whenever possible to avoid having to manage multiple
> > accounts/passwords.
> >
> > Basic enterprise operations best practices dictate centralized user
> > management, and most enterprises do so using some sort of LDAP based
> > directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on moving
> > away from this model. If anything we need to make our LDAP
> > implementation more flexible.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <dewr...@gmail.com>
> > wrote:
> > > I have a question in a similar vein, how often do we really use LDAP?
> My
> > > understanding is we created LDAP access to allow external users in to
> see
> > > our TO Graphs.  Now that graphs are in Graphana is the need for LDAP
> > still
> > > needed?  If we require anyone using TO or the TO API to be in the
> > database
> > > it would alleviate this LDAP security issue entirely.
> > >
> > >  I also wonder if we shouldn't try to leverage transitioning our user
> > > management to Postgres.  Postgres has many options for authentication
> > (as I
> > > mentioned at the Summit), which would allow for more flexibility at TO
> > > installations.
> > >
> > > -Dewayne
> > >
> > > On Wed, May 31, 2017 at 9:24 AM, Robert Butts <
> robert.o.bu...@gmail.com>
> > > wrote:
> > >
> > >> We have a PR https://github.com/apache/incubator-trafficcontrol/pull/
> > 627
> > >> to
> > >> change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> > >> database to view non-sensitive information, like graphs and total CDN
> > >> bandwidth.
> > >>
> > >> To be clear, users will still be able to authenticate with LDAP, as
> > long as
> > >> their user name is in the database. T

Re: LDAP Access

[Jeremy Mitchell]

> @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_
PostgreSQL users. There wouldn't be a single "trafficops" Postgres user,
every TO user would have their own user in Postgres itself.

^^ Sounds like we need a Postgres DBA for that :) Plus, I think that ship
has sailed when the roles/capabilities model was agreed upon and is
currently in the works...

Just to clarify for others, currently, when you login via LDAP and no user
is found in the tm_user table with the same username, we assign the
"read-only" role to the "current user". Rob doesn't think (and he's
probably right) that the "read-only" role is restrictive enough for these
LDAP only users. There are lots of GET routes that "read-only" users can
access that contain "sensitive" info... (depending on your definition of
sensitive)

Anyhow, with this PR -
https://github.com/apache/incubator-trafficcontrol/pull/544 - the concept
of "capabilities" was introducedroles can now have capabilitiesso
in theory we could create a role called "Graph Viewer" or something which
maps to the cdn-graph-read capability that maps to certain api
endpoints...and then the "Graph Viewer" role would be automatically
assigned to LDAP only users..just an example.

^^ however the role/capabilities thing only applies to the API (not the
current TO UI) and was to be enforced by the API gateway

In my opinion, trying to do what's best for the TO UI and the TO API at the
same time is very difficult, thus, my push to deprecate the TO UI and the
entire UI namespace of endpoints, in favor of the TO API and the API
namespace... TO API + API Gateway + Roles/Capabilities gives us more
granularity

Jeremy





On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo <els...@apache.org> wrote:

> We use LDAP all the time. It's optional of course, but in our
> deployment nobody should be using local accounts unless they're not in
> LDAP for some reason (external users, portal users, etc).
> Application/API accounts could go either way, but users of the TO UI
> should use LDAP whenever possible to avoid having to manage multiple
> accounts/passwords.
>
> Basic enterprise operations best practices dictate centralized user
> management, and most enterprises do so using some sort of LDAP based
> directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on moving
> away from this model. If anything we need to make our LDAP
> implementation more flexible.
> --
> Thanks,
> Jeff
>
>
> On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <dewr...@gmail.com>
> wrote:
> > I have a question in a similar vein, how often do we really use LDAP?  My
> > understanding is we created LDAP access to allow external users in to see
> > our TO Graphs.  Now that graphs are in Graphana is the need for LDAP
> still
> > needed?  If we require anyone using TO or the TO API to be in the
> database
> > it would alleviate this LDAP security issue entirely.
> >
> >  I also wonder if we shouldn't try to leverage transitioning our user
> > management to Postgres.  Postgres has many options for authentication
> (as I
> > mentioned at the Summit), which would allow for more flexibility at TO
> > installations.
> >
> > -Dewayne
> >
> > On Wed, May 31, 2017 at 9:24 AM, Robert Butts <robert.o.bu...@gmail.com>
> > wrote:
> >
> >> We have a PR https://github.com/apache/incubator-trafficcontrol/pull/
> 627
> >> to
> >> change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> >> database to view non-sensitive information, like graphs and total CDN
> >> bandwidth.
> >>
> >> To be clear, users will still be able to authenticate with LDAP, as
> long as
> >> their user name is in the database. This only prevents access for LDAP
> >> users whose name is not in the database.
> >>
> >> If you have LDAP-only users who need access, you can simply add their
> user
> >> name to the Traffic Ops database to allow continued access. They don't
> even
> >> need a password, simply inserting the username is sufficient.
> >>
> >> LDAP is a security risk, especially for large organizations. Allowing
> all
> >> non-CDN personnel in the organization full information access, even
> >> read-only, means an attacker has only to compromise a single account in
> the
> >> organization, and they can see the full list of CDN server IPs and
> FDQNs,
> >> as well as the specific ATS and CentOS versions, in order to take
> advantage
> >> of known exploits against those versions.
> >>
> >> Does anyone have any issues with that? Is anyone using LDAP without
> >> usernames in the database, who needs continued access? We just want to
> make
> >> sure we're not breaking anyone before we merge this, and figure out a
> >> solution if we are. Thanks,
> >>
>

Re: LDAP Access

[Robert Butts]

@mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_
PostgreSQL users. There wouldn't be a single "trafficops" Postgres user,
every TO user would have their own user in Postgres itself.

PostgreSQL has row-level security, which makes such a thing possible. You
can configure a user to only have access to certain rows, for example, only
their Delivery Service in the `deliveryservice` table.

It's definitely worth considering. But we should be aware it's not trivial.
It would require a significant amount of configuration, and code to do that
configuration, to make it possible to create users and assign them the
complex permissions required.

Also worth noting, we would have to move to PostgreSQL users for
https://github.com/begriffs/postgrest if we ever transition the TO API to
PostgREST (Which I support, it means drastically less code we have to
maintain).

It's also possible to set up LDAP with Postgres:
https://www.postgresql.org/docs/9.4/static/auth-methods.html#AUTH-LDAP


On Thu, Jun 1, 2017 at 9:41 AM, Jeremy Mitchell <mitchell...@gmail.com>
wrote:

> > I also wonder if we shouldn't try to leverage transitioning our user
> management to Postgres.
>
> I don't understand what that means. We do use Postgres for user
> management...there is a tm_user table in Postgres and a user has a role
> (which will soon have capabilities). That is how users are managed and it
> would be a pretty big shift to move away from that...
>
> I think I'm fine with Rob's PR -
> https://github.com/apache/incubator-trafficcontrol/pull/627
>
> which will basically break everything if you are depending on LDAP only.
> For example, if my LDAP username/pass is jeremy/password but there is no
> user in the tm_user table with username=jeremy, then my authentication will
> work but I will not have a pleasant experience in Traffic Ops as pretty
> much every route will now result in a 404.
>
> ..but the workaround is to create a user with username=jeremy and assign me
> a role..
>
> and that's rob's intent..if you are ldap only, nothing really
> works...(except a few routes)
>
> Jeremy
>
> On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <dewr...@gmail.com>
> wrote:
>
> > I have a question in a similar vein, how often do we really use LDAP?  My
> > understanding is we created LDAP access to allow external users in to see
> > our TO Graphs.  Now that graphs are in Graphana is the need for LDAP
> still
> > needed?  If we require anyone using TO or the TO API to be in the
> database
> > it would alleviate this LDAP security issue entirely.
> >
> >  I also wonder if we shouldn't try to leverage transitioning our user
> > management to Postgres.  Postgres has many options for authentication
> (as I
> > mentioned at the Summit), which would allow for more flexibility at TO
> > installations.
> >
> > -Dewayne
> >
> > On Wed, May 31, 2017 at 9:24 AM, Robert Butts <robert.o.bu...@gmail.com>
> > wrote:
> >
> > > We have a PR https://github.com/apache/incubator-trafficcontrol/pull/
> 627
> > > to
> > > change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> > > database to view non-sensitive information, like graphs and total CDN
> > > bandwidth.
> > >
> > > To be clear, users will still be able to authenticate with LDAP, as
> long
> > as
> > > their user name is in the database. This only prevents access for LDAP
> > > users whose name is not in the database.
> > >
> > > If you have LDAP-only users who need access, you can simply add their
> > user
> > > name to the Traffic Ops database to allow continued access. They don't
> > even
> > > need a password, simply inserting the username is sufficient.
> > >
> > > LDAP is a security risk, especially for large organizations. Allowing
> all
> > > non-CDN personnel in the organization full information access, even
> > > read-only, means an attacker has only to compromise a single account in
> > the
> > > organization, and they can see the full list of CDN server IPs and
> FDQNs,
> > > as well as the specific ATS and CentOS versions, in order to take
> > advantage
> > > of known exploits against those versions.
> > >
> > > Does anyone have any issues with that? Is anyone using LDAP without
> > > usernames in the database, who needs continued access? We just want to
> > make
> > > sure we're not breaking anyone before we merge this, and figure out a
> > > solution if we are. Thanks,
> > >
> >
>

Re: LDAP Access

[Jeremy Mitchell]

> I also wonder if we shouldn't try to leverage transitioning our user
management to Postgres.

I don't understand what that means. We do use Postgres for user
management...there is a tm_user table in Postgres and a user has a role
(which will soon have capabilities). That is how users are managed and it
would be a pretty big shift to move away from that...

I think I'm fine with Rob's PR -
https://github.com/apache/incubator-trafficcontrol/pull/627

which will basically break everything if you are depending on LDAP only.
For example, if my LDAP username/pass is jeremy/password but there is no
user in the tm_user table with username=jeremy, then my authentication will
work but I will not have a pleasant experience in Traffic Ops as pretty
much every route will now result in a 404.

..but the workaround is to create a user with username=jeremy and assign me
a role..

and that's rob's intent..if you are ldap only, nothing really
works...(except a few routes)

Jeremy

On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <dewr...@gmail.com>
wrote:

> I have a question in a similar vein, how often do we really use LDAP?  My
> understanding is we created LDAP access to allow external users in to see
> our TO Graphs.  Now that graphs are in Graphana is the need for LDAP still
> needed?  If we require anyone using TO or the TO API to be in the database
> it would alleviate this LDAP security issue entirely.
>
>  I also wonder if we shouldn't try to leverage transitioning our user
> management to Postgres.  Postgres has many options for authentication (as I
> mentioned at the Summit), which would allow for more flexibility at TO
> installations.
>
> -Dewayne
>
> On Wed, May 31, 2017 at 9:24 AM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
>
> > We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627
> > to
> > change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> > database to view non-sensitive information, like graphs and total CDN
> > bandwidth.
> >
> > To be clear, users will still be able to authenticate with LDAP, as long
> as
> > their user name is in the database. This only prevents access for LDAP
> > users whose name is not in the database.
> >
> > If you have LDAP-only users who need access, you can simply add their
> user
> > name to the Traffic Ops database to allow continued access. They don't
> even
> > need a password, simply inserting the username is sufficient.
> >
> > LDAP is a security risk, especially for large organizations. Allowing all
> > non-CDN personnel in the organization full information access, even
> > read-only, means an attacker has only to compromise a single account in
> the
> > organization, and they can see the full list of CDN server IPs and FDQNs,
> > as well as the specific ATS and CentOS versions, in order to take
> advantage
> > of known exploits against those versions.
> >
> > Does anyone have any issues with that? Is anyone using LDAP without
> > usernames in the database, who needs continued access? We just want to
> make
> > sure we're not breaking anyone before we merge this, and figure out a
> > solution if we are. Thanks,
> >
>

Re: LDAP Access

[Dewayne Richardson]

I have a question in a similar vein, how often do we really use LDAP?  My
understanding is we created LDAP access to allow external users in to see
our TO Graphs.  Now that graphs are in Graphana is the need for LDAP still
needed?  If we require anyone using TO or the TO API to be in the database
it would alleviate this LDAP security issue entirely.

 I also wonder if we shouldn't try to leverage transitioning our user
management to Postgres.  Postgres has many options for authentication (as I
mentioned at the Summit), which would allow for more flexibility at TO
installations.

-Dewayne

On Wed, May 31, 2017 at 9:24 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:

> We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627
> to
> change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> database to view non-sensitive information, like graphs and total CDN
> bandwidth.
>
> To be clear, users will still be able to authenticate with LDAP, as long as
> their user name is in the database. This only prevents access for LDAP
> users whose name is not in the database.
>
> If you have LDAP-only users who need access, you can simply add their user
> name to the Traffic Ops database to allow continued access. They don't even
> need a password, simply inserting the username is sufficient.
>
> LDAP is a security risk, especially for large organizations. Allowing all
> non-CDN personnel in the organization full information access, even
> read-only, means an attacker has only to compromise a single account in the
> organization, and they can see the full list of CDN server IPs and FDQNs,
> as well as the specific ATS and CentOS versions, in order to take advantage
> of known exploits against those versions.
>
> Does anyone have any issues with that? Is anyone using LDAP without
> usernames in the database, who needs continued access? We just want to make
> sure we're not breaking anyone before we merge this, and figure out a
> solution if we are. Thanks,
>

Re: LDAP Access

[Robert Butts]

> Is there an option to entirely block someone from even basic TO access
despite authenticating with LDAP?

Other than disabling LDAP? No. I wouldn't object to adding a config, but I
don't know when I'd be able to find the time. The current version allows
entire read-only access, so this PR isn't a step away from that direction,
at any rate.

The routes currently permitted should be ok from a security perspective to
make public, though. They only include overall graphs and bandwidth, a la
http://store.steampowered.com/stats/content/ . Even the Help page, which
includes the TO version, is prohibited.

On Wed, May 31, 2017 at 9:56 AM, David Neuman 
wrote:

> If you know the user id then there is a DISALLOWED role you can assign them
> to.
>

Re: LDAP Access

[David Neuman]

If you know the user id then there is a DISALLOWED role you can assign them
to.

Re: LDAP Access

[Eric Friedrich (efriedri)]

Is there an option to entirely block someone from even basic TO access despite 
authenticating with LDAP?


> On May 31, 2017, at 11:24 AM, Robert Butts  wrote:
> 
> We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627 to
> change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
> database to view non-sensitive information, like graphs and total CDN
> bandwidth.
> 
> To be clear, users will still be able to authenticate with LDAP, as long as
> their user name is in the database. This only prevents access for LDAP
> users whose name is not in the database.
> 
> If you have LDAP-only users who need access, you can simply add their user
> name to the Traffic Ops database to allow continued access. They don't even
> need a password, simply inserting the username is sufficient.
> 
> LDAP is a security risk, especially for large organizations. Allowing all
> non-CDN personnel in the organization full information access, even
> read-only, means an attacker has only to compromise a single account in the
> organization, and they can see the full list of CDN server IPs and FDQNs,
> as well as the specific ATS and CentOS versions, in order to take advantage
> of known exploits against those versions.
> 
> Does anyone have any issues with that? Is anyone using LDAP without
> usernames in the database, who needs continued access? We just want to make
> sure we're not breaking anyone before we merge this, and figure out a
> solution if we are. Thanks,

LDAP Access

[Robert Butts]

We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627 to
change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
database to view non-sensitive information, like graphs and total CDN
bandwidth.

To be clear, users will still be able to authenticate with LDAP, as long as
their user name is in the database. This only prevents access for LDAP
users whose name is not in the database.

If you have LDAP-only users who need access, you can simply add their user
name to the Traffic Ops database to allow continued access. They don't even
need a password, simply inserting the username is sufficient.

LDAP is a security risk, especially for large organizations. Allowing all
non-CDN personnel in the organization full information access, even
read-only, means an attacker has only to compromise a single account in the
organization, and they can see the full list of CDN server IPs and FDQNs,
as well as the specific ATS and CentOS versions, in order to take advantage
of known exploits against those versions.

Does anyone have any issues with that? Is anyone using LDAP without
usernames in the database, who needs continued access? We just want to make
sure we're not breaking anyone before we merge this, and figure out a
solution if we are. Thanks,