From root@circe.CS.Berkeley.EDU Tue Mar 11 19:55:50 1997 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id TAA26978 for ; Tue, 11 Mar 1997 19:55:50 -0500 Received: from circe.CS.Berkeley.EDU by MIT.EDU with SMTP id AA07883; Tue, 11 Mar 97 19:55:39 EST Received: (from root@localhost) by circe.CS.Berkeley.EDU (8.7.3/8.7.3) id QAA03182; Tue, 11 Mar 1997 16:55:41 -0800 (PST) Message-Id: <199703120055.QAA03182@circe.CS.Berkeley.EDU> Date: Tue, 11 Mar 1997 16:55:41 -0800 (PST) From: Charlie To: krb5-bugs@MIT.EDU Cc: robm@eecs.Berkeley.EDU, sklower@cs.Berkeley.EDU Subject: document v4kadmind, etc. better >Number: 388 >Category: krb5-doc >Synopsis: document v4kadmind, etc. better >Confidential: no >Severity: serious >Priority: medium >Responsible: krb5-unassigned >State: closed >Class: support >Submitter-Id: unknown >Arrival-Date: Tue Mar 11 19:56:01 EST 1997 >Last-Modified: Wed Jul 08 08:46:27 EDT 1998 >Originator: sklower@CS.Berkeley.EDU >Organization: Computer Science Department, UC Berkeley >Release: 1.0 >Environment: BSD/OS 2.1, Ultrix 4.3 System: BSD/OS circe.CS.Berkeley.EDU 2.1 BSDI BSD/OS 2.1 Kernel #7: Thu Oct 31 16:48:20 PST 1996 hodes@terrorism.cs.berkeley.edu:/disks/barad-dur/roboline/PC/src.2.1/sys/compile/BS_MOBILEIP WILDBOAR APM/PCMCIA Driver (WB960224) i386 >Description: After following the instructions in "Upgrading to Kerberos V5 from Kerberos V4", with all data from our real production kerberos V4 database, and having selected 3 sample machines to participate in a test, (a server, circe@CS.Berkeley.EDU, an ultrix V4 machine oboe.CS..., a BSD/OS 2.1 client yacht@CS) none of the following ways allowed me to change my own kerberos password: a.) The V4 kpasswd command as compiled under ultrix from krb_passwd.c Berkeley version 8.3 b.) The BSD/OS 2.1 passwd command c.) The V4-compatible kpasswd command as supplied in the V5 distribution (compiled under BSD/OS 2.1) d.) The V5 v5passwd program as supplied in the V5 distribution (compiled under BSD/OS 2.1) e.) The kadmin command as supplied in the V5 distribution (as run from the server) with my principal "sklower/@EECS.BERKELEY.EDU" f.) ditto e.) for sklower/admin@EECS.BERKELEY.EDU We cannot proceed with deployment of kerberos V here until normal users are able to change their own passwords, and our dedicated kerberos servers are PC's running BSD/OS. >How-To-Repeat: Unfortunately, I'm not at liberty to include a v4 dump of our actual kerberos4 database. I can, however, provide the contents of various other configuration and log files: /etc/krb5.conf: [libdefaults] default_realm = EECS.BERKELEY.EDU krb4_srvtab = /etc/kerberosIV/srvtab krb4_config = /etc/kerberosIV/krb.config krb4_realms = /etc/kerberosIV/krb.realms [appdefaults] [realms] EECS.BERKELEY.EDU = { kdc = circe.CS.Berkeley.EDU admin_server = circe.CS.Berkeley.EDU default_domain = CS.Berkeley.EDU v4_instance_convert = absolut.EECS.Berkeley.EDU [492 lines of *.EECS.Berkeley.EDU deleted; there are also ~950 host instances *.CS.Berkeley.EDU] v4_instance_convert = zirconium.EECS.Berkeley.EDU } ATHENA.MIT.EDU = { kdc = kerberos.mit.edu kdc = kerberos-1.mit.edu kdc = kerberos-2.mit.edu admin_server = kerberos.mit.edu default_domain = mit.edu } [domain_realm] .CS.Berkeley.EDU = EECS.BERKELEY.EDU .EECS.Berkeley.EDU = EECS.BERKELEY.EDU .mit.edu = ATHENA.MIT.EDU [logging] kdc = FILE:/var/log/kerberos5.log kdc = SYSLOG:INFO:DAEMON admin_server = FILE:/var/log/kadmin5.log admin_server = SYSLOG:INFO:DAEMON default = FILE:/var/log/krb5lib.log [capaths] [kdc] /usr/local/var/krb5kdc/kdc.conf: [kdcdefaults] kdc_ports = 88,750 [realms] EECS.BERKELEY.EDU = { database_name = /usr/local/var/krb5kdc/principal admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab acl_file = /usr/local/var/krb5kdc/kadm5.acl dict_file = /usr/local/var/krb5kdc/kadm5.dict key_stash_file = /usr/local/var/krb5kdc/.k5.EECS.BERKELEY.EDU kadmind_port = 749 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4 } [logging] kdc = FILE:/var/log/kerberos5.log kdc = SYSLOG:INFO:DAEMON admin_server = FILE:/var/log/kadmin5.log admin_server = SYSLOG:INFO:DAEMON default = FILE:/var/log/krb5lib.log /usr/local/var/krb5kdc/kadm5.acl: admin/admin@EECS.BERKELEY.EDU * kpasswd/circe@EECS.BERKLEY.EDU ADmcil /etc/inetd.conf [partial]: # Kerberos authenticated services klogin stream tcp nowait root /usr/libexec/rlogind rlogind -k eklogin stream tcp nowait root /usr/libexec/rlogind rlogind -k -x kshell stream tcp nowait root /usr/libexec/rshd rshd -k ekshell stream tcp nowait root /usr/libexec/rshd rshd -k -x rkinit stream tcp nowait root /usr/libexec/rkinitd rkinitd # Services run ONLY on the Kerberos server #krbupdate stream tcp nowait root /usr/libexec/registerd registerd kpasswd stream tcp nowait root /usr/local/sbin/v5passwdd v5passwdd /etc/services [partial]: # # Kerberos (Project Athena/MIT) version 5 services # kerberos-sec 88/udp # Kerberos authentication udp kerberos-sec 88/tcp # Kerberos authentication tcp krb5_prop 753/tcp # Kerberos slave propagation kerberos-adm 749/tcp # Kerberos 5 admin/changepw (tcp) kerberos-adm 749/udp # Kerberos 5 admin/changepw (udp) krb524 4444/udp # Kerberos 5 to 4 ticket translator # # Kerberos (Project Athena/MIT) services # kerberos 750/udp kdc # Kerberos (server) udp kerberos 750/tcp kdc # Kerberos (server) tcp krbupdate 760/tcp kreg # Kerberos registration kpasswd 761/tcp kpwd # Kerberos "passwd" krb_prop 754/tcp # Kerberos slave propagation klogin 543/tcp # Kerberos rlogin eklogin 2105/tcp # Kerberos encrypted rlogin kshell 544/tcp krcmd # Kerberos remote shell ekshell 2106/tcp # Kerberos encrypted shell rkinit 2108/tcp # Kerberos remote initialization Here are the diagnostic messages received under case a.) (kinit; kpasswd from ultrix 4.4): Mar 11 16:26:20 circe.CS.Berkeley.EDU krb5kdc[2722](info): PROCESS_V4:Initial ticket request Host: 128.32.34.61 User: "sklower" "" Mar 11 16:26:26 circe v5passwdd[3117]: v5passwdd: Address already in use while initializing network Mar 11 16:26:26 circe v5passwdd[3117]: v5passwdd: Address already in use while initializing network Mar 11 16:26:26 circe.CS.Berkeley.EDU krb5kdc[2722](info): PROCESS_V4:APPL Request sklower.@EECS.BERKELEY.EDU on 128.32.34.61 for kpasswd.circe Mar 11 16:26:26 circe.CS.Berkeley.EDU v5passwdd[3117](info): starting Mar 11 16:26:26 circe.CS.Berkeley.EDU v5passwdd[3117](Error): v5passwdd: Address already in use while initializing network and the client program reports: % kpasswd WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Changing Kerberos password for sklower.@EECS.BERKELEY.EDU. Old Kerberos password: couldn't read verification string (aborted) % uname -a ULTRIX oboe.CS.Berkeley.EDU 4.4 0 RISC Here are the diagnostic message from case b.) - the BSD/OS passwd command Mar 11 16:32:03 circe.CS.Berkeley.EDU krb5kdc[2722](info): PROCESS_V4:Initial ticket request Host: 208.1.88.41 User: "sklower" "" Mar 11 16:32:09 circe v5passwdd[3122]: v5passwdd: Address already in use while initializing network Mar 11 16:32:09 circe v5passwdd[3122]: v5passwdd: Address already in use while initializing network Mar 11 16:32:09 circe.CS.Berkeley.EDU krb5kdc[2722](info): PROCESS_V4:APPL Request sklower.@EECS.BERKELEY.EDU on 208.1.88.41 for kpasswd.circe Mar 11 16:32:09 circe.CS.Berkeley.EDU v5passwdd[3122](info): starting Mar 11 16:32:09 circe.CS.Berkeley.EDU v5passwdd[3122](Error): v5passwdd: Address already in use while initializing network as resulting from the following sequence: Kerberos Initialization Kerberos name: sklower Kerberos instance: Kerberos Password: yacht# passwd Changing Kerberos password for sklower.@EECS.BERKELEY.EDU. Old Kerberos password: passwd: couldn't read verification string (aborted) yacht# uname -a BSD/OS yacht.CS.Berkeley.EDU 2.1 BSDI BSD/OS 2.1 Kernel #155: Sun Mar 9 20:03:37 PST 1997 stemm@saber.CS.Berkeley.EDU:/disks/barad-dur/roboline/PC/src.2.1/sys/compile/BS WILDBOAR APM/PCMCIA Driver (WB960224) i386 Here are the diagnostic messages from case c.) - The V4-compatible kpasswd command as supplied in the V5 distribution (compiled under BSD/OS 2.1), and run from the server itself: Mar 11 16:36:48 circe.CS.Berkeley.EDU krb5kdc[2722](info): AS_REQ 128.32.33.88(750): ISSUE: authtime 858127008, sklower@EECS.BERKELEY.EDU for krbtgt/EECS.BERKELEY.EDU@EECS.BERKELEY.EDU Mar 11 16:37:03 circe v5passwdd[3129]: Cannot allocate memory - 3129: error reading AP_REQ message Mar 11 16:37:03 circe v5passwdd[3129]: Cannot allocate memory - 3129: error reading AP_REQ message Mar 11 16:37:03 circe.CS.Berkeley.EDU krb5kdc[2722](info): AS_REQ 128.32.33.88(750): ISSUE: authtime 858127023, sklower@EECS.BERKELEY.EDU for kadmin/changepw@EECS.BERKELEY.EDU v5passwdd: Cannot allocate memory - 3129: error reading AP_REQ message result from the following user interaction: % /usr/local/bin/kinit sklower@EECS.BERKELEY.EDU Password for sklower@EECS.BERKELEY.EDU: % /usr/local/bin/kpasswd kpasswd: Changing password for sklower@EECS.BERKELEY.EDU. Old password: kpasswd: Cannot establish a session with the Kerberos administrative server for realm EECS.BERKELEY.EDU. GSS-API (or Kerberos) error. 1.2u 0.0s 0:05.43 23.3% 0+0k 0+11io 0pf+0w % uname -a BSD/OS circe.CS.Berkeley.EDU 2.1 BSDI BSD/OS 2.1 Kernel #7: Thu Oct 31 16:48:20 PST 1996 hodes@terrorism.cs.berkeley.edu:/disks/barad-dur/roboline/PC/src.2.1/sys/compile/BS_MOBILEIP WILDBOAR APM/PCMCIA Driver (WB960224) i386 % There were no diagnostic messages in the server logs resulting from case d.) - the v5passwd program: However, it didn't work, and as I wasn't able to figure out where it was attempting to locate the server from . . . % /usr/local/bin/v5passwd /usr/local/bin/v5passwd: cannot contact server (No such file or directory). In case e.) - kadmin run from my user account: Mar 11 16:47:28 circe.CS.Berkeley.EDU krb5kdc[2722](info): AS_REQ 128.32.33.88(750): ISSUE: authtime 858127648, sklower@EECS.BERKELEY.EDU for kadmin/admin@EECS.BERKELEY.EDU Mar 11 16:47:36 circe v5passwdd[3151]: Cannot allocate memory - 3151: error reading AP_REQ message v5passwdd: Cannot allocate memory - 3151: error reading AP_REQ message Mar 11 16:47:36 circe v5passwdd[3151]: Cannot allocate memory - 3151: error reading AP_REQ message which resulted from the invocation: % /usr/local/sbin/kadmin -p sklower@EECS.BERKELEY.EDU Enter password: kadmin: GSS-API (or Kerberos) error while initializing kadmin interface >Fix: If I knew how to fix this problem I wouldn't be begging for help! >Audit-Trail: From: "Theodore Y. Ts'o" To: krb5-bugs@MIT.EDU, Charlie Cc: bjaspan@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU Subject: Re: krb5-admin/388: request for support in upgrading v4 to v5 Date: Wed, 12 Mar 1997 00:47:36 -0500 Date: Tue, 11 Mar 1997 16:55:41 -0800 (PST) From: Charlie After following the instructions in "Upgrading to Kerberos V5 from Kerberos V4", with all data from our real production kerberos V4 database, and having selected 3 sample machines to participate in a test, (a server, circe@CS.Berkeley.EDU, an ultrix V4 machine oboe.CS..., a BSD/OS 2.1 client yacht@CS) none of the following ways allowed me to change my own kerberos password: a.) The V4 kpasswd command as compiled under ultrix from krb_passwd.c Berkeley version 8.3 b.) The BSD/OS 2.1 passwd command If you want to use the V4 kpasswd clients, you need to run a V4-compatibility kadmin server, to support the V4 kadmin protocol which is used by the V4 kpasswd clients. This can be found in the kadmin/v4server directory. In general, your error messages show v5passwdd firing up in a number of cases. Note that the v5passwdd server is not needed in most cases, unless you need compatibility with the V5 kpasswd that had been released in previous beta releases. v5passwdd also *shouldn't* be running on out of inetd, since v5 passwd does its own waiting. Try removing v5passwdd, since I suspect it was getting in your way, and hurting far more than it was helping. > Not sure what did it; > In any case the sequence > kadmin -p sklower@EECS.BERKELEY.EDU > kadmin: cpw sklower@EECS.BERKELEY.EDU > appears to work now, although it does require that > the v5 kadmin program be made available on all v4 > platforms, as well as an /etc/krb5.conf file. > This is annoying, etc. > If kadmin works, the kpasswd program (found in src/kadmin/kpasswd), should work as well (it contacts the same server). Good luck!! - Ted From: "Barry Jaspan" To: krb5-bugs@MIT.EDU, root@circe.CS.Berkeley.EDU Cc: Subject: Re: krb5-admin/388: request for support in upgrading v4 to v5 Date: Wed, 12 Mar 1997 12:25:00 -0500 none of the following ways allowed me to change my own kerberos password: a.) The V4 kpasswd command as compiled under ultrix from krb_passwd.c Berkeley version 8.3 b.) The BSD/OS 2.1 passwd command c.) The V4-compatible kpasswd command as supplied in the V5 distribution (compiled under BSD/OS 2.1) d.) The V5 v5passwd program as supplied in the V5 distribution (compiled under BSD/OS 2.1) e.) The kadmin command as supplied in the V5 distribution (as run from the server) with my principal "sklower/@EECS.BERKELEY.EDU" f.) ditto e.) for sklower/admin@EECS.BERKELEY.EDU I assume you are running kadmin/server/kadmind on your KDC, and that it started correctly. In that case, Congratulations!, you have discovered six incorrect ways to try to change your password! Quite an accomplishment. :-) The correct program to use with kadmin/server/kadmind is kadmin/passwd/kpasswd. If kadmin/cli/kadmin works, then the kpasswd program will, too. As Ted has explained, the "V5 kpasswd" is not really part of the new kadmin system. "V5 kpasswd" and "V5 kpasswdd" are a separate system that only work with themselves. Confusing, yes. If you want compatibility with V4 kpasswd programs, run kadmin/v4server/v4kadmind (or whatever the program in that directory is called). It works with kadmin/server/kadmind. Barry Responsible-Changed-From-To: bjaspan->krb5-unassigned Responsible-Changed-By: tlyu Responsible-Changed-When: Sun Mar 16 02:24:18 1997 Responsible-Changed-Why: Refiled; this really should be a doc bug now. State-Changed-From-To: open-analyzed State-Changed-By: tlyu State-Changed-When: Sun Mar 16 02:25:12 1997 State-Changed-Why: State-Changed-From-To: analyzed-closed State-Changed-By: mdh State-Changed-When: Wed Jul 8 08:45:39 1998 State-Changed-Why: All that remains here is the doc bug, which is essentially duplicated by PR 392. >Unformatted: To: krb5-bugs@mit.edu Subject: From: sklower@CS.Berkeley.EDU Reply-To: sklower@CS.Berkeley.EDU Cc: X-send-pr-version: 3.99