How to escalate NAGIOS CORE service to alert also without changing the state? (During the CRITICAL-Phase) - nagios

We have a PowerShell Script comparing AD Groups and alerting if there are any differences.
The services works good. If the state changes (CRITICAL to RECOVERY or vica versa) it is OK.
We would like however that we receive Alerts even though the state did not changed.
NAGIOS CORE should alert as till the the services is recovered.
I have tried to add an escalate command, it does not work however.
I have received one alert as it got "CRITICAL" but anyway nothing happens. We do not receive a 2nd or 3rd alert.
define service{
name CheckADGroups_admins
use systemhealth
service_description Check AD Admin Groups for Members of Administrators
check_command check_by_nrpe!check_domainadmins_admins!-t 300 ;
check_interval 60
servicegroups +AVIR
contact_groups +ADGruppe
register 0
}
define serviceescalation{
host_name HOSTNAME
service_description Check AD Admin Groups for Members of Administrators
first_notification 1
last_notification 0
notification_interval 10
contact_groups +ADGruppe
}
Has somebody an idea how to change the config?

Related

Kerberos/SPNEGO : multiple SPNs for the same AD account

Deploying the same HTTP based application on several web servers (srv1, srv2, etc). Protecting the application with SPNEGO auth. The servers are Linux and AD doesn't know of their existence, i.e. they are not joined to the domain. I've got the whole SPNEGO working smoothly on a single host. Now moving on to the subsequent hosts.
Most guides I've found will tell you that you need
An account in AD
A SPN
A keytab (generated on the AD server and then
moved to the Linux host)
While I believe that (2) + (3) will always need to be per-server, I'm somewhat uncertain about (1). Can I do with only one account? I would really like to not having all these accounts in AD if I can do with only one.
This blog has a good recipe for how it can be done: The first invocation of ktpass (for srv1) should be as described in the all the guides you find on the internet, however subsequent invocations (for srv2, srv3, etc) should be using the -setpass and -setupn options.
However I've found that when one uses the ktpass.exe tool the account's userPrincipalName attribute changes to become as given by princ argument from the last invocation of ktpass. So the name of the srv, e.g. srv3 is coded into the name and the name of the account will therefore basically change with each invocation of ktpass. When the web server performs the final step in the SPNEGO chain of events, which is to contact AD using the keytab as credentials, it will look for an account in AD with a userPrincipalName equal to the SPN and this step will therefore fail. (source, scroll to last post, list item 3). Contradicting this is that I'm using Tomcat and thereby JAAS and as far as I understand I can hardcode the principal name to use in my jaas.conf file thereby effectively ignoring the principal name from the keytab.
Can multiple app servers + single account in AD ever work and if so how?
In short, yes it will work and I will tell you how. First of all let's clarify some things and some statements not properly described in your question or the comments:
You have three machines which serve the same DNS name, this means that you either have a DNS round-robin: service.example.com will returned a shuffled list if IPs or a load-balancer (hard of sort) will only one IP for the A record depending on the load. For Kerberos, both setups are equal in the outcome.
Now, you cannot say that the AD does not know the existence of a service or a server if you require Kerberos authentication. It will and must know otherwise it cannot create service tickets for your clients which they pass on to the server. Additionally, Tomcat will not contact the KDC to accept the security context because the service ticket is encrypted with the account's long-term key.
Here is the approach: You have already figured out that one SPN can be bound to one machine, multiple bindings are not allowed. This is the case when you have the machine name bound to the machine account (srv1$, etc.). You need a service account. The service account is a regular account without password expiration, e.g., my-service#EXAMPLE.COM. For this account, you will bind your CNAME or A record. Have you Tomcat authenticator to accept all securty contexts with this service account and it will work.
How to create this magical service account on a Unix-like OS?
Use mskutil to
create the service account,
create a keytab for that service account,
bind your SPN to that service account and have the keytab updated.
After that you will have a keytab suitable for your use. Verify with an LDAP query (e.g., with Softerra's LDAP browser or else) that the account exists, the SPN (servicePrincipalName) is bound to that account and you are done.
Important: if any of your clients use MIT Kerberos or Heimdal, you must set rdns = false your your krb5.conf.
Godspeed!

Active Directory Service Accounts

I am currently working on a AD installation where there are about 45,000 accounts and about 60+ global catalogue servers, some accounts are active some are disabled. Some active accounts are service account which don't appear to login as the lastlogondate is several months old.
If I disable some of the service accounts which do not login the application stops working so I know the application is authenticating to AD somehow.
My question is how can I determine which account have been used to authenticate but have not actually 'logged in'? Is there an attribute I can query or can I set it somehow that AD writes to the event log?
Simply speaking, lastLogonTimestamp is the right attribute to find inactive accounts.
See following link for descriptions on different related attributes:
http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx
Just copied from above link, using PowerShell, you can get inactive users (inactive for AROUND 90 days, note lastLogonTimestamp is only an approx value) by calling:
Search-ADAccount -AccountInactive -DateTime ((get-date).adddays(-90)) -UsersOnly
For the last logon time from Hyena, I suspect it is inaccurate.
(I never use Hyena before, so just a guess.)
From the following link:
http://www.systemtools.com/HyenaHelp/index.htm#userlogoninfo.htm
Seems by default it only get the last logon info from one DC only. If they get this info from lastLogon attribute instead of lastLogonTimestamp (very likely, otherwise the "Check All Domain Controllers" option is meaningless), it will only get the logon time on this specific DC only. So if those service account are always using DC1 in recent authentications but you connect to DC2 to get the logon time, you will only get a very old time (or none if it never use DC2 to authenticate).
I don't know what function or technique you are using in Hyena to get the 'last logon' information, but as indicated by others, the AD attribute 'lastlogontimestamp' will get you a fairly accurate date/time (~within 10-day accuracy) of the last use of an account. This attribute can be added to any query in Hyena for all of your users. You can also export out the service information on all computers and servers, to see what accounts are being used.
If you need additional assistance, contact SystemTools Support - support#systemtools.com
We are always ready to support our customers.
(I am with SystemTools (Hyena) support)

Does domain group policy affect machine and user if user logging locally?

I have read that if user logging on locally (with local user account) the domain GPO will not process. Is it true?
A GPO has a part for the computer and a part for the user that matches the scope in the security filtering of the GPO and is linked to the relevant OU. So if the computer is actually connected to the domain, it will apply all matching GPOs no matter what user is logged in, even for local users.
Hence, if the computer is part of the domain and the user is not (e.g. local user), the computer policies still will be applied and the user policies will not.
So if you want to not apply both policies, you need to use a local user AND remove the computer from the domain (e.g. via a local admin) and for example put it to a local workgroup instead.
The meaning of computer policies is just that: centrally administered settings for a specific machine that cannot be influenced by any user.
I know this is like 6 years old but for anyone else that ends up here, in my experience this is only true if loop back processing is enabled (computer > policies > system > group policy > Configure user Group Policy loopback processing mode > Enabled [merge])
per this post on reddit: https://www.reddit.com/r/sysadmin/comments/2f9tpf/question_does_signing_in_as_a_local_admin_bypass/ck7jvzx?utm_source=share&utm_medium=web2x
without loopback my computer GPOs do not apply. With it, my computer gpo applies even when local users log in

"A referral was returned from the server" error only while querying LDAP from outside the domain

I have 2 domains in the forest. 2nd one is the child domain of the first one. Like below...
Domain1 = abc.com on machine machine1
Domain2 = child.abc.com on machine macnihe2
I have c# application which tries to create a DirectoryEntry on the child domain.
LDAP://machine1/OU_IN_CHILD_DOMAIN/PARENT_DOMAIN_USERNAME_AND_PASSWORD
This works when my c# application is on parent domain i.e on abc.com but if my c# application is on any un-related domain like unrelateddomain.com, I get A referral was returned from the server error.
Please let me know why is this? In first case AD is able to do 'Referral chasing' but not in second case. Is there something am I missing?
I had this exact problem for months and just solved it this afternoon. Here's what you will need to do: prepend a domain controller hostname from the child domain to the LDAP string. In your example, it might be like this for the sub/child domain:
LDAP://MyChildDomainController1.child.abc.com
You also mention connecting from an unrelated domain/LDAP/Active Directory. If there is no trust between Active Directory on the two domains and their LDAP structure is unrelated, then you will not be able to use the above method. If it's possible, you're only approach in that circumstance would be to use an authenticated connection. Never tried it but this is a possible answer:
https://stackoverflow.com/a/9252303/1569434
"...ensure that the service account (or computer account if network
service) hosting the code above is allowed to delegate to the LDAP
service on all of the DCs in your environment"

Check IsInRole against AD

I recently tried to work with WindowsPrincipal but I am getting really confused. I use this code snippet:
WindowsPrincipal principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
MessageBox.Show(Thread.CurrentPrincipal.IsInRole("MyDomain\\Users").ToString());
It returns True so it's OK. But I thought that this "IsInRole" check works against Active Directory. But when I unplug the network cable it still returns true. How come? Is there any easy way to check whether logged user is in specific domain against AD?
Active Directory credentials can be cached on the local system, including role membership (to support Group Policy enforcement). You can turn off the credential cache as described in the MSDN KB Cached Domain Logon Information, but I'm not sure that will clear the cache. While I cannot confirm (as I'm not currently on a system with cached credentials), I believe they are stored as hashes under the registry key HKEY_LOCAL_MACHINE\SECURITY\CACHE\ in values labeled "NLx" where x is an integer.
your code is fine, Windows is a bit smarter than what we think and is caching the user group membership even when you disconnect the network cable, in fact if you are in a AD domain you can also unplug the cable and still log-in because everything is cached locally.
If you want to check really how it works try to unplug the cable, check for another group membership while disconnected and it will be false, then add your user to another group on the server and this check will pass only after you connect your machine to the network again and do a log-off / log-in.

Resources