Richard Smits wrote: > > Douglas E. Engert wrote: >> >> Richard Smits wrote: >>> Hello, >>> >>> We have a problem where we keep getting stuck when we try to find the >>> answer. I hope someone on this list can give us tips or hints in the >>> right direction. >>> >>> I will explain it below : >>> >>> We use Linux/Fedora clients with a nfs4/krb5 mount to a NetApp nashead. >>> Our KDC is our Windows 2003/2008 AD. >>> >>> The problem i was first facing was to establish root access to this >>> nashead. I found out that we had to create a root keytab. >>> >>> No problem there, but we installed a "management station" for creating >>> users an other maintenance work. Then you are going to face the >>> "expired ticket" problem. >>> >>> I solved it this way. >>> >>> In the crontab, every hour : >>> /usr/kerberos/bin/kinit -l 300d -k root/[email protected] >>> >>> 300 days does not work, but one week seems to work. >>> >>> klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: root/[email protected] >>> >>> Valid starting Expires Service principal >>> 05/11/10 08:15:01 05/11/10 18:15:02 krbtgt/[email protected] >>> renew until 05/18/10 08:15:01 >>> 05/11/10 08:20:01 05/11/10 18:15:02 [email protected] >>> renew until 05/18/10 08:15:01 >>> >>> But now I will explain our problem. >>> >>> Every week (on the second) the computer object in the AD is reset. >>> Why, we don't know. See logfile below : >>> >>> -------------------------------------------- >>> 27-4-2010 12:49:56 Security Success Audit Account >>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005 >>> "Computer Account Changed: >>> - >>> Target Account Name: nasmgt$ >>> Target Domain: DASTUD >>> Target Account ID: DOMAIN\nasmgt$ >>> Caller User Name: SRV005$ >>> Caller Domain: DASTUD >>> Caller Logon ID: (0x0,0x3E7) >>> Privileges: - >>> Changed Attributes: >>> Sam Account Name: - >>> Display Name: - >>> User Principal Name: - >>> Home Directory: - >>> Home Drive: - >>> Script Path: - >>> Profile Path: - >>> User Workstations: - >>> Password Last Set: 4/27/2010 12:49:56 PM >>> Account Expires: - >>> Primary Group ID: - >>> AllowedToDelegateTo: - >>> Old UAC Value: - >>> New UAC Value: - >>> User Account Control: - >>> User Parameters: - >>> Sid History: - >>> Logon Hours: - >>> DNS Host Name: - >>> Service Principal Names: - >>> " >>> 27-4-2010 12:49:56 Security Success Audit Account >>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005 >>> "Computer Account Changed: >>> - >>> Target Account Name: nasmgt$ >>> Target Domain: DASTUD >>> Target Account ID: DOMAIN\nasmgt$ >>> Caller User Name: SRV005$ >>> Caller Domain: DASTUD >>> Caller Logon ID: (0x0,0x3E7) >>> Privileges: - >>> Changed Attributes: >>> Sam Account Name: - >>> Display Name: - >>> User Principal Name: - >>> Home Directory: - >>> Home Drive: - >>> Script Path: - >>> Profile Path: - >>> User Workstations: - >>> Password Last Set: 4/27/2010 12:49:56 PM >>> Account Expires: - >>> Primary Group ID: - >>> AllowedToDelegateTo: - >>> Old UAC Value: - >>> New UAC Value: - >>> User Account Control: - >>> User Parameters: - >>> Sid History: - >>> Logon Hours: - >>> DNS Host Name: - >>> Service Principal Names: - >>> >>> >>> >>> Event Type: Success Audit >>> Event Source: Security >>> Event Category: Account Management >>> Event ID: 646 >>> Date: 4-5-2010 >>> Time: 12:49:56 >>> User: NT AUTHORITY\ANONYMOUS LOGON >>> Computer: SRV005 >>> Description: >>> Computer Account Changed: >>> - >>> Target Account Name: nasmgt$ >>> Target Domain: DASTUD >>> Target Account ID: DOMAIN\nasmgt$ >>> Caller User Name: SRV005$ >>> Caller Domain: DASTUD >>> Caller Logon ID: (0x0,0x3E7) >>> Privileges: - >>> Changed Attributes: >>> Sam Account Name: - >>> Display Name: - >>> User Principal Name: - >>> Home Directory: - >>> Home Drive: - >>> Script Path: - >>> Profile Path: - >>> User Workstations: - >>> Password Last Set: 5/4/2010 12:49:56 PM >>> Account Expires: - >>> Primary Group ID: - >>> AllowedToDelegateTo: - >>> Old UAC Value: - >>> New UAC Value: - >>> User Account Control: - >>> User Parameters: - >>> Sid History: - >>> Logon Hours: - >>> DNS Host Name: - >>> Service Principal Names: - >>> >>> >>> For more information, see Help and Support Center at >>> http://go.microsoft.com/fwlink/events.asp. >>> >>> -------------------- >>> >>> Event Type: Success Audit >>> Event Source: Security >>> Event Category: Account Management >>> Event ID: 646 >>> Date: 4-5-2010 >>> Time: 12:49:56 >>> User: NT AUTHORITY\ANONYMOUS LOGON >>> Computer: SRV005 >>> Description: >>> Computer Account Changed: >>> - >>> Target Account Name: nasmgt$ >>> Target Domain: DASTUD >>> Target Account ID: DOMAIN\nasmgt$ >>> Caller User Name: SRV005$ >>> Caller Domain: DASTUD >>> Caller Logon ID: (0x0,0x3E7) >>> Privileges: - >>> Changed Attributes: >>> Sam Account Name: - >>> Display Name: - >>> User Principal Name: - >>> Home Directory: - >>> Home Drive: - >>> Script Path: - >>> Profile Path: - >>> User Workstations: - >>> Password Last Set: 5/4/2010 12:49:56 PM >>> Account Expires: - >>> Primary Group ID: - >>> AllowedToDelegateTo: - >>> Old UAC Value: - >>> New UAC Value: - >>> User Account Control: - >>> User Parameters: - >>> Sid History: - >>> Logon Hours: - >>> DNS Host Name: - >>> Service Principal Names: - >>> =================================== >>> >>> As a result the KVNO (Key Version Number) AD attribute : >>> msDS-KeyVersionNumber keeps changing and is getting higher and higher. >>> We were at version 2. I rejoined the domain a few times and i am at >>> version 6 now. >>> See below. >>> >>> The problem is that I have to recreate a new keytab file because our >>> clients are also using a nfs4/krb5 mount on another server. >>> >>> When the version is higher than local in the keytab, the krb5 security >>> will not work anymore. >>> >>> I have talked to the Windows sysadmins and the say that the password for >>> a computer object is changed every 30 days, but my experience is that >>> the key is increased every seven days. >> Looks like the srv...@dastdu is changing the password. >> >> Are you using a single AD account for the machine and the root/host? >> >> What is SRV005$ is this the samAccountName of the machine's account? >> >> Is there a cron job or some NAS daemon that is changing it, and expecting >> to change the host/f...@realm keys in the keytab at the same time? >> >> Did you do a setspn command to add root/[email protected] >> (What UPN and SPNs are on the account?) >> >> You may have been bit by AD using a single password per account which is >> used to derive the keys on the fly for the UPN and all SPNs associated with >> the account. >> >> Normally the /etc/krb5.keytab has host/f...@realm principals,and not a >> root/f...@realm principals. Did you clobber the previous /etc/krb5.keytab >> which may have had a host/f...@realm principal? >> >> You could consider separating using two the computer account one for root >> and one for the machine. You may not need a root/f...@realm principal at >> all. Look at ~.k5login and use kinit -k host/f...@realm >> >>> ----- >>> klist -k -e >>> Keytab name: FILE:/etc/krb5.keytab >>> KVNO Principal >>> ---- >>> -------------------------------------------------------------------------- >>> >>> 6 root/[email protected] (DES cbc mode with CRC-32) >>> 6 root/[email protected] (DES cbc mode with RSA-MD5) >>> 6 root/[email protected] (ArcFour with HMAC/md5) >>> 6 root/[email protected] (DES cbc mode with CRC-32) >>> 6 root/[email protected] (DES cbc mode with RSA-MD5) >>> 6 root/[email protected] (ArcFour with HMAC/md5) >>> >>> ---------------- >>> klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: root/[email protected] >>> >>> Valid starting Expires Service principal >>> 04/21/10 12:15:01 04/21/10 22:15:01 krbtgt/[email protected] >>> renew until 04/28/10 12:15:01 >>> 04/21/10 12:25:01 04/21/10 22:15:01 [email protected] >>> renew until 04/28/10 12:15:01 >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt0 >>> klist: You have no tickets cached >>> ---------------------------- >>> >>> Reminder : >>> >>> Because this is our maintenance / root station for our nashead, I am >>> renewing our ticket every hour with a cronjob. So the lifetime of the >>> ticket is extended every hour. Could this be one of the actions that >>> causes this ? >>> >>> Greetings ... Richard Smits >>> > Hello, > > > Looks like the srv...@dastdu is changing the password. > Well srv005 is the Windows Domain Controller, and DASTUD the windows domain. > > I use a single workstation account for my server. Why would someone need > more ? > > There is no cronjob on the client or server side what could be causing > this in my knowledge. > > > Did you do a setspn command to add root/[email protected] > > (What UPN and SPNs are on the account?) > > Ok, here are my UPS's and SPN's of the computer object : > > (servicePrincipalName) > HOST/NASMGT > HOST/nasmgt.tudelft.net > ROOT/nasmgt > ROOT/nasmgt.tudelft.net > > (userPrincipalName) > root/[email protected] > > But in my keytab file the HOST entry's are not there.... could this be a > problem. I am relatively a newby for krb5, and never understood where > the HOST entry's were for. > > Your story about not needing a root entry in the keytab is interesting. > I will look in to this. > > Greetings .. Richard > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos
Well, I just want to say that this problem has been solved. It took a long time, but this is the solution : The new samba versions has a different syntax in the smb.conf file. In the old versions of samba, there was a line that said : use kerberos keytab = yes But in the newer versions, they changed the syntax of this line to : kerberos method = secrets and keytab This line says that the AD communication will use the keytab file, AND the sessions.tdb file. If you do not have this line, it only uses the session.tdb, and your keytab will be out of sync in a couple of days. Greetings .. Richard ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
