What precautions should I take when creating users that will be used by applications and not by people?

Identification and tracking become important but surprisingly difficult.

First, tag the accounts in the directory so you can identify them as non-user IDs.

Each non-user account needs to be associated with an account owner, someone responsible for securing the system it accesses. Store the owner's identity in the non-user ID's directory entry, so if you go hunting these down later, you know who should be contacted. Remember that owners come and go with employee promotions, turnover, etc., so you might need a department or other organizational tag to go with the employee ID. Group membership can help here. Also, as employees leave, their directory accounts may be deleted, rendering an unknown ID useless - a name is at least someone other people can help you track down.

It may also be helpful to know what machine the accounts are associated with. Keep that information in your directory, too.

If you have a formal request system, where people enter their requirements for requesting the account, the machine, etc., I'd store the request number in the directory entry. But keep in mind that request tracking systems can be changed, and that information associated with tracking numbers issued 5 years ago may no longer be available. I recommend you still keep the owner and machine info on the record, too.

If you don't already have a formal review process for your accounts, consider that when you do implement one, you'll have a big pile of non-user accounts in your directory. This data will help you identify the reviewers (the system owners should review these for appropriateness on a periodic basis.) Consider keeping the review data with the record; you may even want to keep 'last reviewed on/by' information in the directory to provide to auditors.

The main reason to keep this information is in case of a compromise. During the response phase, you need to be able to rapidly identify the people associated with the account so you can change the passwords, scan the systems, and track them down quickly, with a minimum of effort. Keep in mind that you may need to do this activity without alerting the system owners, at least while the investigation is active. You may also need to provide review information to investigators. It's a sad reality that the compromise may originate from an internal source.

To answer the rest of your question, you should generate a lengthy password, using a cryptographically strong password generator (not javascript's random()). If you can assign these accounts and passwords without involving humans, using a password management tool, that's even better. There are commercial systems that tie into ldap servers to do much of this (since you're an Oracle shop, you should check with your account rep because they sell such a system.)

In general there's not a huge amount of difference between users created for automation, and users created for actual people. You should still limit the access each user has to only what's required.

It's a little bit more ambiguous to think about how to segment the 3rd party services access to a trusted resource. A person normally has just one account, and we don't create multiple accounts per user (with some exceptions to this). But your "service" can be thought of in multiple ways. Only you can determine how to delineate this, and if different parts of what you might think of as a single service might need different levels of access.

As an example, there's a well known mail server known as postfix. At a high level you can think of postfix as a single service. At a lower level, it's really designed multiple processes that make up each service inside it. Each process has the least amount of privilege necessary to get the job done.

With a 3rd party software, you may or may not have be able to accomplish a "least privilege" way of doing things. But it's still an important design consideration when setting up automation that isn't as relevant when dealing with actual people.

1. Other commentator suggested to use certificates instead of LDAP - But I will not advice at using 2 authentication mechanisms if you can't easily do it. Having one authentication system will make sure there will be less likelihood for poor implementations.
2. For strong passwords use a "UUID-type 4" generator algorithm - this will give you a random String that will suit you (it won't be guessable).
3. Users that are not used by application have the weakness of having the full permissions of the user while they can be controlled by anyone with access to them (so ex-employees might still have access to them) - make sure the access to such applications is managed (along with their permissions - only give enough permissions for them to work). Also manage the password expiration with caution - If an application won't incorporate such expiry option and it will be enabled, it might stop working at an unexpected time.