RE: [ActiveDir] Fun with Kerberos
that's correct - even if you configure an additional UPN suffix for the forest (or for an OU) and assign this to an account when you create the account (e.g. via ADUC), every account will still have an implicit UPN suffix that is made up of his samAccountName + the domain-suffix of his AD domain. So even though your first user had an explicit UPN of [EMAIL PROTECTED], he also had an implicit UPN of [EMAIL PROTECTED] Looks like the reason for your problem was mainly caused due to the special char in your ADM accounts (as it only used the first part of the name to create) - or did you configure your 2nd account like this on purpose? I assume that the accounts were created programmatically, as the ADUC UI will check for duplicate UPNs by querying a GC - so usually this is only a problem if accounts are created at roughly the same time on differnt DCs (even in different domains). But I'm not sure if ADUC only queries for the explicit UPN that you've assigned at creation and ignores the implicit UPN (seems to be the case). But I'm quite sure that this check is not performed when you programmatically add accounts to AD. As a result the duplicate UPNs caused a Kerberos conflict as you well noticed - interesting to read how your users noticed this on their XP clients. Can you elaborate on the Once in a while... - i.e. how often? and did this only occurr if they were also logged on as the guy$adm at the same time? And when did the 2nd account get locked out - at the time the kerberos ticket of #1 was getting refreshed (i.e. after 10 hours past logon of #1)? Or at logon of #1? I'll have to check out this sort of attack a little closer... BTW - the same risk applies with machine-accounts in AD, wich register an SPN (service principal name) that must also be unique: if they're able to register the same name as another machine (e.g. when DDNS is not secured sufficiently well), they can hinder both machines from receiving kerberos tickets and (if the attacked server was set to allow kerberos delegation e.g. for some web-application) could thus cause a DOS for applications running on the other server. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Thursday, September 09, 2004 6:22 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Fun with Kerberos Stumbled upon an issue couple of days ago and wanted to hear what you guys think about it. Suppose that your AD is called myad.com and you also configure additional UPN suffix company.com. Now I create 2 users in child.myad.com child domain: 1) sAMAccountName: guy userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 2) sAMAccountName: guy$adm userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (Notice that in ADUC the userPrincipalName is constructed from 2 fields: W2K username and suffix) From AD point of view this is all nice and legit and UI will be happy to create both. But if you look at the users explicit Kerberos principals, both look the same: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (checked with klist tgt). In our environment, if you are logged on with account #1, two things happened: 1. Once in a while LAN users had XP pop up a baloon in systrey with XP needs your user credentials 2. The corresponding account #2 was getting locked out. Renaming UPNs of supplemental accounts fixed the issue (the name clash was not intentional from the beginning as you might guess). Still I am wondering why AD allowed creation of account with Kerberos principal that already existed in AD. If AD check for sAMAccountName collisions, is there any special reason not to check Kerberos principals ? How can I prevent this from happening ? (the implications would mean that anyone with permissions to create user accounts can do some very nasty things) Guy List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
[ActiveDir] Unauthorized DHCP Requests
Our domain is using a Win2K3 server which is also a domain controller as its DHCP solution. Often I look at the DHCP tables and notice that there are unauthorized machines that connect to our network. This seems to occur from employees who bring in their laptop during the weekend when the workload is light and management does not have as much a presence. The workstations within the domain all follow a naming scheme. For example, ORL-RM3-204-2 which means, the server is located in Orlando, physically located in Room3, desk number 204 and the number of times that that particular workstation has been replaced. So if I see a workstation in the DHCP tables that does not follow that naming scheme, then I know that something else has managed to get an IP Address from the network. Is there a way to prevent unauthorized machines from retrieving an IP address? If so, is there also a way to make an exception to the rule should a non-standard naming convention machine require authorized access to the network? Thank you all for your replies. Edwin
RE: [ActiveDir] Exchange Authentication and WinXP Workstations
I was informed of this problem today and it is with a certain individual who uses their laptop on the public network. When he uses that same laptop from within the network all is buttery! In a totally separate event that I was looking into, I noticed that some people were getting the same error. These workstations have Win2K Pro installed and are on a Win2K3 domain. If the user within the domain hit the RETRY button, it works. I myself am operating under the same GPOs and other related settings as the person who is getting the RETRY prompt from within the network but I do not get that error from my workstation. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Thursday, September 09, 2004 9:16 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Exchange Authentication and WinXP Workstations That depends. What's the entire scope of the problem? One machine? Three machines? All machines? That makes a big difference for the solution that needs to be used. What gets logged on the domain controller when you attempt this (assuming you have audit logging enabled)? What happens on the wire during the attempts? Network trace? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edwin Sent: Thursday, September 09, 2004 8:57 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Exchange Authentication and WinXP Workstations Recently I was informed that users attempting to connect to our Exchange server when using WinXP are experiencing troubles. The error is that it cannot connect to the exchange server. I do not see any errors on the client XP machine or on the Exchange server itself. For some reason I am able to open the MAIL application within the control panel and successfully connect and authenticate to the Exchange server. But when you do a Check Name the error is returned that it could not connect. I found an article on Microsoft's site but it seems a bit extreme. http://support.microsoft.com/default.aspx?scid=kb;EN-US;255843 Has anyone else encountered this? Was there an alternate solution? Thank you all for your replies. Edwin
RE: [ActiveDir] Exchange Authentication and WinXP Workstations
For the first user, I assume then that you realize the answer right? For the other users, see below for questions relating to the scope and steps so far taken. Add software in use to find out what's different about those 2K workstations that have a problem. Al From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of EdwinSent: Thursday, September 09, 2004 11:15 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Exchange Authentication and WinXP Workstations I was informed of this problem today and it is with a certain individual who uses their laptop on the public network. When he uses that same laptop from within the network all is buttery! In a totally separate event that I was looking into, I noticed that some people were getting the same error. These workstations have Win2K Pro installed and are on a Win2K3 domain. If the user within the domain hit the "RETRY" button, it works. I myself am operating under the same GPO's and other related settings as the person who is getting the RETRY prompt from within the network but I do not get that error from my workstation. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, AlSent: Thursday, September 09, 2004 9:16 AMTo: '[EMAIL PROTECTED]'Subject: RE: [ActiveDir] Exchange Authentication and WinXP Workstations That depends. What's the entire scope of the problem? One machine? Three machines? All machines? That makes a big difference for the solution that needs to be used. What gets logged on the domain controller when you attempt this (assuming you have audit logging enabled)? What happens on the wire during the attempts? Network trace? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of EdwinSent: Thursday, September 09, 2004 8:57 AMTo: [EMAIL PROTECTED]Subject: [ActiveDir] Exchange Authentication and WinXP Workstations Recently I was informed that users attempting to connect to our Exchange server when using WinXP are experiencing troubles. The error is that it cannot connect to the exchange server. I do not see any errors on the client XP machine or on the Exchange server itself. For some reason I am able to open the MAIL application within the control panel and successfully connect and authenticate to the Exchange server. But when you do a "Check Name" the error is returned that it could not connect. I found an article on Microsoft's site but it seems a bit extreme. http://support.microsoft.com/default.aspx?scid=kb;EN-US;255843 Has anyone else encountered this? Was there an alternate solution? Thank you all for your replies. Edwin
[ActiveDir] Stopping a GC from doing Authentications
Is it possible to configure a GC to perform GC functions, but to disable the ability to process authentication request? I was asked this question and figured this would be an interesting topic here. I know it is possible to mess with the SRV records to lower the priority of the server, etc. Thanks, Todd
Re: [ActiveDir] Stopping a GC from doing Authentications
Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName | |--++--| | Ldap |SRV |_ldap._tcp.DnsDomainName| |--++--| | DcByGuid |SRV |_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName| |--++--| | Kdc |SRV |_kerberos._tcp.dc._msdcs.DnsDomainName | |--++--| | Dc |SRV |_ldap._tcp.dc._msdcs.DnsDomainName | |--++--| | Rfc1510Kdc |SRV |_kerberos._tcp.DnsDomainName| |--++--| | Rfc1510UdpKdc|SRV |_kerberos._udp.DnsDomainName| |--++--| | Rfc1510Kpwd |SRV |_kpasswd._tcp.DnsDomainName | |--++--| | Rfc1510UdpKpw|SRV |_kpasswd._udp.DnsDomainName | | d|| | |--++--| Global Catalog-Specific Records |---++| | Mnemonic |Type| DNS Record | |---++| |Gc |SRV |_ldap._tcp.gc._msdcs.DnsForestName| |---++| | GcIpAddres|A |gc._msdcs.DnsForestName | | s ||| |---++| | GenericGc |SRV |_gc._tcp.DnsForestName| |---++| For the complete list of the domain controller locator DNS records, see the Windows 2000 Server Resource Kit, Distributed Systems Guide book, Chapter 3 Name Resolution in Active Directory. For the complete list of the domain controller locator DNS records, refer to KB article Q267855 that is referenced in this article You should be able to hide all but the GC records and it will stop being available to clients for authentication. We have hidden DCs from all but in site clients with success. We also found you need to wipe out the SRV records in DNS after you apply the registry / GPO changes. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 09/09/2004 02:16 PM AST| | | Please respond to | | | ActiveDir | |-+--
RE: [ActiveDir] Stopping a GC from doing Authentications
There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName | |--++--| | Ldap |SRV |_ldap._tcp.DnsDomainName| |--++--| | DcByGuid |SRV |_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName| |--++--| | Kdc |SRV |_kerberos._tcp.dc._msdcs.DnsDomainName | |--++--| | Dc |SRV |_ldap._tcp.dc._msdcs.DnsDomainName | |--++--| | Rfc1510Kdc |SRV |_kerberos._tcp.DnsDomainName| |--++--| | Rfc1510UdpKdc|SRV |_kerberos._udp.DnsDomainName| |--++--| | Rfc1510Kpwd |SRV |_kpasswd._tcp.DnsDomainName | |--++--| | Rfc1510UdpKpw|SRV |_kpasswd._udp.DnsDomainName | | d|| | |--++--| Global Catalog-Specific Records |---++| | Mnemonic |Type| DNS Record | |---++| |Gc |SRV |_ldap._tcp.gc._msdcs.DnsForestName| |---++| | GcIpAddres|A |gc._msdcs.DnsForestName | | s ||| |---++| | GenericGc |SRV |_gc._tcp.DnsForestName| |---++| For the complete list of the domain controller locator DNS records, see the Windows 2000 Server Resource Kit, Distributed Systems Guide book, Chapter 3 Name Resolution in Active Directory. For the complete list of the domain controller locator DNS records, refer to KB article Q267855 that is referenced in this article You should be able to hide all but the GC records and it will stop being available to clients for authentication. We have hidden DCs from all but in site clients with success. We also found you need to wipe out the SRV records in DNS after you apply the registry / GPO changes. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | |
RE: [ActiveDir] Stopping a GC from doing Authentications
Maybe I'm mis-understanding something; stop the KDC service? -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, September 09, 2004 2:46 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Stopping a GC from doing Authentications There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName | |--++--| | Ldap |SRV |_ldap._tcp.DnsDomainName| |--++--| | DcByGuid |SRV |_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName| |--++--| | Kdc |SRV |_kerberos._tcp.dc._msdcs.DnsDomainName | |--++--| | Dc |SRV |_ldap._tcp.dc._msdcs.DnsDomainName | |--++--| | Rfc1510Kdc |SRV |_kerberos._tcp.DnsDomainName| |--++--| | Rfc1510UdpKdc|SRV |_kerberos._udp.DnsDomainName| |--++--| | Rfc1510Kpwd |SRV |_kpasswd._tcp.DnsDomainName | |--++--| | Rfc1510UdpKpw|SRV |_kpasswd._udp.DnsDomainName | | d|| | |--++--| Global Catalog-Specific Records |---++| | Mnemonic |Type| DNS Record | |---++| |Gc |SRV |_ldap._tcp.gc._msdcs.DnsForestName| |---++| | GcIpAddres|A |gc._msdcs.DnsForestName | | s ||| |---++| | GenericGc |SRV |_gc._tcp.DnsForestName| |---++| For the complete list of the domain controller locator DNS records, see the Windows 2000 Server Resource Kit, Distributed Systems Guide book, Chapter 3 Name Resolution in Active Directory. For the complete list of the domain controller locator DNS records, refer to KB article Q267855 that is referenced in this article You should be able to hide all but the GC records and it will stop being available to clients for authentication. We have hidden DCs from all but in site clients with success. We also found you need to wipe out the SRV records in DNS after you apply the registry / GPO changes. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park
RE: [ActiveDir] Stopping a GC from doing Authentications
Hi Todd True, but if you misconfigure the DNS settings the clients will not be able to find the DC SRV records to authenticate. We did have one location that was using a BIND DNS server and had a local DC. They replaced their DC but did not update the SRV records in their DNS server. Consequently, there users all authenticated to a DC in another site rather then the local one because they could not find the DNS SRV records for that local DC. We have not yet done extensive testing on the SRV record Group Policy or registry changes but the preliminary testing we have done has hidden the LDAP SRV records from DNS which should make it invisible as an available authentication option for the users. We are looking at testing some parts of this over the next 2 weeks so I will let you know what we find out. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 09/09/2004 02:46 PM AST| | | Please respond to | | | ActiveDir | |-+-- --| | | | To: [EMAIL PROTECTED] | | cc: [EMAIL PROTECTED], (bcc: James Day/Contractor/NPS) | | Subject: RE: [ActiveDir] Stopping a GC from doing Authentications | --| There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName | |--++--| | Ldap |SRV |_ldap._tcp.DnsDomainName | |--++--| | DcByGuid |SRV |_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName| |--++--| | Kdc |SRV |_kerberos._tcp.dc._msdcs.DnsDomainName | |--++--| | Dc |SRV |_ldap._tcp.dc._msdcs.DnsDomainName | |--++--| | Rfc1510Kdc |SRV |_kerberos._tcp.DnsDomainName | |--++--| |
RE: [ActiveDir] Stopping a GC from doing Authentications
Thanks Dean James, That is a good point too. My boss asked me this question... So I figured I would test the waters. I proposed... setup an ADAM instance and have MIIS replicate to it. Allow Everyone Read access. Not sure why they want to do it. Todd -Original Message- From: Dean Wells [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 3:07 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Stopping a GC from doing Authentications Maybe I'm mis-understanding something; stop the KDC service? -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, September 09, 2004 2:46 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Stopping a GC from doing Authentications There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName | |--++--| | Ldap |SRV |_ldap._tcp.DnsDomainName| |--++--| | DcByGuid |SRV |_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName| |--++--| | Kdc |SRV |_kerberos._tcp.dc._msdcs.DnsDomainName | |--++--| | Dc |SRV |_ldap._tcp.dc._msdcs.DnsDomainName | |--++--| | Rfc1510Kdc |SRV |_kerberos._tcp.DnsDomainName| |--++--| | Rfc1510UdpKdc|SRV |_kerberos._udp.DnsDomainName| |--++--| | Rfc1510Kpwd |SRV |_kpasswd._tcp.DnsDomainName | |--++--| | Rfc1510UdpKpw|SRV |_kpasswd._udp.DnsDomainName | | d|| | |--++--| Global Catalog-Specific Records |---++| | Mnemonic |Type| DNS Record | |---++| |Gc |SRV |_ldap._tcp.gc._msdcs.DnsForestName| |---++| | GcIpAddres|A |gc._msdcs.DnsForestName | | s ||| |---++| | GenericGc |SRV |_gc._tcp.DnsForestName| |---++| For the complete list of the domain controller locator DNS records, see the Windows 2000 Server Resource Kit, Distributed Systems Guide book, Chapter 3 Name Resolution in Active Directory. For the complete list of the domain controller
RE: [ActiveDir] Stopping a GC from doing Authentications
What you may find is that users that have already used it as an authentication source will try again. Not sure if they'll try to look up the DNS records or not but I would expect them to just try to use server again. Additionally, wondering what's going to happen if you remove the ability for authentication and you want the other DC's to replicate with it. Not saying it can't work, but it seems odd to have it work that way off the cuff. What really has me quizzical is why you would want to prevent authentication on a GC? Seems a waste of hardware since you'll have all of the data there anyway. Can you expand why you would want to do that? I'm a curious person by nature and it's killing me not to be able to think of a reason on my own ;-) Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 09, 2004 3:09 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Stopping a GC from doing Authentications Hi Todd True, but if you misconfigure the DNS settings the clients will not be able to find the DC SRV records to authenticate. We did have one location that was using a BIND DNS server and had a local DC. They replaced their DC but did not update the SRV records in their DNS server. Consequently, there users all authenticated to a DC in another site rather then the local one because they could not find the DNS SRV records for that local DC. We have not yet done extensive testing on the SRV record Group Policy or registry changes but the preliminary testing we have done has hidden the LDAP SRV records from DNS which should make it invisible as an available authentication option for the users. We are looking at testing some parts of this over the next 2 weeks so I will let you know what we find out. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 09/09/2004 02:46 PM AST| | | Please respond to | | | ActiveDir | |-+-- --- ---| | | | To: [EMAIL PROTECTED] | | cc: [EMAIL PROTECTED], (bcc: James Day/Contractor/NPS) | | Subject: RE: [ActiveDir] Stopping a GC from doing Authentications | --- ---| There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS records that should not be registered by the satellite domain controllers and global catalogs to optimize the domain controller location. Domain Controller-Specific Records |--++--| | Mnemonic |Type| DNS Record | |--++--| |LdapIpAddress |A |DnsDomainName
RE: [ActiveDir] Stopping a GC from doing Authentications
I agree AL, It seems kinda challenged to me as well... I was just asked the question, and I am the kinda guy that looks for answers to questions people pose. All your input has been really appreciated. Todd -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 3:22 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Stopping a GC from doing Authentications What you may find is that users that have already used it as an authentication source will try again. Not sure if they'll try to look up the DNS records or not but I would expect them to just try to use server again. Additionally, wondering what's going to happen if you remove the ability for authentication and you want the other DC's to replicate with it. Not saying it can't work, but it seems odd to have it work that way off the cuff. What really has me quizzical is why you would want to prevent authentication on a GC? Seems a waste of hardware since you'll have all of the data there anyway. Can you expand why you would want to do that? I'm a curious person by nature and it's killing me not to be able to think of a reason on my own ;-) Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 09, 2004 3:09 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Stopping a GC from doing Authentications Hi Todd True, but if you misconfigure the DNS settings the clients will not be able to find the DC SRV records to authenticate. We did have one location that was using a BIND DNS server and had a local DC. They replaced their DC but did not update the SRV records in their DNS server. Consequently, there users all authenticated to a DC in another site rather then the local one because they could not find the DNS SRV records for that local DC. We have not yet done extensive testing on the SRV record Group Policy or registry changes but the preliminary testing we have done has hidden the LDAP SRV records from DNS which should make it invisible as an available authentication option for the users. We are looking at testing some parts of this over the next 2 weeks so I will let you know what we find out. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 09/09/2004 02:46 PM AST| | | Please respond to | | | ActiveDir | |-+-- --- ---| | | | To: [EMAIL PROTECTED] | | cc: [EMAIL PROTECTED], (bcc: James Day/Contractor/NPS) | | Subject: RE: [ActiveDir] Stopping a GC from doing Authentications | --- ---| There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor (Regedt32.exe). 2.Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3.On the Edit menu, click Add Value, and then add the following registry value: Value name: DnsAvoidRegisterRecords Data type: REG_MULTI_SZ Set the value to the list of the space-delimited mnemonics that are specified in the following tables. 4.Quit Registry Editor. Windows Server 2003 To configure Windows Server 2003-based domain controllers, use the Net Logon service Group Policy DNS records not registered by the domain controllers by specifying the list of the space-delimited mnemonics that are specified in the following tables. Reference Tables The following tables contain mnemonics, types, and the owner names of the domain controller locator DNS
RE: [ActiveDir] Stopping a GC from doing Authentications
I'm guessing he wants to use the GC solely as a directory/ldap server rather than as a point of authentication - ldap heavy app, wnat to dedicate a GC to it would be my guess. --Brian -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Thu 9/9/2004 2:21 PM To: '[EMAIL PROTECTED]' Cc: Subject: RE: [ActiveDir] Stopping a GC from doing Authentications What you may find is that users that have already used it as an authentication source will try again. Not sure if they'll try to look up the DNS records or not but I would expect them to just try to use server again. Additionally, wondering what's going to happen if you remove the ability for authentication and you want the other DC's to replicate with it. Not saying it can't work, but it seems odd to have it work that way off the cuff. What really has me quizzical is why you would want to prevent authentication on a GC? Seems a waste of hardware since you'll have all of the data there anyway. Can you expand why you would want to do that? I'm a curious person by nature and it's killing me not to be able to think of a reason on my own ;-) Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 09, 2004 3:09 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Stopping a GC from doing Authentications Hi Todd True, but if you misconfigure the DNS settings the clients will not be able to find the DC SRV records to authenticate. We did have one location that was using a BIND DNS server and had a local DC. They replaced their DC but did not update the SRV records in their DNS server. Consequently, there users all authenticated to a DC in another site rather then the local one because they could not find the DNS SRV records for that local DC. We have not yet done extensive testing on the SRV record Group Policy or registry changes but the preliminary testing we have done has hidden the LDAP SRV records from DNS which should make it invisible as an available authentication option for the users. We are looking at testing some parts of this over the next 2 weeks so I will let you know what we find out. Regards; James R. Day Active Directory Core Team Office of the Chief Information Officer National Park Service (202) 354-1464 (direct) (202) 371-1549 (fax) [EMAIL PROTECTED] |-+-- | | Myrick, Todd | | | (NIH/CIT) | | | [EMAIL PROTECTED] | | | Sent by: | | | [EMAIL PROTECTED]| | | tivedir.org| | | | | | | | | 09/09/2004 02:46 PM AST| | | Please respond to | | | ActiveDir | |-+-- --- ---| | | | To: [EMAIL PROTECTED] | | cc: [EMAIL PROTECTED], (bcc: James Day/Contractor/NPS) | | Subject: RE: [ActiveDir] Stopping a GC from doing Authentications | --- ---| There just isn't a way to turn off the authentication function other than block port 88. Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 2:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ActiveDir] Stopping a GC from doing Authentications Hi Todd You can use a GPO (2003) or Reg Hacks (2000) to hide the SRV records so it can no longer do authentications. The following is an excerpt from Microsoft Q306602 Windows 2000 1.Start Registry Editor
RE: [ActiveDir] Fun with Kerberos
ok... this starts to be more interesting. If the implicit UPN is constructed from samaccountname and AD DNS name, I do not see how Kerberos principals could clash. This is what I initially had (names changed to protect the innocent): Regular account: dn:[EMAIL PROTECTED],OU=Accounts,DC=child,DC=myad,DC=com sAMAccountName: guy userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Supplemental account: dn:CN=Teverovsky\, Guy (Supplemental),OU=Accounts,DC=child,DC=myad,DC=com sAMAccountName: guysu userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The regular account was programmatically created as disabled and was renamed+enabled when user migrated from NT domain. Supplemental account was created beforehand for administrative purposes (the user is member of IT staff) Renaming the UPN of supplemental account to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] was the fix. Now I am totally confused and can't understand why the lockouts happened. It is almost as if [EMAIL PROTECTED] and [EMAIL PROTECTED] UPNs were somehow resolved to the same account. P.S.: it's worth to mention that the machine the user was logged to was in another forest which has Kerberos trust with myad.com forest. Guy From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Thu 9/9/2004 11:52 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Fun with Kerberos that's correct - even if you configure an additional UPN suffix for the forest (or for an OU) and assign this to an account when you create the account (e.g. via ADUC), every account will still have an implicit UPN suffix that is made up of his samAccountName + the domain-suffix of his AD domain. So even though your first user had an explicit UPN of [EMAIL PROTECTED], he also had an implicit UPN of [EMAIL PROTECTED] Looks like the reason for your problem was mainly caused due to the special char in your ADM accounts (as it only used the first part of the name to create) - or did you configure your 2nd account like this on purpose? I assume that the accounts were created programmatically, as the ADUC UI will check for duplicate UPNs by querying a GC - so usually this is only a problem if accounts are created at roughly the same time on differnt DCs (even in different domains). But I'm not sure if ADUC only queries for the explicit UPN that you've assigned at creation and ignores the implicit UPN (seems to be the case). But I'm quite sure that this check is not performed when you programmatically add accounts to AD. As a result the duplicate UPNs caused a Kerberos conflict as you well noticed - interesting to read how your users noticed this on their XP clients. Can you elaborate on the Once in a while... - i.e. how often? and did this only occurr if they were also logged on as the guy$adm at the same time? And when did the 2nd account get locked out - at the time the kerberos ticket of #1 was getting refreshed (i.e. after 10 hours past logon of #1)? Or at logon of #1? I'll have to check out this sort of attack a little closer... BTW - the same risk applies with machine-accounts in AD, wich register an SPN (service principal name) that must also be unique: if they're able to register the same name as another machine (e.g. when DDNS is not secured sufficiently well), they can hinder both machines from receiving kerberos tickets and (if the attacked server was set to allow kerberos delegation e.g. for some web-application) could thus cause a DOS for applications running on the other server. /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Thursday, September 09, 2004 6:22 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Fun with Kerberos Stumbled upon an issue couple of days ago and wanted to hear what you guys think about it. Suppose that your AD is called myad.com and you also configure additional UPN suffix company.com. Now I create 2 users in child.myad.com child domain: 1) sAMAccountName: guy userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 2) sAMAccountName: guy$adm userPrincipalName: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (Notice that in ADUC the userPrincipalName is constructed from 2 fields: W2K username and suffix) From AD point of view this is all nice and legit and UI will be happy to create both. But if you look at the users explicit Kerberos principals, both look the same: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] (checked with klist tgt). In our environment, if you are logged on with account #1, two things happened: 1. Once in a while LAN users had XP pop up a baloon in systrey with XP needs your user credentials 2. The corresponding account #2 was getting locked out. Renaming UPNs of supplemental accounts fixed the issue (the name clash was not intentional from the beginning as you might guess). Still I am wondering why AD allowed creation of account with Kerberos principal that already
