Where to put Created date and Created by in DDD?

Is it Ok to use DateTime.Now in the Domain model at all?

Yes.

Where do you put this kind of information using DDD and EF Code First? Should User to be set in the domain object or require it in the Business Layer?

Well. First of all: A DDD model is always in a valid state. That's impossible with public setters. In DDD you work with the models using methods since the methods can make sure that all required information has been specified and is valid.

For instance, if you can mark an item as completed it's likely that the UpdatedAt date should be changed too. If you let the calling code make sure of that it's likely that it will be forgotten somewhere. Instead you should have something like:

public class MyDomainModel
{
    public void MarkAsCompleted(User completedBy)
    {
        if (completedBy == null) throw new ArgumentNullException("completedBy");
        State = MyState.Completed;
        UpdatedAt = DateTime.Now;
        CompletedAt = DateTime.Now;
        CompletedBy = completedBy;
    }
}

Read my blog post about that approach: http://blog.gauffin.org/2012/06/protect-your-data/

Update

How to make shure that noone changes the "CreatedBy" and "CreatedDate" later on

I usually have two constructors for the models which also fits the DB. one protected one which can be used by my persistance layer and one which requires the mandatory fields. Put the createdby in that constructor and set the createdate in it:

public class YourModel
{
    public YourModel(User createdBy)
    {
        CreatedDate = DateTime.Now;
        CreatedBy = createdby;
    }

    // for persistance
    protected YourModel()
    {}
}

Then have private setters for those fields.

I get a lot of R# warning "Virtual member call in constructor", I've read about it before and it is not supposed to be a good practice.

That's usually not a problem. Read here: Virtual member call in a constructor

Is it Ok to use DateTime.Now in the Domain model at all?

It isn't terrible, but the problem is that you will end up having to duplicate code and it will more difficult to achieve consistency.

Where do you put this kind of information using DDD and EF Code First?

You are correct to assert that this type of information doesn't belong in your domain. It is typically called an audit log or trail. There are a few ways to implement auditing with EF. Take a look at AuditDbContext - Entity Framework Auditing Context for instance, or just search around for EF auditing implementations. The idea is that before EF persists changes to an entity, it raises an event which you can listen to and assign the required audit values.

Should User to be set in the domain object or require it in the Business Layer?

It is best to handle this at the infrastructure/repository level with an auditing implementation as stated above. This is the final stop before data is persisted and thus is the perfect place to take care of this.