########################
JHU Upstream Information
########################

Miscellaneous information that's relevant for hanging around in JHU's computing
environment.

Networking
----------

This is big enough that it needs its own document; see
:doc:`../core/networks/external`.

NTP
---

JHU runs NTP servers at ``ntp1.jhu.edu`` and ``ntp2.jhu.edu``, accessible
only within the campus firewall.

.. _jhu-upstreams_dns:


DNS
---

JHU DNS, including glue records for ``acm.jhu.edu``, is controlled by
``hostmaster@jhmi``.

We use JHU CS (``128.220.13.50`` and ``blaze.cs.jhu.edu``) and JHU IT
(``10.200.2.2`` and ``10.200.1.1``, which have a slew of names but are
``ns2.johnshopkins.edu.`` and ``ns1.johnshopkins.edu.`` respectively) as our
upstream DNS resolvers.

Note that because various DNS software (notably dnsmasq) attempt to protect
against so-called "rebinding attacks", and JHU uses RFC1918 addresses
internally, we find it necessary to OK certain JHU domains::

  rebind-domain-ok=/ad.jhu.edu/
  rebind-domain-ok=/ntp1.jhu.edu/
  rebind-domain-ok=/ntp2.jhu.edu/
  rebind-domain-ok=/johnshopkins.edu/

While here, we should also mention that *we* serve RFC1918 addresses out of
``acm.jhu.edu`` on occasion, and that we use DNSRBLs, so add to the above::

  rebind-domain-ok=/acm.jhu.edu/
  rebind-domain-ok=/zen.spamhaus.org/

Kerberos
--------

As is typical of Kerberos cross-realming, a shared secret exists for
``krbtgt/ACM.JHU.EDU@WIN.AD.JHU.EDU`` in both the JHU AD and our KDCs.  They do
not trust us to make names for them, so there is no
``krbtgt/WIN.AD.JHU.EDU@ACM.JHU.EDU`` shared secret; don't be surprised.

On their side, they ran ``ktpass -ptype KRB5_NT_PRINCIPAL -princ
krbtgt/ACM.JHU.EDU@WIN.AD.JHU.EDU -crypto AES256-SHA1 -mapuser
acmrealm@WIN.AD.JHU.EDU -pass XXXX -out acm.keytab`` to make our keytab for us.
As such, changing our cross-realm password is done by ``kpasswd
acmrealm@WIN.AD.JHU.EDU`` from the command line and ``cpw
krbtgt/ACM.JHU.EDU@WIN.AD.JHU.EDU`` in kadmin.

See :ref:`readme-user_jhed` for instructions to grab kerberos tickets from the
JHU AD.

.. _jhu-upstreams_ldap:

LDAP
----

First, you'll need to URL escape the LDAP DN for DNS SRV record discovery.
Ignore that; run this::

  LDAPURI=ldap:///$(perl -MURI::Escape -e 'print uri_escape("dc=win,dc=ad,dc=jhu,dc=edu");')

(full credit to
http://stackoverflow.com/questions/296536/urlencode-from-a-bash-script for
that).  Then, assuming you have JHU kerberos tickets as per
:ref:`readme-user_jhed` or are logged in to :doc:`../services/egg` using your
JHED ID, run to your heart's content searches like.::

  ldapsearch -Y GSSAPI -H ${LDAPURI} -b dc=win,dc=ad,dc=jhu,dc=edu cn=${JHEDID}
  ldapsearch -Y GSSAPI -H ${LDAPURI} -b dc=win,dc=ad,dc=jhu,dc=edu mailequivalentaddress=${EMAIL}

Note that the JHU directory uses ``cn=`` rather than, as we do, ``uid=`` for
the object's DN.  Some other useful fields of their database include:

+------------------------------+--------------------------------------------------------------------+
| ``johnshopkinseduhopkinsid`` | The "Hopkins ID" (that funky five character thing that ISIS shows) |
+------------------------------+--------------------------------------------------------------------+
|  ``jhejcardbarcode``         | J-card barcode number                                              |
+------------------------------+--------------------------------------------------------------------+
|  ``jheOLaccttype``           | Whether the person is a student or alumnus (or something else?)    |
+------------------------------+--------------------------------------------------------------------+
| ``johnshopkinseduhmwbadge``  | The other, non-barcode number on J-cards                           |
+------------------------------+--------------------------------------------------------------------+
| ``mailequivalentaddress``    | Email addresses and aliases associated with the account            |
|                              | See also ``proxyAddresses``.                                       |
+------------------------------+--------------------------------------------------------------------+
| ``manager``                  | Person's manager's DN                                              |
+------------------------------+--------------------------------------------------------------------+


.. note:: Failure to set the correct search base will result not in failure but
   in confusing LDAP referals.

.. note:: You will need the correct SASL GSSAPI KRB5 implementation around on
   your machine.  On a Debian machine, that probably means you should ensure
   that you have ``libsasl2-modules-gssapi-mit`` installed.

JHU AD Principles Assigned for ACM Use
``````````````````````````````````````

+-----------+------------------------------------------------------------------------+------------------------+
| Principal | DN                                                                     | See                    |
+-----------+------------------------------------------------------------------------+------------------------+
| acmjanus  | CN=acmjanus,OU=ACM,OU=AuthN,DC=win,DC=ad,DC=jhu,DC=edu                 | :ref:`janus_jhed`      |
+-----------+------------------------------------------------------------------------+------------------------+
| egg       | CN=EGG,OU=SERVERS,OU=CS,OU=Computers,OU=WSE,DC=win,DC=ad,DC=jhu,DC=edu | :doc:`../services/egg` |
+-----------+------------------------------------------------------------------------+------------------------+

.. _jhu-upstreams_ssl:

SSL
---

To get an SSL cert signed by JHU's business relationship with an existing
SSL CA, you'll be interacting with
http://www.it.johnshopkins.edu/services/directoryservices/SSLCertificates/index.html
.

* Generate a .key and .csr; see ``please-do-not.../certs/build.sh``.  For
  example, run ``./build.sh foobar`` to get a files named
  ``foobar-YYYYMM.{key,csr}`` .

* Hand the CSR to JHU.  We usually select ``Apache/mod_ssl`` as the server
  type (this list makes no sense what so ever), and set the number of
  servers to 1.  Set the contact name to ``admins@acm...``.

* When you get mail, place the resulting .crt file in
  ``/afs/acm.jhu.edu/group/admins.pub/certs/`` and release.

* Use the key and crt files as appropriate to your service.

The file
``/afs/acm.jhu.edu/readonly/group/admins.pub/certs/jhu-cert-chain.pem``
contains all intermediate certificates necessary for improved client
verification (notably, our nagios scripts need it, but so do some browsers and
so on).  If ever JHU changes from whom they are issuing certs, probably create
a new file beside that one and roll over to it, or however is necessary.  (As
usual, see :doc:`../core/afsdoc/admins-pub` for information about this path.)

.. note:: Be sure to have Nagios watch over the validity of your SSL
   certificate when it gets deployed.  This will give present and future
   admins a heads up when things are about to expire!