[32324] in Kerberos
Re: Computer Account Reset AD
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Wed May 12 11:35:17 2010
Message-ID: <4BEACAAB.3070609@anl.gov>
Date: Wed, 12 May 2010 10:35:07 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Richard Smits <R.Smits@tudelft.nl>
In-Reply-To: <4BEABD01.5030605@tudelft.nl>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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/hostname.domain.net@DOMAIN.NET
>>>
>>> 300 days does not work, but one week seems to work.
>>>
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/hostname.domain.net@DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 05/11/10 08:15:01 05/11/10 18:15:02 krbtgt/DOMAIN.NET@DOMAIN.NET
>>> renew until 05/18/10 08:15:01
>>> 05/11/10 08:20:01 05/11/10 18:15:02 srv005$@DOMAIN.NET
>>> 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 SRV005@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/fqdn@realm keys in the keytab at the same time?
>>
>> Did you do a setspn command to add root/hostname.domain.net@DOMAIN.NET
>> (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/fqdn@realm principals,and not a
>> root/fqdn@realm principals. Did you clobber the previous /etc/krb5.keytab
>> which may have had a host/fqdn@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/fqdn@realm principal at
>> all. Look at ~.k5login and use kinit -k host/fqdn@realm
>>
>>> -----
>>> klist -k -e
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ----
>>> --------------------------------------------------------------------------
>>>
>>> 6 root/nasmgt.domain.net@DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt.domain.net@DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt.domain.net@DOMAIN.NET (ArcFour with HMAC/md5)
>>> 6 root/nasmgt@DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt@DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt@DOMAIN.NET (ArcFour with HMAC/md5)
>>>
>>> ----------------
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/nasmgt.domain.net@DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 04/21/10 12:15:01 04/21/10 22:15:01 krbtgt/DOMAIN.NET@DOMAIN.NET
>>> renew until 04/28/10 12:15:01
>>> 04/21/10 12:25:01 04/21/10 22:15:01 srv005$@DOMAIN.NET
>>> 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 SRV005@DASTDU is changing the password.
> Well srv005 is the Windows Domain Controller, and DASTUD the windows domain.
So what might be happening is the computer is not changing the password
as base on policy, so AD changes it. So unless you are using something like
Samba, Likewise or msktutil and changing the keytab and password, AD
may have change the password (but not the keytab) because the machine did not.
There is an option on the account to say password never expires.
>
> I use a single workstation account for my server. Why would someone need
> more ?
>
A number of reasons depending on the services, and needs to use different
keys/passwords for each.
> 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/hostname.domain.net@DOMAIN.NET
> > (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/nasmgt.tudelft.net@TUDELFT.NET
Strange, you said your AD domain was DASTDU but the realm is TUDELFT.NET
Are these the same AD domain?
Usually the AD domain is the same as the realm. AD can use a short form
and is case insensitive, but Kerberos uses the full realm name and in
upper case.)
(Normally this would be host/nasmgt.tudelft.net@TUDELFT.NET
>
> 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.
Yes. Normally, the keytab file only has host/fqdn@realm entries and
is used by pam_krb5, sshd, telnetd, rlogind, ftpd, etc.
i.e. used for "login" type services. and the AD account for a Unix host
would have only:
userPrincipalName: host/fqdn@REALM
servicePrincipalName: host/fqdn
You can use kinit -k host/fqdn@REALM as long as the keytab and the
AD account password are changed together.
>
> Your story about not needing a root entry in the keytab is interesting.
> I will look in to this.
>
> Greetings .. Richard
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
