(Sorry for the top-post, I'm a Windows guy..)
Microsoft uses the authdata field to carry SID data (uid and gids, kinda) in
the PAC structure, with optional SAML-type claims added into the structure in
Windows 2012. On the other hand, Active Directory deals with settings for the
user (home dir,
Is your requirement to have the same certificate valid for two Kerberos realms
that are "equivalent" (An AD and a MIT/Heimdahl Kerberos realm)?
I worked with this a while ago (2010) issuing certificates from an
AD-integrated AD-CS certificate server:
Active Directory and MIT Kerberos use
Another avenue that you may want to look into is checking that the Active
Directory domain controller has a real, routable IPv6 address and that you have
disabled transition technologies (ISATAP, 6to4, Toredo, etc.) There are lots of
headaches that can occur when AD thinks it is on a working IPv
You can access more AD brainpower by posting this to
active...@mail.activedir.org or windows-h...@lists.stanford.edu
-
You are correct. The member server can only be a member of a single Kerberos
realm (Active Directory domain) at any time.
My first thought is that you need to add Top
The user will have to connect to their home directory using a credential from
Active Directory (using NTLM auth).
Windows computers will not use Kerberos unless they are:
Professional, Enterprise, or Ultimate edition
Joined to a domain (Or "joined" to an MIT/heimdahl realm)
-Ross
One thing that you did not make clear is if you defined the MIT kerberos realm
in the registry of the Windows 7 machine.
(ksetup /AddKDC or just go to
HKLM\System\CurrentControlSet\LSA\Kerberos\Domains and make a key named the
same as the realm and add a REG_MULTI_SZ value "KdcNames")
-Ross
possible to authenticate Windows clients against MIT
Kerberos (no AD)?
Quoting "Wilper, Ross A" :
> This is possible using the built-in Microsoft Kerberos as well
> without adding software.
Since which version of Windows is this possible... Vista? I should
have mentioned th
This is possible using the built-in Microsoft Kerberos as well without adding
software. There are a few threads from this list about how to do it.
Basically, you need to:
Use KSetup to configure the Windows machine with settings about your MIT realm.
Create a host principal on the MIT KDC and set
day, January 24, 2011 7:58 PM
To: Wilper, Ross A
Cc: kerberos@mit.edu
Subject: Re: Cross-Platform/Realm Authentication Error Assistance
No good on the state of that flag. I have spun up a machine running
Windows Server 2003 and configured it to be identical to the Windows
Server 2008R2 one. Despite th
Grant Cohoe [mailto:co...@csh.rit.edu]
Sent: Monday, January 24, 2011 11:21 AM
To: Wilper, Ross A
Cc: kerberos@mit.edu
Subject: Re: Cross-Platform/Realm Authentication Error Assistance
I ran 'ksetup /getenctypeattr EXAMPLE.COM' on the AD DC and it
returned "Enctypes for domain EXAMPLE.
First, I would strongly suggest that you set the allowed encryption types by
GPO, not by setting registry on machines.
By default, all new external trust relationships created on Windows Server 2008
R2 will use only RC4-HMAC for the cross-realm enctype. You must use ksetup to
enable/disable ot
On the campus side of Stanford, the only ones of those that is not set as
listed below is the one about LDAP signing (set to none) and the Enctypes (DES
is allowed for now, but have tested with it off).
-Ross
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@m
1) In the Active Directory, is the userPrincipalName or one of the
altSecurityIdentities of the admin account jdraht/ad...@realm?
2) Might you be running Windows Server 2008 without Service Pack 2 on your AD?
Before SP2 there was a bug that prevented any account with a "/" from
authenticating.
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of
Nicolas Williams
Sent: Tuesday, December 28, 2010 11:58 AM
To: Victor Sudakov
Cc: kerberos@mit.edu
Subject: Re: some cross-realm trust questions
Our adjoin[0] script (which was referenced in
From: Jean-Yves Avenard [mailto:jyaven...@gmail.com]
Sent: Tuesday, September 21, 2010 12:54 PM
To: Wilper, Ross A
Cc: kerberos@mit.edu
Subject: Re: MIT kdc with Windows 7 pc
Hi
On 22 September 2010 05:39, Wilper, Ross A wrote:
> You must have the external (MIT) principal mapped to a Windows u
You must have the external (MIT) principal mapped to a Windows user for logon
to succeed.
This can be done with an Active Directory/Cross-realm trust by using the
AltSecurityIdentities property on AD users. For a machine in a Workgroup, this
can be done by using "ksetup /mapuser"
Windows suppo
ething more specific than
these two options.
ksetup /SetEncTypeAttr
-Ross
From: c f [mailto:claudia...@gmail.com]
Sent: Wednesday, August 25, 2010 2:46 AM
To: Wilper, Ross A
Cc: kerberos@mit.edu
Subject: Re: problem with the cross-realm, any help?
Hi Ross,
On Tue, Aug 24, 2010 at 5:39 PM, Wi
You mention allowing the DES enctypes on the Windows 7 box? Is that the only
common enctype available between the MIT realm and Windows? (AES256, AES128,
RC4_HMAC, DES_CBC_MD5, DES_CBC_CRC)
If so, you will need to have DES enabled on the domain controller also. This is
most easily done (for all
m/en-us/library/cc736698(WS.10).aspx depending on
your external realm's settings.
-Ross
From: N K [mailto:nkalus...@gmail.com]
Sent: Tuesday, August 03, 2010 4:10 PM
To: Wilper, Ross A
Cc: kerberos@MIT.EDU
Subject: Re: Establishing and verifying a trust between Unix MIT KDC and
Windows Server 200
, if needed.
-Ross
From: N K [mailto:nkalus...@gmail.com]
Sent: Tuesday, August 03, 2010 4:04 PM
To: Wilper, Ross A
Cc: kerberos@MIT.EDU
Subject: Re: Establishing and verifying a trust between Unix MIT KDC and
Windows Server 2003 AD
Hi Ross,
Thank you very much for your prompt response. A
Unfortunately, there are a lot of reasons that this could fail.
1) Incorrect passphrase for one of the three trust accounts
2) Enctype mismatch (by default, a new trust will only support RC4-HMAC)
3) Client machine cannot resolve the MIT KDCs
4) Duplicate mappings on user accounts in the same AD d
That is true.. I oversimplified a bit. This would allow you to have a KDC with
equivalent principals. You would need a trust relationship and the external
principal names set on the AD users as alternate security identities for the
synchronized principals to work for Windows logon, etc. I had si
You could do this with a password change notification DLL on the AD domain
controllers. There are some DLLs around that already do this.
Of course, you can only propagate when a password is changed.
-Ross
-Original Message-
From: kerberos-boun...@mit.edu [mailto:kerberos-boun...@mit.edu
There is a Group Policy option in the security options that sets the Allowed
encryption types.
>From a Windows 7 or Windows Server 2008 R2 machine:
Create a group policy object on OU=Domain Controllers or use an existing policy
Set the policy option "Network security: Configure encryption types a
Have you tried setting this on the client Windows machine?
HKLM\CurrentControlSet\Control\LSA\Kerberos\Domains\YOUR.REALM
RealmFlags = Reg_DWORD = 2 (USE_TCP)
The default behavior for a cross-realm trust is to assume that only UDP is
supported.
-Ross
-Original Message-
From: k
Is the external trust from Windows configured to use RC4-HMAC? If I
remember correctly, the default is DES-CBC-CRC (At least in Windows 2000
- 2003 R2).
HMAC-RC4 for external trust requires Windows 2003 SP1 or later domain
controllers.
For Pre-Windows 2008, there was a later version of "ktpass"
I will comment on two things.
"Empty" root domains in an Active Directory forest - They are worthless
and will cause you headaches down the line if you implement them. Use
other controls to protect your EA accounts.
On the trust problem, by default, Windows clients rely on the Active
Directory to
There is a bug in Windows 2008 KDC that prevents any principal name with a "/"
in it from authenticating from a non-Windows client.
KB Article Number(s): 951191
This is a public hotfix, but you may need to contact Microsoft to get the
hotfix. The hotfix is included in SP2.
-Ross
-Origina
ary 13, 2009 8:46 AM
To: Wilper, Ross A; Russ Allbery; Michael Engemann
Cc: kerberos@mit.edu
Subject: AW: computer account change password with Windows 2008 domain
Hi Ross,
thank you very much for the information about the hotfix.
May I ask if you have experienced any issues since applying the ho
I'll jump in again and state that Windows 2000 did not support setting
unicodePwd using anything other than LDAPS, but Windows 2003 and 2008 do
support using SASL with "auth-conf" (SASL confidentiality is now the
default mechanism in the ADSI libraries) The MS documents are fairly
confusing, but I
The QoP negotiation issue is fixed by the hotfix with KB article 957072.
This has been applied to our systems, but as of yet, I have not seen
that this hotfix has been released publicly. So you would need to
contact MS support for the hotfix
-Ross
-Original Message-
From: kerberos-boun..
: Tuesday, May 13, 2008 12:04 PM
To: Wilper, Ross A; kerberos@mit.edu
Subject: RE: Hotfix released for Windows Server 2008 KDC issue
Ross,
There is a mistake in the kb in the "File information" section, where it
suggests that Windows Server 2003, x86-based files are changed. I think
this shoul
The hotfix for my KDC issue has been publicly released.
http://support.microsoft.com/kb/951191
-Ross
> * Authentication to Active Directory using a principal that contains a
> slash (such as service/foo) from a keytab generated by the Windows
> tool is broken in Windows 2008.
__
m Alsop
Cc: kerberos@mit.edu; Srinivas Cheruku; Wilper, Ross A
Subject: Re: computer account change password with Windows 2008 domain
Ross, could you give Tim our reference numbers for our Microsoft bug
reports that we filed as part of Guest? They're running into one of the
same issues, and I figu
34 matches
Mail list logo
