I am trying to open a gpmc for another domain. We have 2 AD Domains A and B. There are no trusts between them. My Computer is joined to Domain A and I want to open a gpmc for domain B.
For DSA (AD Users and Computers) this seems to be possible like this:
runas.exe /netonly /user:<Domain B>\<Domain B User> "mmc dsa.msc /domain=<Domain B>"
but when I try to run this for gpmc the following error comes up:
I probably do not have access to the logs of either domain.
This is working as expected and is not supposed to work. The GPMC console is designed to try to get a operational token for the PDC of the domain environment wherever you are opening the same. Because PDC(primary domain controller role holder in a domain ) is supposed to have the most recent copy of the group policies (but sometimes this is not true due to delayed replication etc.) So when you try to connect to GPMC of another domain it connects and sends a Kereros request which fails to get a ticket(to be considered same as token i mentioned above.) .
If you take a network trace in both the cases you will see that there is a TGT request to get a ticket for SPN ldap/(domain A) from the domain B domain controller which is not possible because you do not have trust between the domains. This fails with "KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)" . This is the moment you see the access is denied error as shown in screenshot . I hope that provides clarity on your query .
It's been a while, but with the help of a colleague we came to a solution. The GPMC has an option called trust detection (View -> Options -> General).
Once this options is disabled, the GPMC has to be closed so that this option is saved. If you then start the GPMC via
runas.exe /netonly /user:<Domain B>\<Domain B User> "mmc gpmc.msc /domain=<Domain B>"
the forest from domain B can be added and you can configure your GPOs as you normally would.
Related
I'm pretty new to Kerberos. I'm testing the Single Sign On feature using Kerberos. The environment: Windows clients (with Active Directory authentication) connecting to an Apache server running on Linux machine. The called cgi script (in Perl) connects to a DB server using the forwarded user TGT. Everything works fine (I have the principals, the keytab files, config files and the result from the DB server :) ). So, if as win_usr_a on Windows side I launch my CGI request, the CGI script connects to the remote DB and queries select user from dual and it gets back win_usr_a#EXAMPLE.COM.
I have only one issue I'd like to solve. Currently the credential cache stored as FILE:.... On the intermediate Apache server, the user running the Apache server gets the forwarded TGTs of all authenticated users (as it can see all the credential caches) and while the TGTs lifetime are not expired it can requests any service principals for those users.
I know that the hosts are considered as trusted in Kerberos by definition, but I would be happy if I could limit the usability of the forwarded TGTs. For example can I set the Active Directory to limit the forwarded TGT to be valid only to request a given service principal? And/Or is there a way to define the forwarded TGT to make it able to be used only once, namely after requesting any service principal, become invalid. Or is there a way the cgi script could detect if the forwarded TGT was used by someone else (maybe check a usage counter?).
Now I have only one solution. I can define the lifetime of the forwarded TGT to 2 sec and initiate a kdestroy in the CGI script after the DB connection is established (I set that the CGI script can be executed by the apache-user, but it cannot modify the code). Can I do a bit more?
The credential caches should be hidden somehow. I think defining the credential cache as API: would be nice, but this is only defined for Windows. On Linux maybe the KEYRING:process:name or MEMORY: could be a better solution as this is local to the current process and destroyed when the process is exited. As I know apache create a new process for a new connection, so this may work. Maybe KEYRING:thread:name is the solution? But - according to the thread-keyring(7) man page - it is not inherited by clone and cleared by execve sys call. So, if e.g. Perl is called by execve it will not get the credential cache. Maybe using mod_perl + KEYRING:thread:name?
Any idea would be appreciated! Thanks in advance!
The short answer is that Kerberos itself does not provide any mechanism to limit the scope of who can use it if the client happens to have all the necessary bits at a given point in time. Once you have a usable TGT, you have a usable TGT, and can do with it what you like. This is a fundamentally flawed design as far as security concerns go.
Windows refers to this as unconstrained delegation, and specifically has a solution for this through a Kerberos extension called [MS-SFU] which is more broadly referred to as Constrained Delegation.
The gist of the protocol is that you send a regular service ticket (without attached TGT) to the server (Apache) and the server is enlightened enough to know that it can exchange that service ticket to itself for a service ticket to a delegated server (DB) from Active Directory. The server then uses the new service ticket to authenticate to the DB, and the DB see's it's a service ticket for win_usr_a despite being sent by Apache.
The trick of course is that enlightenment bit. Without knowing more about the specifics of how the authentication is happening in your CGI, it's impossible to say whether whatever you're doing supports [MS-SFU].
Quoting a previous answer of mine (to a different question, focused on "race conditions" when updating the cache)
If multiple processes create tickets independently, then they have no
reason to use the same credentials cache. In the worst case they would
even use different principals, and the side effects would be...
interesting.
Solution: change the environment of each process so that KRB5CCNAME
points to a specific file -- and preferably, in an
application-specific directory.
If your focus in on securing the credentials, then go one step further and don't use a cache. Modify your client app so that it creates the TGT and service tickets on-the-fly and keeps it private.
Note that Java never publishes anything to the Kerberos cache; it may either read from the cache or bypass it altogether, depending on the JAAS config. Too bad the Java implementation of Kerberos is limited and rather brittle, cf. https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/jdk_versions.html and https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/jaas.html
I'm struggling to resolve this error.
I think I've correctly set up the DNS-part, by creating Secondary Zones for forward and reverse look-up. I can ping all servers, ports are open etc. At some point, I can validate the trust perfectly. But when I check again at a later point (now = next day), I'm getting this error (I had this before, first tried recreating everything).
The outgoing trust was successfully validated.
The secure channel (SC) reset on Active Directory Domain Controller
\DC-02.mydomain2.local of domain mydomain2.local to domain
intranet.mydomain1.local failed with error: There are currently no
logon servers available to service the logon request.
Domain controllers:
mydomain2: DC-01, DC-02
mydomain1: has 4 domain controllers, DNS is NOT on the primary domain controller (still need to promote the new DNS server to PDC as well).
The issue always mentions DC-02, not sure if this is relevant?
What should I check?
I also tried resetting the password, as suggested. That leads to a "No Logon servers are available" error.
Update: when validating again from domain 1, it claims the RPC server is unavailable. Further investigation: it seems all of a sudden, from the PDC, I can't ping by the name of the domain or domain controllers of domain2. I double-checked this yesterday, then it worked. From other domain controllers in domain 1, it still works. I disabled Kaspersky Endpoint Security, then ran a ipconfig /flushdns and tried again: working. Could it be Kaspersky, or a DNS-issue (weird, since the same DNS-servers are used and on other DC's it's working?)
Please verify the following:
In the Condintional forwarders in DNS setting - Add the other domain's DNS server name and IP.
Open ncpa.cpl - Goto properties of IPv4 and then click on advanced.
Goto DNS - clcick on the radio button - "Append these DNS suffixes (in order):"
Then add the domain - e.g. lab.com in it.
Perform the above two steps in both the domain's Domain controllers/DNS servers.
I've been trying to setup SonarQube (v4.1) with the LDAP authentication plugin (v1.4) and I just can't get it to authenticate against my domain user. My config is setup as follows:
#########################
# LDAP configuration
#########################
# General Configuration
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.downcase=true
sonar.authenticator.createUsers=true
ldap.authentication=simple
ldap.realm=mydomain.co.uk
ldap.bindDn=CN=USERNAME,OU=developers,DC=mydomain,DC=co,DC=uk
ldap.bindPassword=PASSWORD
# User Configuration
#ldap.user.baseDn=OU=developers,DC=mydomain,DC=co,DC=uk
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
# Group Configuration
ldap.group.baseDn=CN=Domain Users,CN=Users,DC=adastra,DC=co,DC=uk
ldap.group.request=(&(objectClass=group)(member={dn}))
and the log outputs the following messges that seem to say that the LDAP connection is working fine:
2014.01.20 16:12:32 INFO [org.sonar.INFO] Security realm: LDAP
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Auto discovery mode
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Detected server: ldap://dc02.mydomain.co.uk:389
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=dc=mydomain,dc=co,dc=uk, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
2014.01.20 16:12:32 INFO [o.s.p.l.LdapSettingsManager] Group mapping: LdapGroupMapping{baseDn=CN=Domain Users,CN=Users,DC=mydomain,DC=co,DC=uk, idAttribute=cn, requiredUserAttributes=[dn], request=(&(objectClass=group)(member={0}))}
2014.01.20 16:12:32 INFO [o.s.p.l.LdapContextFactory] Test LDAP connection on ldap://dc02.mydomain.co.uk:389: OK
2014.01.20 16:12:32 INFO [org.sonar.INFO] Security realm started
But it just doesn't seem to work for my user unless I use a local user. When enabling logging on the wrapper by setting:
wrapper.console.loglevel=DEBUG
I get the following error in the logs which doesn't really help that much! :)
2014.01.20 17:07:10 ERROR [rails] Error from external users provider:
I just worked through getting the SonarQube LDAP plugin to work with Active Directory myself. Since everyone's network is set up differently, you often can't just copy and paste a configuration. Here is the process I used to figure out the correct configuration at my company:
As stated in the documentation, this configuration goes in the file:
SONARQUBE_HOME/conf/sonar.properties
The following line is required as-is:sonar.security.realm=LDAP. Other lines will be different per company.
It was helpful for me to test the configuration with a GUI tool. I used the Softerra LDAP Browser (free read-only version of LDAP Administrator). In that LDAP Browser,
Create a new profile.
Lookup Servers button will help determine ldap.url. You will need to end up with something along the lines of ldap.url=ldap://dc01.mycompany.local:3268. NOTE: As stated in another answer, this may need to be a different port than the one listed in this screen.
The Base DN box can be left blank for now.
For authentication, I just chose the currently logged on user.
The filter can also be left blank for now.
Click Finish and it should display items at the top level of your AD.
F3 toggles the Quick Search bar.
Since you can't connect SonarQube to AD with Anonymous Authentication, you will need to select a user for the SonarQube service to connect as. Search for that user in the Quick Search.
You should find a CN (Common Name) entry. Double-click that to open it up.
Find the distinguishedName field and copy its value to use as your ldap.bindDn
ldap.bindPassword should be that user's password.
That should be enough to let SonarQube start successfully, but it is NOT enough to let it search for the user that is trying to log into your SonarQube web portal. For that, first pick a sample person (such as yourself).
Do another Quick Search for the sample person and open up their CN entry
Take the value of their distinguishedName, remove the "CN={Their Name}," piece, and put that into ldap.user.baseDn
The last piece that you need to determine with the ldap.user.request. The suggestion from the SonarQube docs to use with AD worked for me: (&(objectClass=user)(sAMAccountName={login})). Let me explain why, in case it does not work for you. The "{login}" will be replaced by whatever the SonarQube enters for their username, so that request string (which is called "Filter" in LDAP Browser) is essentially saying to search for all entries with any objectClass equal to "user" and their sAMAccountName equal to whatever is typed into the username textbox in your SonarQube web portal. Inside the sample person's info, there should be at least one field called "objectClass". One of those should have the value "user". There should also be an field for sAMAccountName. Use that value for the username textbox in your SonarQube web portal.
To test if that request string should work for you, do a Directory Search in LDAP Browser (Ctrl+F3). Put your ldap.user.baseDn value in the "Search DN" texbox and put your ldap.user.request value in the Filter texbox (be sure to manually replace "{login}" with your sample username). It should return the CN entry for the sample person.
Thanks to #aaron who managed to point me in the right direction! For my issue it was a problem with the auto-discovery and the forest I was connecting to. According to http://technet.microsoft.com/en-us/library/cc978012.aspx you should use a different port when connecting to a forest so that it can then search the whole forest rather that the domain you happen to connect to (which I suppose might not be the correct one in auto-discovery mode). In the end the configuration that worked for me was:
# General Configuration
ldap.realm=mydomain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://dc.mydomain.com:3268
# User Configuration
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
Which is actually quite simple and doesn't require a user account to connect with. This means it is in SIMPLE authentication mode (I can't seem to get it to work in anything else) but that is fine with me as it's an internal only system.
I am using SonarQube 3.7.3 and I attached my configuration which works. I hope that would be useful.
# General Configuration
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://...
ldap.bindDn=user
ldap.bindPassword=password
# User Configuration
ldap.user.baseDn=ou=People,dc=company,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
My Fix
I had painstakingly verified my settings, even to the point of using the log file's "User mapping" output line to configure a manual ldapsearch command and verify that my user was being retrieved properly.
For some reason, specifying this setting fixed it for me:
ldap.user.realNameAttribute=cn
Why?
This attribute is supposed to be optional and default to cn anyway, but it only works for me if I specify it manually. This might be a bug.
Debugging with ldapsearch
ldapsearch can allow you to bypass the application query LDAP directly.
I looked in the log file for this line:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=DC=my-ad,DC=example,DC=com, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
And then built an ldapsearch command like:
ldapsearch -D CN=myldapuser,CN=Users,DC=my-ad,DC=example,DC=com -W -h my-ad.example.com -b "DC=my-ad,DC=example,DC=com" "(&(objectClass=user)(sAMAccountName=myuser))"
-D specifies the bind DN, basically the login username for LDAP
-W means that ldapsearch will prompt you for the password
-h specifies the LDAP URL
-b should be baseDN from the log file line
The last positional parameter is the request value from the log file line, after replacing {0} with a real username.
If you get real user info back, it means your basic settings are right. This is a hint that something else is going wrong.
http://blogs.msdn.com/b/visualstudioalm/archive/2015/11/13/support-for-active-directory-and-single-sign-on-sso-in-the-sonarqube-ldap-plugin.aspx
With the new v1.5, only one line is required:
LDAP configuration
sonar.security.realm=LDAP
Using port 3268 did the trick for me. Here is my configuration that works with SonarQube 5.0.1 and Active Directory:
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.createUsers=true
ldap.url=ldap://dc101.office.company.com:3268
ldap.bindDn=CN=Service Account,OU=Windows Service,OU=Accounts,OU=Resources,DC=office,DC=company,DC=com
ldap.bindPassword=PASSWORD
ldap.user.baseDn=DC=office,DC=company,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
None of solutions before worked for me, but this:
# Configuration
sonar.realm=myreal.domain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://myreal.domain.com:389
ldap.bindDn=cn=CNUser,dc=domain,dc=com
ldap.bindPassword=password
# User Configuration
ldap.user.baseDn=ou=people,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
#logeo lo que pasa
wrapper.console.loglevel=DEBUG
My Ldap server do needs authentication, so i cant avoid that. If it doesnt works for you, try not to especify the ldap.user.request: all depends of the configuration of your network´s LDAP server.
I need to read the Active Directory, search users and create user functionality.
I am able to use DirectoryEntry in C# and Domain is only physical server.
In my production environment, I have two physical domain servers with same domain name. When I try to search the AD user or create, I am getting the following exception.
Exception : "0000202B: RefErr: DSID-031007EF, data 0, 1 access points" [extended Error 8235]
Note that I have Domain Admin privileges on the domain but I'm still having the same issue.
0000202B: could mean wrong DN/searchbase like incorrect DC value etc.
Your problem looks like a DNS problem. I know writting that, I've got statisticaly 80% chance being right. Check the domain name resolution from your client. Check your DNS and verify that your two domain controlers are well registered.
The error you are getting is referall related:
ERROR_DS_REFERRAL
8235 (0x202B)
A referral was returned from the server.
You can find the error codes linked at this MSDN Article.
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.