Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Cisco 877 MacSucks and Arpnips not working (Oliver Gorwits)
2. Re: AD/LDAP support for Netdisco (Michael Dano Config & Logs)
(Michael Dano)
3. Re: Cisco 877 MacSucks and Arpnips not working (Jeremy Bresley)
4. Re: AD/LDAP support for Netdisco (Michael Dano Config & Logs)
(Natxo Asenjo)
--- Begin Message ---
Hi Muris,
On 2015-03-06 10:26, Muris wrote:
In reply to Oliver, "and there is no need for the "root discovery
device" concept either."
Can you explain why this is the case? For example I'm having to
search
and put each device manually how can i just get it to discover the
whole network like net disco 1 ?
The first thing to understand is that in Netdisco 2 you *must* run the
backend daemon (netdisco-daemon) to have everything work properly.
You only need to discover one device (preferably a central one), and
then Netdisco 2 will discover all other devices and store them in the
database. Then according to the "schedule:" item in your configuration,
the discoverall job will trigger a review of your network (once per
day). This is the same as Netdisco 1 but a bit smarter/simpler, because
it's done in parallel across all known devices rather than starting at
the "root" each time.
Also i couldn't seem to find to individualy arpnip or macsuck devices
from command line, or do the whole network arpnip/macsuck from
command
line, is this available?
You can queue a "discoverall" "arpwalk" or "macwalk" from the command
line, but all this does is ask the netdisco-daemon to start the work (so
the command returns immediately). This is different to Netdisco 1 when
the *all/*walk commands were done in real time at the CLI. Please do
*not* use the CLI or cron to trigger regular *all/*walk jobs. Use the
"schedule:" configuration and netdisco-daemon. For single device actions
(discover/macsuck/arpnip), however, it is done in real time at the CLI.
See the netdisco-do documentation for more detail.
I hope this helps,
regards,
oliver.
--- End Message ---
--- Begin Message ---
Hi,
On Fri, Mar 6, 2015 at 09:04, Natxo Asenjo <[email protected]> wrote:
you need to show the (sanitized) apache ldap config then. If you do ldap
instead of ldaps of ldap+tls then it will still be just ldap withouth
encryption even though the web session between the apache host and the
browser will be secure (so the insecure connection will be between the
apache reverse proxy and the AD ldap servers (which might be more
acceptable if you trust your server lan, although I would go with secure
connections everywhere).
Both my Network Director and I agree we want the connection to be secure
all the way through the communication stream. For this reason I decided to
try and mimic the config that Natxo and Oliver worked on in
the netdisco-users Digest, Vol 95, Issue 4 - 8 Heres what I came up with
but doesn't seem to work.
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName xxNetdisco2.ad.baker.edu
ServerAdmin [email protected]
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/netdisco.access.log combined
ErrorLog /var/log/apache2/netdisco.error.log
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader unset X-REMOTE_USER
RequestHeader add X-REMOTE_USER %{RU}e
# RequestHeader unset X-REMOTE_USER
# RequestHeader set X-REMOTE_USER "%{REMOTE_USER}e" env=REMOTE_USER
<Location />
AuthType Basic
AuthName "Netdisco"
AuthBasicProvider ldap
AuthLDAPBindAuthoritative On
AuthLDAPURL "ldaps://
EISADC01.AD.BAKER.EDU:636/DC=AD,DC=BAKER,DC=EDU?sAMAccountName?sub?(objectClass=user)"
NONE
AuthLDAPBindDN "CN=SVCAccount,OU=Service,OU=Users,OU=Enterprise
Support,DC=AD,DC=BAKER,DC=EDU"
AuthLDAPBindPassword "ourpassword"
require ldap-group
CN=technology,OU=Organizational,OU=Security,OU=Groups,OU=Enterprise
Support,DC=AD,DC=BAKER,DC=EDU
</Location>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
# ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:5000/ retry=0 timeout=60
ProxyPassReverse / http://localhost:50000/
</VirtualHost>
</IfModule>
and in environments/deployment.yml I set:
trust_x_remote_user: true
as stated in the documentation. When I go to the web page I get a sign in
box enter the credentials and then get redirected to a 500 Internal Server
Error page with entries in the error log.
Here's the error log didn't know if I should attach the file or paste the
content. https://db.tt/znXGDQ70
I'm not sure what the issues is with. Just for reference the host is Ubuntu
14.04.02 LTS Server, latest Apache2 and Netdisco 2.031012
Mike Dano
IT Engineer
Security Services
Baker College
Information Technology
--- End Message ---
--- Begin Message ---
On 3/6/2015 10:59 AM, Oliver Gorwits wrote:
Hi Muris,
On 2015-03-06 10:26, Muris wrote:
In reply to Oliver, "and there is no need for the "root discovery
device" concept either."
Can you explain why this is the case? For example I'm having to
search
and put each device manually how can i just get it to discover the
whole network like net disco 1 ?
The first thing to understand is that in Netdisco 2 you *must* run the
backend daemon (netdisco-daemon) to have everything work properly.
You only need to discover one device (preferably a central one), and
then Netdisco 2 will discover all other devices and store them in the
database. Then according to the "schedule:" item in your configuration,
the discoverall job will trigger a review of your network (once per
day). This is the same as Netdisco 1 but a bit smarter/simpler, because
it's done in parallel across all known devices rather than starting at
the "root" each time.
Also i couldn't seem to find to individualy arpnip or macsuck devices
from command line, or do the whole network arpnip/macsuck from
command
line, is this available?
You can queue a "discoverall" "arpwalk" or "macwalk" from the command
line, but all this does is ask the netdisco-daemon to start the work (so
the command returns immediately). This is different to Netdisco 1 when
the *all/*walk commands were done in real time at the CLI. Please do
*not* use the CLI or cron to trigger regular *all/*walk jobs. Use the
"schedule:" configuration and netdisco-daemon. For single device actions
(discover/macsuck/arpnip), however, it is done in real time at the CLI.
See the netdisco-do documentation for more detail.
If the concern is the initial discovery of the devices on an ND2 install
rather than going forward, you can run a series of netdisco-do discover
-d host jobs from the CLI to import some/all of your devices. I did
this when we built our ND2 server initially, just exported a list of all
devices from ND1 and did a shell script to run through all the devices
and discover them. We have a L3VPN MPLS cloud that we don't see
connections between sites, so at a minimum we would have to discover our
router at each site and let ND pick up the core and access switches from
there. And things that don't speak CDP/LLDP would still need to be
added manually (Firewalls, load-balancers, WAN accelerators, etc)
As Oliver mentioned above, the discoverall jobs do a good job of keeping
things up to date, and discovering things like new access switches at a
site automatically. The only thing I remember ND1 having that I miss in
ND2 is the nodes not responding in X days report. An automatic way to
remove any nodes not reachable in X days would be a cool feature to have
as an alternative.
Jeremy "TheBrez" Bresley
[email protected]
--- End Message ---
--- Begin Message ---
hi Michael
On Fri, Mar 6, 2015 at 6:08 PM, Michael Dano <[email protected]> wrote:
> Both my Network Director and I agree we want the connection to be secure
> all the way through the communication stream. For this reason I decided to
> try and mimic the config that Natxo and Oliver worked on in
> the netdisco-users Digest, Vol 95, Issue 4 - 8 Heres what I came up with
> but doesn't seem to work.
>
> <IfModule mod_ssl.c>
> <VirtualHost *:443>
> ServerName xxNetdisco2.ad.baker.edu
> ServerAdmin [email protected]
>
> # Possible values include: debug, info, notice, warn, error, crit,
> # alert, emerg.
> LogLevel debug
>
> CustomLog /var/log/apache2/netdisco.access.log combined
> ErrorLog /var/log/apache2/netdisco.error.log
>
> RewriteEngine On
> RewriteCond %{LA-U:REMOTE_USER} (.+)
> RewriteRule . - [E=RU:%1]
> RequestHeader unset X-REMOTE_USER
> RequestHeader add X-REMOTE_USER %{RU}e
> # RequestHeader unset X-REMOTE_USER
> # RequestHeader set X-REMOTE_USER "%{REMOTE_USER}e" env=REMOTE_USER
>
> <Location />
> AuthType Basic
> AuthName "Netdisco"
> AuthBasicProvider ldap
> AuthLDAPBindAuthoritative On
> AuthLDAPURL "ldaps://
> EISADC01.AD.BAKER.EDU:636/DC=AD,DC=BAKER,DC=EDU?sAMAccountName?sub?(objectClass=user)"
> NONE
> AuthLDAPBindDN "CN=SVCAccount,OU=Service,OU=Users,OU=Enterprise
> Support,DC=AD,DC=BAKER,DC=EDU"
> AuthLDAPBindPassword "ourpassword"
> require ldap-group
> CN=technology,OU=Organizational,OU=Security,OU=Groups,OU=Enterprise
> Support,DC=AD,DC=BAKER,DC=EDU
>
>
> </Location>
>
> SSLEngine on
>
> SSLCertificateFile /etc/apache2/ssl/apache.crt
> SSLCertificateKeyFile /etc/apache2/ssl/apache.key
>
>
> # ProxyRequests Off
> ProxyPreserveHost On
> <Proxy *>
> Order deny,allow
> Allow from all
> </Proxy>
>
> ProxyPass / http://localhost:5000/ retry=0 timeout=60
> ProxyPassReverse / http://localhost:50000/
>
> </VirtualHost>
> </IfModule>
>
in the error log I see this:
[Fri Mar 06 11:55:46.666906 2015] [authnz_ldap:info] [pid 29222:tid
140523935377152] [client 10.8.17.1:57437] AH01695: auth_ldap authenticate:
user mdano01 authentication failed; URI / [LDAP: ldap_simple_bind()
failed][Can't contact LDAP server
So the ldap client in apache is for whatever reason not reaching the ldap
server.
I would step back a little and get ldaps/ldap+tls working first. The
reverse proxy stuff to netdisco is very simple, so that will just work
later once the ldap client in apache is in place.
In order to use ssl or, better yet, tls to your ldap servers, you need to
get the right certs for the ldap client in apache in place. See
http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#usingtls (I
assume you are using apache 2.2, change the link to the doc version if you
use another). So to be clear, you need to specify the LDAPTrustedClientCert
<http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldaptrustedclientcert>,
LDAPTrustedGlobalCert
<http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldaptrustedglobalcert>
and LDAPTrustedMode
<http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#ldaptrustedmode>
directives in your ldap config
The certs for mod_ssl might be different, because those are the certs the
browser and the webserver are going to be exchanging.
HTH.
Regards,
--
natxo
--- End Message ---
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
