Authentication: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
==Introduction== | ==Introduction== | ||
The lab services and utilities used by mu2e require gaining and using several kinds of authentication. | The lab services and utilities used by mu2e require gaining and using several kinds of authentication. You will have one username for all computing purposes lab. | ||
You login to the virtual machines with '''kerberos''' authentication. You will need a permanent ID called a kerberos "principal" which is looks like "xyz@FNAL.GOV", where xyz is your username. | You login to the virtual machines with '''kerberos''' authentication. You will need a permanent ID called a kerberos "principal" which is looks like "xyz@FNAL.GOV", where xyz is your username. You will have a password associated with your principal. You will use this principal and password to log into the various personal linux desktops located at Fermilab or to ssh into the collaboration interactive machines from your home institution. | ||
The second identity you will need is the '''services''' principal, which looks like xyz@services.fnal.gov, or often just xyz, and also has a password (different from your kerberos password). You will need this identity to log into Fermilab email, the servicedesk web site and some other services based at the lab. You would typically only use this authentication at the point you log into the service. | |||
The third identity you will need is a '''CILogin certificate'''. This "cert" is the basis of authentication to the mu2e documents database, the computing farms, and a few other services. You will use this cert in two ways. The first way is to load it into your browser, which then gives you access to web pages and web services. The second is by using your kerberos authentication to access a copy of your certificate maintained in a remote database. You get this certificate once and then renew it only once a year. | |||
hypernews is an archived blog and email list - for access here, you will need a hypernews password and your services password! | |||
Finally, the mu2e internal web pages require a collaboration username and password, please ask your mu2e mentor. | |||
If you need to do any computing in mu2e, please go ahead and start the procedure on the [[ComputingAccounts]] to create your accounts and authentication. | |||
==Kerberos== | |||
You login to the virtual machines with '''kerberos''' authentication. You will need a permanent ID called a kerberos "principal" which is looks like "xyz@FNAL.GOV", where xyz is your username. You will have a password associated with your principal. You will use this principal and password to log into the various personal linux desktops located at Fermilab or to ssh into the collaboration interactive machines from your home institution. | |||
Your kerberos authentication is stored in a file | |||
/tmp/krb5cc_`id -u`_* | |||
where "*" will be a random string. Each time you ssh into a machine, it will produce a new file in /tmp for that process. The environmental <code>KRB5CCNAME</code> will point to the ticket file. | |||
The ticket may be viewed with | |||
klist | |||
If you log into a lab desktop, you would typically user you username (just "xyz" without the "@FNAL.GOV") a new ticket is created. | |||
You can renew the ticket, or create it if you logged on my some other means, using | |||
kinit | |||
kinit takes an argument which is the user name (or full principle) and asked for you password. Tickets are "forwardable" by default. This means if you are logged into machine A with a ticket, and ssh to machine B, the ticket will also be moved to machine B, so you can ssh (or scp, etc) once you are on B. | |||
Tickets are only valid for 26h and you typically refresh your kerberos authentication every day. This would normally happen as you log in to a desktop. If you have an ssh session from machine A to machine B, and leave the session up, you may renew the ticket on A, but the ticket on B will not automatically be updated. in this case, you can use | |||
k5push | |||
to push your fresh ticket out though all ssh sessions and update their tickets. | |||
There are two utilities in kerberos which we will only note here. One is <code>kcon</code> and <code>kcroninit</code>. This allows you to gain a kerberos ticket in a cron job. The other variant is the <code>keytab</code> file. This file can hold a ticket that is good for a year and can be accessed by anyone with access to the keytab file. This feature is not as secure, so it is usually only used when needed, for example, in a group account. | |||
Read more at the FNAL [https://fermi.service-now.com/nav_to.do?uri=%2Fkb_view_customer.do%3Fsysparm_article%3DKB0011308 kerberos link]. | |||
Reset password [https://fermi.service-now.com/nav_to.do?uri=%2Fkb_view_customer.do%3Fsysparm_article%3DKB0010628 |here]. | |||
==Services== | ==Services== | ||
Revision as of 21:31, 10 May 2017
This page is a draft, please help complete it!
Introduction
The lab services and utilities used by mu2e require gaining and using several kinds of authentication. You will have one username for all computing purposes lab.
You login to the virtual machines with kerberos authentication. You will need a permanent ID called a kerberos "principal" which is looks like "xyz@FNAL.GOV", where xyz is your username. You will have a password associated with your principal. You will use this principal and password to log into the various personal linux desktops located at Fermilab or to ssh into the collaboration interactive machines from your home institution.
The second identity you will need is the services principal, which looks like xyz@services.fnal.gov, or often just xyz, and also has a password (different from your kerberos password). You will need this identity to log into Fermilab email, the servicedesk web site and some other services based at the lab. You would typically only use this authentication at the point you log into the service.
The third identity you will need is a CILogin certificate. This "cert" is the basis of authentication to the mu2e documents database, the computing farms, and a few other services. You will use this cert in two ways. The first way is to load it into your browser, which then gives you access to web pages and web services. The second is by using your kerberos authentication to access a copy of your certificate maintained in a remote database. You get this certificate once and then renew it only once a year.
hypernews is an archived blog and email list - for access here, you will need a hypernews password and your services password!
Finally, the mu2e internal web pages require a collaboration username and password, please ask your mu2e mentor.
If you need to do any computing in mu2e, please go ahead and start the procedure on the ComputingAccounts to create your accounts and authentication.
Kerberos
You login to the virtual machines with kerberos authentication. You will need a permanent ID called a kerberos "principal" which is looks like "xyz@FNAL.GOV", where xyz is your username. You will have a password associated with your principal. You will use this principal and password to log into the various personal linux desktops located at Fermilab or to ssh into the collaboration interactive machines from your home institution.
Your kerberos authentication is stored in a file
/tmp/krb5cc_`id -u`_*
where "*" will be a random string. Each time you ssh into a machine, it will produce a new file in /tmp for that process. The environmental KRB5CCNAME will point to the ticket file.
The ticket may be viewed with
klist
If you log into a lab desktop, you would typically user you username (just "xyz" without the "@FNAL.GOV") a new ticket is created. You can renew the ticket, or create it if you logged on my some other means, using
kinit
kinit takes an argument which is the user name (or full principle) and asked for you password. Tickets are "forwardable" by default. This means if you are logged into machine A with a ticket, and ssh to machine B, the ticket will also be moved to machine B, so you can ssh (or scp, etc) once you are on B.
Tickets are only valid for 26h and you typically refresh your kerberos authentication every day. This would normally happen as you log in to a desktop. If you have an ssh session from machine A to machine B, and leave the session up, you may renew the ticket on A, but the ticket on B will not automatically be updated. in this case, you can use
k5push
to push your fresh ticket out though all ssh sessions and update their tickets.
There are two utilities in kerberos which we will only note here. One is kcon and kcroninit. This allows you to gain a kerberos ticket in a cron job. The other variant is the keytab file. This file can hold a ticket that is good for a year and can be accessed by anyone with access to the keytab file. This feature is not as secure, so it is usually only used when needed, for example, in a group account.
Read more at the FNAL kerberos link. Reset password |here.
Services
Certificate
For interactive use on linux, for example, to upload files or write to the SAM database with samweb, you will need a valid certificate. (While job submission and ifdh can convert a kerberos ticket into a certificate, samweb cannot.) The easiest method is to create a valid kerberos ticket, then convert that to a cert.
kinit kx509
Certificate Error
If you believe you have a valid certificate and you still see errors, for example,
Error creating dataset definition for ... 500 SSL negotiation failed: .
Then try removing the cert and recreating it.
kinit rm /tmp/x509up_u`id -u` kx509
Certificate print
voms-proxy-info -all
Under construction
When you connect to a secure web site that expects a certificate from you, that site will also present your browser with a certificate of its own. Your browser will then attempt to authenticate the certificate. If it cannot, it will open a dialog box telling you that it does not recognize the site's certificate and asking you if you would like to "add an exception". If you add the exception, then your browser will accept this site even though the browser cannot itself authenticate the certificate.
The way that your browser authenticates a certificate is that it contacts a recognized, trusted, Certificate Authority (CA). It then forwards the certificate in question to the CA and asks "Can I trust this?". If all is well, the CA replies that you can trust it. If your browser does not know the relevant CA to use, or if it does not trust the CA that the certificate says to use, then your browser will start the "add exception" dialog. Out of the box, your browser usually does not know much about which CAs to trust. In the cases you will encounter here, the relevant CA is the DOE GRID CA. This is true even for KCA certificates. You can tell your browser to accept certificates authenticated by the DOE GRID CA as follows:
- Go to https://pki1.doegrids.org .
- Click on the third tab from the top left (retrieval) and then on "import CA certificate chain".
- That may itself require you to say yes to an exception, if so, do it.